Re: [Help-gsl] gsl_multimin_fminimizer_free should deallocate gracefully

[Carl Boettiger]

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