From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00
	autolearn=unavailable autolearn_force=no version=3.4.4
Path: 
 eternal-september.org!reader01.eternal-september.org!feeder.eternal-september.org!aioe.org!.POSTED.5toSSCP5H8WhQPVIfFrwuA.user.gioia.aioe.org!not-for-mail
From: "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>
Newsgroups: comp.lang.ada
Subject: Re: generic provokes segmentation fault
Date: Sun, 17 May 2020 20:34:08 +0200
Organization: Aioe.org NNTP Server
Message-ID: <r9s02u$j01$1@gioia.aioe.org>
References: <hicvepF6b7sU1@mid.individual.net>
NNTP-Posting-Host: 5toSSCP5H8WhQPVIfFrwuA.user.gioia.aioe.org
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Complaints-To: abuse@aioe.org
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.8.0
Content-Language: en-US
X-Notice: Filtered by postfilter v. 0.9.2
Xref: reader01.eternal-september.org comp.lang.ada:58716
Date: 2020-05-17T20:34:08+02:00
List-Id: <comp.lang.ada>

On 2020-05-17 16:19, hreba wrote:

> I'll try to describe the problem without posting loads of code. Still 
> working on my thick binding of GSL/Odeiv2, the API of my package odeiv2 
> consists of 3 procedures:
>   - Init_Solve
>   - Solve
>   - Finit_solve
> They basically copy values to variables which are global in odeiv, and 
> pass their addresses to the C library functions of the thin binding. 

Well, that is certainly not good. IMO it is not Ada way to do this and 
it does not look like intended way of odeiv2 either. I looked shortly 
the interface of. It is decently designed and has operations to allocate 
a new structure and free it.

As a side note. It is not clear if the structure must be allocated in 
the C's memory pool. I would not experiment with that. Which could be 
reason for memory corruption on its own. That is frequently the case 
when the library has some bookkeeping attached to memory allocation.

But clearly the proper way to write an Ada binding to this would be a 
Limited_Controlled object. It would allocate the C object(s) in its 
Initialize using the official library call (or at some later point, e.g. 
on demand) and free them in the Finalize, again by the official means.

> generic
>     dim:    Positive;
>     type Float is digits<>;
> package odeiv2 is

I don't see any reason making it generic. The C library can only double. 
It does not make much sense to have a generic instance for Float, 
Long_Float, IEEE_Float_32 etc if the underlying computations are all double.

> raised STORAGE_ERROR : stack overflow or erroneous memory access
> (SIGSEV, segmentation fault, when run under the debugger)
> just at the line starting "status:= ..." shown above.
> What would be an explication or a remedy for this behaviour?

In the code you posted the parameter n in the call is missing. If that 
is not a typo error in your post, then you have got the stack mangled.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de