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,FREEMAIL_FROM autolearn=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!feeder.eternal-september.org!news.uzoreto.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: hreba Newsgroups: comp.lang.ada Subject: Re: generic provokes segmentation fault Date: Mon, 18 May 2020 13:29:43 +0200 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Trace: individual.net XB5Z9mTkBvazvcN8RV8kBwb2jgupnkW6SOT5yVp0hHkFJWi7x5 Cancel-Lock: sha1:ENwAFh2pJ1jxr3b3ebo046/tKyE= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 In-Reply-To: Content-Language: de-DE Xref: reader01.eternal-september.org comp.lang.ada:58735 Date: 2020-05-18T13:29:43+02:00 List-Id: 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