[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