Re: SIGSEGV, not a problem just interesting observation.

Matthias Urlichs (smurf@work.smurf.noris.de)
24 May 1997 16:03:58 +0200


<TIGRANA@DSTIUK.CCMAIL.CompuServe.COM> writes:
>
> is that after I have tested the program successfully on DYNIX/ptx, Digital Unix
> and IBM AIX I was almost confident that it works fine, but... as soon as I tried
> it on Linux it mysteriously coredumped (with SIGSEGV). A few minutes of
> debugging with gdb(1) revealed the following:

You cannot depend on free() leaving the memory you free alone.
That's not a mystery, it's a bug in your program. The fact that some malloc
packages let you do that is mostly because some programs expect that
behavior...

NB, this is not a kernel issue. But you know that.

NB2, an iterative approach would be a better idea. Most C compiler don't
optimize tail recursion away.

NB3, if you really need a bug workaround, do something like this:

void free(void *what) {
static void *old_ptr = NULL;
static int (*libc_free)(void *what) = NULL;

if(libc_free == NULL)
libc_free = (typeof(libc_free))dlsym (RTLD_NEXT, "free");

if(old_ptr == what || what == NULL)
return;
if(old_ptr != NULL)
(*libc_free)(old_ptr);
old_ptr = what;
}

... which keeps the last freed pointer around a while longer and also
protects against duplicate invocations of free(), which is also a bug.

Inserting appropriate logging messages is left as an exercise.

You can compile the above as a dynamic library and LD_PRELOAD it.

-- 
Kleeneness is next to Godelness.
-- 
Matthias Urlichs         \  noris network GmbH  /  Xlink-POP Nürnberg 
Schleiermacherstraße 12   \   Linux+Internet   /   EMail: urlichs@noris.de
90491 Nürnberg (Germany)   \    Consulting+Programming+Networking+etc'ing
   PGP: 1024/4F578875   1B 89 E2 1C 43 EA 80 44  15 D2 29 CF C6 C7 E0 DE
       Click <A HREF="http://info.noris.de/~smurf/finger">here</A>.    42