Re: generic provokes segmentation fault

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On 2020-05-18 13:29, hreba wrote:
> 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.

What is global variables you are talking about? gsl_odeiv2_driver seems 
to be allocated and initialized using library functions.

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

You can always pass array as a parameter. The caller is responsible to 
allocate it in a way suitable for the caller, e.g. on the stack.

>>> 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 see, I thought it is another variant of apply.

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

I do not know the library. To me it looks that dimension is a parameter 
to pass with other parameters when gsl_odeiv2_driver is allocated.

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