This is the mail archive of the
mailing list for the glibc project.
Re: malloc problem/question in 2.1.3
- To: glibc-linux at ricardo dot ecn dot wfu dot edu
- Subject: Re: malloc problem/question in 2.1.3
- From: Kathy Bieltz <kbieltz at hal-pc dot org>
- Date: Thu, 01 Jun 2000 08:34:57 -0500
- References: <3935691B.C54F9E55@ronispc.chem.mcgill.ca>
- Reply-To: glibc-linux at ricardo dot ecn dot wfu dot edu
When you mentioned the SIGSEGV in a program where you are
using malloc() and free() the first thing I thought of was that you
were freeing some memory that hadn't been allocated.
This has bitten me so many times in my XWindows programs
that now I make sure all my pointers are initialized to NULL
so that I can test for a NULL pointer before I attempt to
free any memory.
I'm glad you found your problem. You're lucky the debugger
indicated the problem was in malloc(). Usually, after freeing
memory not previously allocated, the SIGSEGV will occur
in some totally unrelated code.
David Ronis wrote:
> I have a program that repeatedly uses strdup to malloc and copy some
> small strings (each 9+1 char's long), does some computations, and then
> frees the strings. It works for a while (I estimate that it has 21
> calls to strdup/free) but ends up
> SIGSEGV'ing. The same code compiled under solaris works fine, and
> running under their debugger with leak detection turned on shows no
> The debugger backtrace (ddd/gdb) shows that
> Program received signal SIGSEGV, Segmentation fault.
> 0x407798e0 in chunk_alloc (ar_ptr=0x40803fa0, nb=16) at malloc.c:2763
> 2763 malloc.c: No such file or directory.
> #1 0x4077978c in __libc_malloc (bytes=10) at malloc.c:2696
> 2696 malloc.c: No such file or directory.
> #2 0x4077e594 in __strdup (s=0x8084b06 "\\Y0\\Y0\\WL") at strdup.c:43
> 43 strdup.c: No such file or directory.
> The program was compiled with gcc-2.95.2 with -O0 -g (I've also used
> agressive optimization options with the same result) on an
> i686-linux-gnu box (version 2.2.15 of linux). I also built glibc here,
> using the default configure options [unfortunately I didn't save the
> sources, so can't trace the routines any further].
> Does this problem ring a bell with anyone? Any suggestions how I might
> track it down (I tried building checker, but couldn't).
> Thanks in advance.