This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug libc/1510] New: Malloc segmentation fault with glibc 2.3.2,2.3.5
- From: "math at sai dot msu dot ru" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sources dot redhat dot com
- Date: 20 Oct 2005 22:32:13 -0000
- Subject: [Bug libc/1510] New: Malloc segmentation fault with glibc 2.3.2,2.3.5
- Reply-to: sourceware-bugzilla at sourceware dot org
Hello,
I am seeing the segmentation fault inside a malloc with glibc 2.3.2 and
2.3.5. I suspect that this is the glibc bug.
The error comes in rather complex environment (when I run the C program
through JavaNativeInterface). The java program using the C library crashes
with the segmentation fault in malloc block.
Here you can see the core dump:
(gdb) bt
#0 0xb7e58027 in raise () from /lib/tls/libc.so.6
#1 0xb7e59747 in abort () from /lib/tls/libc.so.6
#2 0xb7c4ed6f in os::abort ()
from /opt/j2sdk1.4.2_09/jre/lib/i386/client/libjvm.so
#3 0xb7cb4221 in VMError::report_and_die ()
from /opt/j2sdk1.4.2_09/jre/lib/i386/client/libjvm.so
#4 0xb7c4f8d7 in JVM_handle_linux_signal ()
from /opt/j2sdk1.4.2_09/jre/lib/i386/client/libjvm.so
#5 0xb7c4e2f4 in signalHandler ()
from /opt/j2sdk1.4.2_09/jre/lib/i386/client/libjvm.so
#6 <signal handler called>
#7 0xb7e926c1 in _int_malloc () from /lib/tls/libc.so.6
#8 0xb7e918f3 in malloc () from /lib/tls/libc.so.6
#9 0xaaa588ac in new_grp_stack () at group.c:5930
#10 0xaaa58595 in fits_clean_url (
inURL=0xbfa839bc
"/home/math/works/gmatch/java_interface/../test_data/ngc3065_without_wcs.fits",
outURL=0xbfa8319c "../test_data/ngc3065_without_wcs.fits",
status=0xbfa8831c) at group.c:5828
....
The analyze of assembler code I realized that the seg. fault come
roughly from lines 3873-3879 of _int_malloc() in malloc/malloc.c
and _int_malloc_ has been called from
line 3339 of public_mALLOc( ) in malloc/malloc.c
In frame #9 the malloc with argument = 8 has been called.
I tried to trace the error by setting the MALLOC_CHECK_ variable, but didn't
succeded:
When I set MALLOC_CHECK_=1 the program works without any problem, and malloc
does not report anything (except "malloc: using debugging hooks" 3 times in
the very beginning)
When I set MALLOC_CHECK=2 the program works without problems
And when I set MALLOC_CHECK_=0 the program crashes (in the same place as
without MALLOC_CHECK_)
Isn't that the bug in malloc ?
First the error appeared with glibc 2.3.2, but after that I updated glibc to
2.3.5 and the result was the same. (the previous examples, and line numbers
shown here were from glibc 2.3.5)
Info:
uname-r:
Linux fortune 2.6.12 #28 Thu Oct 20 06:32:14 CEST 2005 i686 unknown unknown
GNU/Linux
gcc -v:
Reading specs from /usr/lib/gcc-lib/i486-slackware-linux/3.3.4/specs
Configured with: ../gcc-3.3.4/configure --prefix=/usr --enable-shared
--enable-threads=posix --enable-__cxa_atexit --disable-checking
--with-gnu-ld --verbose --target=i486-slackware-linux
--host=i486-slackware-linux
Thread model: posix
gcc version 3.3.4
Thank you in advance,
Sergey
PS I'm not completely sure what's the host/target/build triplets are...
The values which I have written were obtained from config.guess from
automake-1.8 package.
--
Summary: Malloc segmentation fault with glibc 2.3.2,2.3.5
Product: glibc
Version: 2.3.5
Status: NEW
Severity: normal
Priority: P2
Component: libc
AssignedTo: drepper at redhat dot com
ReportedBy: math at sai dot msu dot ru
CC: glibc-bugs at sources dot redhat dot com,math at sai dot
msu dot ru
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://sourceware.org/bugzilla/show_bug.cgi?id=1510
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.