Rtld does not set FD_CLOEXEC on its internal file descriptors;
therefore, such a file descriptor may be passed to a process created by
another thread running in parallel to dlopen() or fdlopen().
The race is easy to trigger with the below dlopen_exec_race.c that
performs the two in parallel
On Sun, Nov 04, 2012 at 03:37:27PM +0100, Jilles Tjoelker wrote:
Rtld does not set FD_CLOEXEC on its internal file descriptors;
therefore, such a file descriptor may be passed to a process created by
another thread running in parallel to dlopen() or fdlopen().
The race is easy to trigger
dlopen()/dlclose(). The real question is
whether they're interesting in supporting this model.
If the Firebird folks aren't interested in having their
library be accessible in that fashion, then you have
little choice but to simply forgo unloading this particular
library.
It's a bit unfortunate
Tim Kientzle writes:
I would be curious to see the results of running your
sample program (with lots of extra fprint(stderr...)
calls, of course) on Linux to see whether it calls the
registered exit function at dlclose time or never.
I suspect the answer is never. If I'm right, the
Also, I'm wondering how other OSes handle this. I don't see this
code crash on Linux, contrary to its design as you say.
I would be curious to see the results of running your
sample program ... on Linux to see whether it calls the
registered exit function at dlclose time or never.
Linux
On Jan 1, 2008, at 19:41 , Tim Kientzle wrote:
Also, I'm wondering how other OSes handle this. I don't see this
code crash on Linux, contrary to its design as you say.
I would be curious to see the results of running your
sample program ... on Linux to see whether it calls the
registered
Hi,
I've been redirected by Giorgos Keramidas to this list after reporting
a problem on the freebsd-questions list. I'd greatly appreciate if you
could have a look at the following problem. Apparently programs are
doomed to segfault on FreeBSD if dlopen()ed modules install exit
handlers via
are
doomed to segfault on FreeBSD if dlopen()ed modules install exit
handlers via atexit(). Similar problem reports have cropped up before,
see e.g.
http://www.imagemagick.org/pipermail/magick-developers/2006-March/002523.html
My system runs:
FreeBSD yeti.mininet 6.1-RELEASE FreeBSD 6.1
Markus Hoenicka wrote:
I've been redirected by Giorgos Keramidas to this list after reporting
a problem on the freebsd-questions list. I'd greatly appreciate if you
could have a look at the following problem. Apparently programs are
doomed to segfault on FreeBSD if dlopen()ed modules install
Alexander Kabaev writes:
As designed. atexit should not be used by shared objects that do not
expect themselves to live until actual exit() happens. ELF provides
proper _init/_fini sections to support shared object
initialization/destruction.
That is, the only real solution to this
Markus Hoenicka wrote:
Alexander Kabaev writes:
As designed. atexit should not be used by shared objects that do not
expect themselves to live until actual exit() happens. ELF provides
proper _init/_fini sections to support shared object
initialization/destruction.
That is, the only
On Monday 31 December 2007 05:20:51 pm Julian Elischer wrote:
Markus Hoenicka wrote:
Alexander Kabaev writes:
As designed. atexit should not be used by shared objects that do not
expect themselves to live until actual exit() happens. ELF provides
proper _init/_fini sections to
On Mon, 31 Dec 2007 14:20:51 -0800
Julian Elischer [EMAIL PROTECTED] wrote:
Markus Hoenicka wrote:
Alexander Kabaev writes:
As designed. atexit should not be used by shared objects that do
not expect themselves to live until actual exit() happens. ELF
provides proper _init/_fini
Alexander Kabaev wrote:
On Mon, 31 Dec 2007 14:20:51 -0800
Julian Elischer [EMAIL PROTECTED] wrote:
Markus Hoenicka wrote:
Alexander Kabaev writes:
As designed. atexit should not be used by shared objects that do
not expect themselves to live until actual exit() happens. ELF
provides
folks. I'm just trying to use their client library in a dlopen()ed
module, and I was investigating whether something can be done from the
FreeBSD end. I've also forwarded Alexander's reply to the Firebird
folks for consideration.
regards,
Markus
--
Markus Hoenicka
[EMAIL PROTECTED]
(Spam-protected
real solution to this problem is to convince the
Firebird folks to remove their atexit() calls from the client
libraries?
I suspect they never considered that their dynamic library
might be used via dlopen()/dlclose(). The real question is
whether they're interesting in supporting this model
On Fri, 30 Nov 2007 19:02:01 +0200
Kostik Belousov [EMAIL PROTECTED] wrote:
On Fri, Nov 30, 2007 at 01:28:58PM -0300, Alejandro Pulver wrote:
Hello.
When I was updating the games/deng port, I found it failed at runtime
with the following error:
% doomsday
While opening dynamic
, of course) would be to make
dlopen() resolve these symbols to the main executable. I tried to do
this with RTLD_GLOBAL without success.
The port is available here (note that the application uses cmake to
build):
ftp://ftp.alepulver.com.ar/deng.tar.bz2
If you need any other information just ask me
ArgExists
The files are linked with the -flat namespace and -undefined
suppress flags in Mac OS X (don't know if it's relevant here).
I think the simplest solution (if possible, of course) would be to make
dlopen() resolve these symbols to the main executable. I tried to do
this with RTLD_GLOBAL
On Fri, Nov 30, 2007 at 04:40:33PM -0300, Alejandro Pulver wrote:
On Fri, 30 Nov 2007 19:02:01 +0200
Kostik Belousov [EMAIL PROTECTED] wrote:
On Fri, Nov 30, 2007 at 01:28:58PM -0300, Alejandro Pulver wrote:
Hello.
When I was updating the games/deng port, I found it failed at
On Fri, 30 Nov 2007 22:19:48 +0200
Kostik Belousov [EMAIL PROTECTED] wrote:
On Fri, Nov 30, 2007 at 04:40:33PM -0300, Alejandro Pulver wrote:
On Fri, 30 Nov 2007 19:02:01 +0200
Kostik Belousov [EMAIL PROTECTED] wrote:
On Fri, Nov 30, 2007 at 01:28:58PM -0300, Alejandro Pulver wrote:
On Fri, 24 Mar 2006 10:48:34 +0200
Kostik Belousov [EMAIL PROTECTED] wrote:
I did understand the purpose of the thread mask code in
libexec/rtld/rtld_lock.c, or, more precisely, the condition where
this code works (for the context, see the mails with same subject on
freebsd-hackers).
Look,
在 Saturday 25 March 2006 23:07，Alexander Kabaev 写道：
The thread mask only makes sense when flags are per-thread. I meant
to use it to detect PLT recursions from locking primitives exported to
rtld by the threads library as those are not allowed and threads
implementations are required to take
I did understand the purpose of the thread mask code in
libexec/rtld/rtld_lock.c, or, more precisely, the condition where this code
works (for the context, see the mails with same subject on freebsd-hackers).
Look, that code assumes that blocking async signals would stop thread
scheduler from
在 Friday 24 March 2006 16:48，Kostik Belousov 写道：
I did understand the purpose of the thread mask code in
libexec/rtld/rtld_lock.c, or, more precisely, the condition where this code
works (for the context, see the mails with same subject on freebsd-hackers).
Look, that code assumes that
Kostik Belousov wrote:
I did understand the purpose of the thread mask code in
libexec/rtld/rtld_lock.c, or, more precisely, the condition where this code
works (for the context, see the mails with same subject on freebsd-hackers).
Look, that code assumes that blocking async signals would
On Fri, Mar 24, 2006 at 08:54:34PM +0900, Kazuaki Oda wrote:
* The current implementation of rtld has a problem both with
libpthread and libthr. It works only with libc_r.
It doesn't work correctly with libc_r. Concurrent dlopen and dlclose of
the same shared object doesn't work fully
On Fri, Mar 24, 2006 at 08:54:34PM +0900, Kazuaki Oda wrote:
Kostik Belousov wrote:
I did understand the purpose of the thread mask code in
libexec/rtld/rtld_lock.c, or, more precisely, the condition where this code
works (for the context, see the mails with same subject on
. Concurrent dlopen and dlclose of
the same shared object doesn't work fully corretly ATM, but the patch
isn't the best approach either.
Joerg
You promised the patch. Anyway, part of my patch that touched rtld_lock.c
shall be discarded.
pgpTpwnFEZHaM.pgp
Description: PGP signature
, try the following patch and report results. I can run (modified *)
version of your test for some time without crash with both libpthread
and libthr.
[* You need to allow for errors in dlopen and just continue the loop.]
Patch protects access to the list of unloading objects by bind lock,
and marks
On Thu, Mar 23, 2006 at 12:54:40PM +0200, Kostik Belousov wrote:
On Thu, Mar 23, 2006 at 05:57:24AM +0900, Kazuaki Oda wrote:
BTW do you know the reason why lock is released before calling
objlist_call_fini()? If we don't release the lock, what problem will
occur? deadlock?
The reasoning
(modified *)
version of your test for some time without crash with both libpthread
and libthr.
[* You need to allow for errors in dlopen and just continue the loop.]
Patch protects access to the list of unloading objects by bind lock,
and marks the objects that are running finalizers to prevent
*/
exit(0);
}
void *func(void *dummy)
{
void *h;
for (;;) {
if ((h = dlopen(/usr/lib/libm.so, RTLD_NOW)) == NULL)
errx(1, dlopen: %s, dlerror());
if (dlclose(h) == -1)
errx(1, dlclose: %s, dlerror());
}
/* NOTREACHED */
return (NULL
, pthread_create);
}
for (;;)
sleep(1);
/* NOTREACHED */
exit(0);
}
void *func(void *dummy)
{
void *h;
for (;;) {
if ((h = dlopen(/usr/lib/libm.so, RTLD_NOW)) == NULL)
errx(1, dlopen: %s, dlerror());
if (dlclose(h) == -1
= pthread_create(tids[i], NULL, func, NULL);
if (error)
errc(1, error, pthread_create);
}
for (;;)
sleep(1);
/* NOTREACHED */
exit(0);
}
void *func(void *dummy)
{
void *h;
for (;;) {
if ((h = dlopen(/usr/lib/libm.so
Kostik Belousov wrote:
Oops. Completely reversed condition in the if. :(. Also, I don't think it
shall returns the error in this situation. New take:
Index: libexec/rtld-elf/rtld.c
===
RCS file:
Below is a little snipper that tries to dlopen(argv[1]).
It works fine until it is compiled with profiling support, -pg flag.
Compiled with -pg, dlopen() reports Service unavailable.
How to fix that ?
-sergey
#include dlfcn.h
#include stdlib.h
#include stdio.h
int main(int argc, char *argv
-pg on your system implies static linking. dlopen() is not available in
statically linked binaries on FreeBSD and many other systems.
Consider building your binary dynamic by making sure there is a dynamic
version of libc with profiling support (something like /usr/lib/libc_p.so).
Otherwise
Absolutely.
thanks, that helps!
On Wed, Dec 03, 2003 at 02:23:18AM -0800, Lev Walkin wrote:
-pg on your system implies static linking. dlopen() is not available in
statically linked binaries on FreeBSD and many other systems.
Consider building your binary dynamic by making sure
Hi,
I would like to know where are the dlopen()/dlsym()/etc sources ?
There's nothing in the libc sources :/
(I'm using the HEAD tree)
-- Aurelien
msg39153/pgp0.pgp
Description: PGP signature
Aurelien Nephtali wrote:
I would like to know where are the dlopen()/dlsym()/etc sources ?
There's nothing in the libc sources :/
(I'm using the HEAD tree)
src/lib/csu/common/crtbegin.c
src/lib/csu/i386/crt0.c
src/lib/csu/i386-elf/crt1.c
That's the glue. The actual functions are mapped
Greetings all,
I wish to accomplish the following:
1. Program foo loads shared object bar using dlopen() and
dlsym()
2. bar needs certain symbols resolved, which foo intercepts.
For example, foo might wrap malloc() or open() to provide its
own behavior... much like subclassing window
* E.B. Dreger [EMAIL PROTECTED] [020402 10:29] wrote:
Greetings all,
I wish to accomplish the following:
1. Program foo loads shared object bar using dlopen() and
dlsym()
2. bar needs certain symbols resolved, which foo intercepts.
For example, foo might wrap malloc() or open
Date: Tue, 2 Apr 2002 11:05:52 -0800
From: Alfred Perlstein [EMAIL PROTECTED]
From the dlopen manpage:
I reread that right before initial post.
If dlsym() is called with the special handle RTLD_NEXT, then the search
for the symbol is limited to the shared objects which were
Date: Tue, 2 Apr 2002 11:05:52 -0800
From: Alfred Perlstein [EMAIL PROTECTED]
From the dlopen manpage:
[ snip ]
Works great, less coding.
Looks like I just misunderstood the manpage and/or the workings
of the dynamic linker.
Time for me to have some fun. And, no, I'm not using wrappers
. This is arguably a linker bug, since it's not reporting
missing symbols at link time. You can recreate this without shared
objects that you are going to dlopen, simply by creating a shared
library that references symbols in a second shared library (no
static data references!), and then using
Hello John,
John, is it possible to find out in dlopen() which object in the
linked list has issued the dlopen() call? Then a fix would be easy.
Yes, it's possible to find out which shared object the dlopen call
was made from. There's already a function obj_from_addr() in rtld.c
which
On Fri, 1 Feb 2002 20:24:33 -0800 (PST), John Polstra [EMAIL PROTECTED] wrote:
If you're talking about efficiency, it doesn't matter very much. It's
a rare program that loads more than, say, 20 shared libraries.
We have an application toolchain which basically puts each object into
its own
Hello John,
Yes, it's possible to find out which shared object the dlopen call
was made from. There's already a function obj_from_addr() in rtld.c
which does that. But as far as I know, it is not standard behavior to
search the RPATH of the object which issued the dlopen call.
I only have
Bjoern Fischer wrote:
Yes, it's possible to find out which shared object the dlopen call
was made from. There's already a function obj_from_addr() in rtld.c
which does that. But as far as I know, it is not standard behavior to
search the RPATH of the object which issued the dlopen call
Hello there,
I have a problem with dlopen() on FreeBSD: When dlopen()ed
shared objects dlopen() a shared object themselves, the DT_RPATH,
that is hardcoded into the first dlopen()ed object is *not*
searched.
This can be easily demonstated with the tiny (0.8k) example
I attached to this mail
On Fri, Feb 01, 2002 at 09:10:18PM +0100, Bjoern Fischer wrote:
I have a problem with dlopen() on FreeBSD: When dlopen()ed
shared objects dlopen() a shared object themselves, the DT_RPATH,
that is hardcoded into the first dlopen()ed object is *not*
searched.
Ok, I've looked into /usr/src
In article [EMAIL PROTECTED],
Bjoern Fischer [EMAIL PROTECTED] wrote:
On Fri, Feb 01, 2002 at 09:10:18PM +0100, Bjoern Fischer wrote:
I have a problem with dlopen() on FreeBSD: When dlopen()ed
shared objects dlopen() a shared object themselves, the DT_RPATH,
that is hardcoded
On Thu, Jan 04, 2001 at 10:19:56AM -0800, Doug White wrote:
No. The linux compatbility is through the image activator. The syscalls
have to be translated, otherwise if you were running as root and loaded a
linux lib into a freebsd binary, then that lib called fcntl(), your system
would
On Thu, Jan 04, 2001 at 10:19:56AM -0800, Doug White wrote:
1) Can a native binary dlopen a Linux ELF GL, yes or no?
No. The linux compatbility is through the image activator. The syscalls
have to be translated, otherwise if you were running as root and loaded a
linux lib into a freebsd
On Tue, 2 Jan 2001, Rafael Barrero wrote:
Hi all,
Two questions:
0) Are native binaries for OpenBSD different from FreeBSD?
Yes.
1) Can a native binary dlopen a Linux ELF GL, yes or no?
No. The linux compatbility is through the image activator. The syscalls
have to be translated
Hi all,
Two questions:
0) Are native binaries for OpenBSD different from FreeBSD?
1) Can a native binary dlopen a Linux ELF GL, yes or no?
Rafael Barrero
[EMAIL PROTECTED]
"You know ... you take the killing for granted. And then it's gone, and you're like,
'I wish I'd appreciated it
Rafael Barrero [EMAIL PROTECTED] wrote:
0) Are native binaries for OpenBSD different from FreeBSD?
Yes.
--
Christian "naddy" Weisgerber [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Greetings.
Is it safe to remove the *.so file after it is loaded
into the process space and addresses to its
functions are gotten?
I've tested this and have no problems so far.
I need this to implement the "hot swap" of the
dynamic loading libraries.
Thanks,
Dmitry
To Unsubscribe: send
Dmitry Sychov wrote:
Greetings.
Is it safe to remove the *.so file after it is loaded
into the process space and addresses to its
functions are gotten?
It's safe to remove it as soon as it's been opened.
The file will still exist in the filesystem, only there won't be any
references to it
On Thu, Nov 23, 2000 at 01:40:34PM +, Konstantin Chuguev wrote:
Dmitry Sychov wrote:
Greetings.
Is it safe to remove the *.so file after it is loaded
into the process space and addresses to its
functions are gotten?
It's safe to remove it as soon as it's been opened.
The file
hi, there!
On Wed, 22 Nov 2000, Dmitry Sychov wrote:
Is it safe to remove the *.so file after it is loaded
into the process space and addresses to its
functions are gotten?
yes
/fjoe
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the
FreeBSD box nearby):
For all dynamically loaded modules:
dlopen() opens the file (gets a file descriptor) and mmaps it (possibly
excluding the debug and some other sections). dlclose() unmaps and closes it.
For shared libraries:
__init() code of the binary executable dlopen()'s all the libraries
modules:
dlopen() opens the file (gets a file descriptor) and mmaps it (possibly
excluding the debug and some other sections). dlclose() unmaps and closes it.
Not quite. The dynamic linker opens the file, mmaps it, and closes
it immediately. A mapping created by mmap endures even after you
close
Ciao!
I have an ObjC shared object compiled in this way:
gcc -shared -rdynamic -o Bundle BreakTest.o SetTestCase.o -lSenFoundation
-lSenTestingKit
When I load this object with dlopen() the __objc_exec_class() initializer
of the libraries's classes are called first than the objc initializers
In article [EMAIL PROTECTED],
[EMAIL PROTECTED] wrote:
I have an ObjC shared object compiled in this way:
gcc -shared -rdynamic -o Bundle BreakTest.o SetTestCase.o -lSenFoundation
-lSenTestingKit
When I load this object with dlopen() the __objc_exec_class() initializer
On Mon, Sep 04, 2000 at 11:16:17PM -0500, Michael Owens wrote:
[...]
-Wl,export-dynamic, but still have not seemed to resolve the problem: when the
program calls dlopen to load the library, it returns
./libcircle.so: Undefined symbol "__pure_virtual"
It seems that this is a li
I am trying an example I got from a magazine originally written for Linux
which dynamically loads shared libraries and instantiates C++ classes within
them. Being a recent FreeBSD convert, I intended to run this example on it.
However, I am having a problem. I did read the man page for dlopen
Daniel O'Connor writes:
On 20-Jul-00 Raymond Wiker wrote:
Is it possible, at all, to use dlopen etc from a
statically-linked executable? My experiments with FreeBSD-4.0 (see
below) indicate that it's not possible.
You can't do it from a statically linked binary, however
On Sat, 22 Jul 2000, Daniel O'Connor wrote:
On 20-Jul-00 Raymond Wiker wrote:
Is it possible, at all, to use dlopen etc from a
statically-linked executable? My experiments with FreeBSD-4.0 (see
below) indicate that it's not possible.
You can't do it from a statically linked
[ Re-sent, as it seemed to get lost on my first try. ]
Is it possible, at all, to use dlopen etc from a
statically-linked executable? My experiments with FreeBSD-4.0 (see
below) indicate that it's not possible.
The reason that I'd like this to work is that SBCL (a Common
"Raymond" == Raymond Wiker [EMAIL PROTECTED] writes:
Raymond raw : ~ $ cat dltest.c
Raymond #include dlfcn.h
Raymond #include stdio.h
Raymond main()
Raymond {
Raymond void *handle;
Raymond void *sym;
Raymond handle = dlopen(0, RTLD_LAZY);
On 20-Jul-00 Raymond Wiker wrote:
Is it possible, at all, to use dlopen etc from a
statically-linked executable? My experiments with FreeBSD-4.0 (see
below) indicate that it's not possible.
You can't do it from a statically linked binary, however you can create a
dynamic executable
passing 0 for handle should
have the same effect as passing 0 as the path to dlopen; i.e, to
access the symbol table for the running program.
--
Raymond Wiker
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
In article [EMAIL PROTECTED],
Max Khon [EMAIL PROTECTED] wrote:
Are there any plans to implement RTLD_NODELETE and RTLD_NOLOAD mode
flags for dlopen?
I wasn't aware of them, but it looks like they would be easy to
implement. Could you please file a PR with send-pr and tell me the
PR number
-On [2526 16:22], Max Khon ([EMAIL PROTECTED]) wrote:
Are there any plans to implement RTLD_NODELETE and RTLD_NOLOAD mode
flags for dlopen?
Not sure, buy maybe John Polstra can answer this one. CC:'d.
from Solaris 2.6 man 3X dlopen:
The following modes provide additional capabilities
hi, there!
Are there any plans to implement RTLD_NODELETE and RTLD_NOLOAD mode
flags for dlopen?
from Solaris 2.6 man 3X dlopen:
The following modes provide additional capabilities outside
of relocation processing:
RTLD_NODELETE The specified object will not be deleted
#include stdlib.h
#include dlfcn.h
int main() {
void *handle;
void (*myhellofunc)(void);
char *c;
handle = dlopen(NULL, 1);
c = dlerror();
if (c) abort_with_error(c);
myhellofunc = dlsym(handle, "_helloworld");
c = dlerror();
if(c
ing of two source files
and a makefile
file1.c
---
#include stdio.h
#include stdlib.h
#include dlfcn.h
int main() {
void *handle;
void (*myhellofunc)(void);
char *c;
handle = dlopen(NULL, 1);
c = dlerror();
if (c) abort_with_error(c);
m
hi, there!
On Mon, 1 Nov 1999, John Polstra wrote:
Are there any plans to implement RTLD_GLOBAL/RTLD_LOCAL mode flags for
dlopen?
RTLD_GLOBAL has been supported in -current since around the
beginning of September.
great. I think that manpage should be brought up to date
with -current
In article [EMAIL PROTECTED],
Max Khon [EMAIL PROTECTED] wrote:
Are there any plans to implement RTLD_GLOBAL/RTLD_LOCAL mode flags for
dlopen?
RTLD_GLOBAL has been supported in -current since around the
beginning of September.
What is RTLD_LOCAL, and which OS supports it? I've never heard
hi, there!
Are there any plans to implement RTLD_GLOBAL/RTLD_LOCAL mode flags for
dlopen?
/fjoe
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
In article pine.bsf.4.05.9906291726460.1300-100...@iclub.nsu.ru,
Max Khon f...@iclub.nsu.ru wrote:
in the following code `dlopen' returns NULL
on the first iteration (because g() is not defined) -- it's ok
but on the second iteration `dlopen' returns valid dlh
ELF or a.out? Which version
hi, there!
On Wed, 30 Jun 1999, John Polstra wrote:
in the following code `dlopen' returns NULL
on the first iteration (because g() is not defined) -- it's ok
but on the second iteration `dlopen' returns valid dlh
ELF or a.out? Which version of FreeBSD?
For a.out, it's a known bug
as the resposible
person. Please be sure to state that it's the ELF dynamic linker.
If you're in a big hurry and would like to work on it yourself, the
relevant code is in src/libexec/rtld-elf/rtld.c in the function
dlopen() near the comment that says XXX - Clean up properly after an
error
hi, there!
in the following code `dlopen' returns NULL
on the first iteration (because g() is not defined) -- it's ok
but on the second iteration `dlopen' returns "valid" dlh
I need the code like this to load some functions dynamically.
The code below shows that it's unable to ensur
hi, there!
in the following code `dlopen' returns NULL
on the first iteration (because g() is not defined) -- it's ok
but on the second iteration `dlopen' returns valid dlh
I need the code like this to load some functions dynamically.
The code below shows that it's unable to ensure that all
In article 37458ff0.fc9b2...@cablenet.net,
Damian Hamill dam...@cablenet.net wrote:
I have found the problem and it is a problem with make. By chance I did
an ls -l of the directory and noticed the shared object was only 371
bytes and thought no that can't be right.
Thanks for
trap.
#0 0x800b728 in _kill ()
(gdb) bt
#0 0x800b728 in _kill ()
#1 0x800b34c in abort ()
#2 0x8004aa2 in __assert ()
#3 0x8003b4b in map_object ()
#4 0x8002e9e in find_symdef ()
#5 0x800334d in dlopen ()
#6 0x8049a68 in Get_SQL_Driver (name=0x804c7e4 mysql) at Vdb.c:150
#7
with signal 6, Abort trap.
#0 0x800b728 in _kill ()
(gdb) bt
#0 0x800b728 in _kill ()
#1 0x800b34c in abort ()
#2 0x8004aa2 in __assert ()
#3 0x8003b4b in map_object ()
#4 0x8002e9e in find_symdef ()
#5 0x800334d in dlopen ()
#6 0x8049a68 in Get_SQL_Driver (name=0x804c7e4
.
#0 0x800b728 in _kill ()
(gdb) bt
#0 0x800b728 in _kill ()
#1 0x800b34c in abort ()
#2 0x8004aa2 in __assert ()
#3 0x8003b4b in map_object ()
#4 0x8002e9e in find_symdef ()
#5 0x800334d in dlopen ()
#6 0x8049a68 in Get_SQL_Driver (name=0x804c7e4 mysql) at Vdb.c
0x800b728 in _kill ()
#1 0x800b34c in abort ()
#2 0x8004aa2 in __assert ()
#3 0x8003b4b in map_object ()
#4 0x8002e9e in find_symdef ()
#5 0x800334d in dlopen ()
#6 0x8049a68 in Get_SQL_Driver (name=0x804c7e4 mysql) at Vdb.c:150
#7 0x8049ff9 in GetDefaultDriver () at Vdb.c:254
#8
in map_object ()
#4 0x8002e9e in find_symdef ()
#5 0x800334d in dlopen ()
#6 0x8049a68 in Get_SQL_Driver (name=0x804c7e4 mysql) at Vdb.c:150
#7 0x8049ff9 in GetDefaultDriver () at Vdb.c:254
#8 0x804a141 in VdbInit (user=0x804bfb1 nobody, passwd=0x0) at
Vdb.c:329
#9 0x8049316 in main ()
#10 0x8048be5
-
and here's the ld line for the shared object I am loading;
ld -Bshareable -o $@ $ -u _floor ../../lib/libV.a
/usr/local/lib/mysql/libmysqlclient.a /usr/lib/libm.a
This is probably unrelated to the bug (but it might be related).
Are
94 matches
Mail list logo
