[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Help-gsl] gsl_multimin_fminimizer_free should deallocate gracefull
From: |
Carl Boettiger |
Subject: |
Re: [Help-gsl] gsl_multimin_fminimizer_free should deallocate gracefully |
Date: |
Tue, 5 May 2009 23:50:06 -0700 |
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