Re: [Help-gsl] gsl_multimin_fminimizer_free should deallocate gracefully

[kamaraju kusumanchi]

Thanks Carl! Your reply is helpful. I've rewritten the code by
defining a new gsl_vector variable. It works now. Previously, when I
used the incorrect code (the crash.cpp I attached was reduced from it)
I actually managed to create a kernel panic on a Debian machine :-)

Thanks for your help.
raju

On Wed, May 6, 2009 at 2:50 AM, Carl Boettiger <address@hidden> wrote:
> Ok, think i understand.  You call gsl_multimin_fminimizer_x and assign
> the value to the gsl_vector pointer x, but you had already allocated
> this vector earlier.  You'll note it does not crash if you assign this
> to a new pointer, like
>
> gsl_vector * xx = gsl_multimin_fminimizer_x(s)
>
> It seems to me that you'd have to do this, and then get each of the
> values from xx and copy them to x in a loop, you can't just set the
> values the whole vector with the address alone.  Does this make sense?
>
> -Carl
>
>
> On Tue, May 5, 2009 at 11:17 PM, kamaraju kusumanchi
> <address@hidden> wrote:
>> Forgot to add the attachment last time. Sorry! It is attached now.
>>
>> raju
>>
>> On Wed, May 6, 2009 at 1:48 AM, Carl Boettiger <address@hidden> wrote:
>>> I'm not seeing the attached code, but Id look at what size you are
>>> passing for the parameter space in the multimin argument.  If you are
>>> using dynamically allocated parameter space, you need to provide the
>>> copy-constructor, copy, and destructor yourself (instead of the NULL
>>> pointers given in the examples -- sorry if this is what you are doing,
>>> just my guess from the error).  I got very similar stack trace in an
>>> error in my own codes do to not providing my own copy functions for a
>>> variable sized structure.  Hope this helps.  If not, maybe try
>>> reposting the source code.
>>>
>>> -Carl
>>>
>>> On Tue, May 5, 2009 at 10:03 PM, kamaraju kusumanchi
>>> <address@hidden> wrote:
>>>> Consider the attached crash.cpp.
>>>>
>>>> It is compiled using
>>>>
>>>> $g++ -g -O0 crash.cpp -lgsl -lgslcblas
>>>>
>>>> When executed, it crashes with
>>>>
>>>> $./a.out
>>>>
>>>> initial x vector is
>>>> 0.1  1.1  2.1  3.1  4.1  5.1  6.1  7.1  8.1  9.1  10.1  11.1  12.1
>>>> 13.1  14.1  15.1  16.1  17.1  18.1  19.1  20.1  21.1  22.1  23.1  24.1
>>>>  25.1  26.1  27.1  28.1  29.1  30.1  31.1  32.1  33.1  34.1  35.1
>>>> 36.1  37.1  38.1  39.1  40.1  41.1  42.1  43.1  44.1  45.1  46.1  47.1
>>>>  48.1  49.1
>>>> initial step size vector is
>>>> 0.2  0.2  0.2  0.2  0.2  0.2  0.2  0.2  0.2  0.2  0.2  0.2  0.2  0.2
>>>> 0.2  0.2  0.2  0.2  0.2  0.2  0.2  0.2  0.2  0.2  0.2  0.2  0.2  0.2
>>>> 0.2  0.2  0.2  0.2  0.2  0.2  0.2  0.2  0.2  0.2  0.2  0.2  0.2  0.2
>>>> 0.2  0.2  0.2  0.2  0.2  0.2  0.2  0.2
>>>> *** glibc detected *** ./a.out: free(): invalid pointer: 0x097b55b0 ***
>>>> ======= Backtrace: =========
>>>> /lib/i686/cmov/libc.so.6[0x403e6564]
>>>> /lib/i686/cmov/libc.so.6(cfree+0x96)[0x403e8766]
>>>> /usr/lib/libgsl.so.0(gsl_block_free+0x25)[0x4007bee5]
>>>> /usr/lib/libgsl.so.0(gsl_vector_free+0x2c)[0x401b88bc]
>>>> /usr/lib/libgsl.so.0(gsl_multimin_fminimizer_free+0x3b)[0x401246eb]
>>>> ./a.out(__gxx_personality_v0+0x457)[0x8048f07]
>>>> /lib/i686/cmov/libc.so.6(__libc_start_main+0xe6)[0x4038e456]
>>>> ./a.out(__gxx_personality_v0+0x31)[0x8048ae1]
>>>> ======= Memory map: ========
>>>> 08048000-0804a000 r-xp 00000000 08:08 2506337    
>>>> /home/rajulocal/debug/gsl/a.out
>>>> 0804a000-0804b000 rw-p 00001000 08:08 2506337    
>>>> /home/rajulocal/debug/gsl/a.out
>>>> 097b5000-097d6000 rw-p 097b5000 00:00 0          [heap]
>>>> 40000000-4001a000 r-xp 00000000 08:07 163575     /lib/ld-2.7.so
>>>> 4001a000-4001c000 rw-p 0001a000 08:07 163575     /lib/ld-2.7.so
>>>> 4001c000-4001d000 r-xp 4001c000 00:00 0          [vdso]
>>>> 4001d000-40020000 rw-p 4001d000 00:00 0
>>>> 40038000-40214000 r-xp 00000000 08:07 1756194    /usr/lib/libgsl.so.0.13.0
>>>> 40214000-4021e000 rw-p 001dc000 08:07 1756194    /usr/lib/libgsl.so.0.13.0
>>>> 4021e000-40255000 r-xp 00000000 08:07 1756196    
>>>> /usr/lib/libgslcblas.so.0.0.0
>>>> 40255000-40256000 rw-p 00036000 08:07 1756196    
>>>> /usr/lib/libgslcblas.so.0.0.0
>>>> 40256000-40257000 rw-p 40256000 00:00 0
>>>> 40257000-4033a000 r-xp 00000000 08:07 1748044    
>>>> /usr/lib/libstdc++.so.6.0.10
>>>> 4033a000-4033d000 r--p 000e2000 08:07 1748044    
>>>> /usr/lib/libstdc++.so.6.0.10
>>>> 4033d000-4033f000 rw-p 000e5000 08:07 1748044    
>>>> /usr/lib/libstdc++.so.6.0.10
>>>> 4033f000-40345000 rw-p 4033f000 00:00 0
>>>> 40345000-40369000 r-xp 00000000 08:07 163291     /lib/i686/cmov/libm-2.7.so
>>>> 40369000-4036b000 rw-p 00023000 08:07 163291     /lib/i686/cmov/libm-2.7.so
>>>> 4036b000-40377000 r-xp 00000000 08:07 163613     /lib/libgcc_s.so.1
>>>> 40377000-40378000 rw-p 0000b000 08:07 163613     /lib/libgcc_s.so.1
>>>> 40378000-404cd000 r-xp 00000000 08:07 163287     /lib/i686/cmov/libc-2.7.so
>>>> 404cd000-404ce000 r--p 00155000 08:07 163287     /lib/i686/cmov/libc-2.7.so
>>>> 404ce000-404d0000 rw-p 00156000 08:07 163287     /lib/i686/cmov/libc-2.7.so
>>>> 404d0000-404d4000 rw-p 404d0000 00:00 0
>>>> 40500000-40521000 rw-p 40500000 00:00 0
>>>> 40521000-40600000 ---p 40521000 00:00 0
>>>> bff91000-bffa6000 rw-p bffeb000 00:00 0          [stack]
>>>> Aborted (core dumped)
>>>>
>>>>
>>>>
>>>> I believe this happens because gsl_vector x is already deallocated
>>>> before the corresponding vector in gsl_multimin_fminimizer s is
>>>> deallocated. Is this considered a bug in my code or a bug in gsl? In
>>>> any case, It would be nice if cases like these are handled more
>>>> gracefully.
>>>>
>>>> regards
>>>> raju
>>>>
>>>>
>>>> _______________________________________________
>>>> Help-gsl mailing list
>>>> address@hidden
>>>> http://lists.gnu.org/mailman/listinfo/help-gsl
>>>>
>>>
>>>
>>>
>>> --
>>> Carl Boettiger
>>> Population Biology, UC Davis
>>> http://two.ucdavis.edu/~cboettig
>>>
>>
>
>
>
> --
> Carl Boettiger
> Population Biology, UC Davis
> http://two.ucdavis.edu/~cboettig
>