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.2uCIJahv+a4XEBqttj5Vkw.user.gioia.aioe.org!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: generic provokes segmentation fault Date: Mon, 18 May 2020 14:36:59 +0200 Organization: Aioe.org NNTP Server Message-ID: References: NNTP-Posting-Host: 2uCIJahv+a4XEBqttj5Vkw.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 X-Mozilla-News-Host: news://news.aioe.org X-Notice: Filtered by postfilter v. 0.9.2 Content-Language: en-US Xref: reader01.eternal-september.org comp.lang.ada:58737 Date: 2020-05-18T14:36:59+02:00 List-Id: 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