This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

segfault in libc6-2.2.5:malloc on call from libstdc++


Hi all.

libc = libc6 v.2.2.5-3
libstdc++ = v 3.0.4-6
(debian packaging numbers)

The subject should be self explanatory.  Could this have anything to do 
with libstdc++, or is that a red herring.

I also have equally reproducible results on valarray destruction and 
subsequent calls to libc:free, but I figured that those had a greater 
likelihood of being the fault of libstdc++ or me and not glibc.  Now I'm 
not so sure -- the stack trace below looks pretty incriminating to me.

Other unusual variants: I'm linking against libf2c, libblas, and 
liblapack -- don't know much about fortran, but could that have some bad 
interaction with libc?

I'd be happy to tar up my code if anyone is interested.

Cheers,
Craig

Stack trace:
Program received signal SIGSEGV, Segmentation fault.
0x40bdf4c6 in malloc () from /lib/libc.so.6
(gdb) info stack
#0  0x40bdf4c6 in malloc () from /lib/libc.so.6
#1  0x40bdf1e4 in malloc () from /lib/libc.so.6
#2  0x40094789 in operator new(unsigned) () from /usr/lib/libstdc++.so.3
#3  0x080514e1 in std::__valarray_get_memory(unsigned) (__n=8)
    at /usr/include/g++-v3/bits/valarray_array.h:53
#4  0x0805ad6d in int* restrict std::__valarray_get_storage<int>(unsigned) (
    __n=2) at /usr/include/g++-v3/bits/valarray_array.h:59
#5  0x080594a6 in std::valarray<int>::valarray(unsigned) (this=0xbffff800,
    __n=2) at /usr/include/g++-v3/bits/std_valarray.h:265
#6  0x08055f25 in Patch::calculateTargetBin(Atom const&) (this=0xbffff950,
    a=@0x807cd88) at Patch.cc:266
#7  0x080556bb in Patch::rebin() (this=0xbffff950) at Patch.cc:167
#8  0x080658ef in main (argc=4, argv=0xbffffa94) at hessianTest.cc:97
#9  0x40b8a6cf in __libc_start_main () from /lib/libc.so.6

PS is it usual for malloc to call itself recursively like this?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]