[galib] galib246pre2 testing/error, more...

Michael Brady tirins.play at gmail.com
Sun Jan 23 14:51:09 EST 2005


Earlier I wrote...

I am testing your galib246pre2 on a Suse 9.1 (gcc 3.3.3) and an
getting segmentation faults in /lib/tls/libc.so.6 (_int_free()). I am
using GA1DArrayGenome...

Quite likely the error is in my code. However, I am using very high
level (stl, no overt pointers, etc.) code. I am tracing through with
gdb...

All of this to let you know. If you have seen/heard any evidence that
this segfault is related to 246pre2, please send me a note.

NOW I'm not too sure if it isn't an issue in galib246pre2. See thread below... 

Regards,

Michael
>>>

	
Chris Pritchard 	  May 12 2003, 4:25 am     show options
Newsgroups: comp.os.linux.development.apps
From: Chris Pritchard <c... at bakbone.co.uk> - Find messages by this author
Date: Mon, 12 May 2003 12:26:25 +0100
Local: Mon, May 12 2003 4:26 am
Subject: Re: Crashes in malloc() and free() on RedHat 9.0
Reply | Reply to Author | Forward | Print | Individual Message | Show
original | Report Abuse

I have resolved this issue, but still do not clearly understand it. My main
application did not make any calls to libc, but my shared library did. I
had forgotten to link my shared library against libc, but my application
did link against it. I reduced my application to a single call to a
function in my shared library (so there is no chance of memory corruption
here), and that library function called a libc function (in this case
fopen()). It would seem that the C library function then corrupted memory
themselves, since they would randomly crash from then on.

By adding -lc to the link line for my shared library there was no further
problem.

What on earth is going on??? The functions in libc were obviously being
resolved or I would have gotten runtime link errors...

Thanks,

Chris
<<< AND LATER IN THREAD >>>
 I have resolved this issue, but still do not clearly understand it.
I

think I might have worked it out. Just to clarify, the issue is:

* Main program doesn't use libc functions.

* Loadable shared object does use libc functions.

* Former dynamically loads the latter. Program crashes at call into
   libc functions.

* If you modify the main program to require a libc symbol, even if it
   never calls it, the problem goes away.

If so, I think the problem is that when the main program doesn't use any
libc symbols, the libc link is "optimised-away", and the libc startup
code never gets called. If so, you could probably fix it by including a
line like "extern void *malloc();" in your main code source.


More information about the galib mailing list