bug-glibc
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Craig Maloney
Subject: segfault in libc6-2.2.5:malloc on call from libstdc++
Date: Wed, 03 Apr 2002 09:06:41 -0800
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020214

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,
   address@hidden) 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?




reply via email to

[Prev in Thread] Current Thread [Next in Thread]