Re: generic provokes segmentation fault

[hreba <f_hreba@yahoo.com.br>]

On 2020-05-17 20:34, Dmitry A. Kazakov wrote:
> 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.

It is done in the intended way. Solve_Init allocates and Finit_Solve 
frees, calling the respective GSL/odeiv2 functions. My test program 
calls them in the correct sequence.

> 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.

In my program, I hold
  - references to structures allocated by the GSL C functions
  - data, which I have to provide, in variables of type C.double and
    arrays of them (with convention C).
Now what do you mean with experimenting in memory pools?

> 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.

My software is not yet in its final state. The strategy is to transform 
it step by step from the thin to the thick binding, including tests at 
each stage. Reason for that is ease of problem detection. The 
development might result in a controlled object in the end. Right now, 
my programs seems logically correct and a non-proper style certainly 
should not provoke an exception.

>> 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.

That's correct with respect to the floating point type. What about dim? 
I need an array holding start and end values of the calculation. Without 
dim I would have to allocate it dynamically. I'm not writing 
safety-critical software, but shouldn't that be avoided if possible?

>> 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.

What n are you talking about? The C prototype of the above function is

int gsl_odeiv2_driver_apply (gsl_odeiv2_driver * d, double *t,
                              const double t1, double y[]);

I you mean the dimension of the equation system, that is defined within 
Init_Solve.

Regards,
-- 
Frank Hrebabetzky, Kronach	+49 / 9261 / 950 0565