help-gplusplus
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: string STL assignment in g++ shared object crashes with core


From: Paul Pluzhnikov
Subject: Re: string STL assignment in g++ shared object crashes with core
Date: Wed, 20 Sep 2006 20:02:39 -0700
User-agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Jumbo Shrimp, linux)

"Nilesh" <nileshg@gmail.com> writes:

> I am using my own shared object to link it dynamically to a program
> exe. The EXE makes a call to function in .so, in which l_str=
> "somestring"; code causes a core. 

Just *how* did you come to that conclusion?
None of the info you posted points to "l_str = ..." statement.
 
> the way I build .so is like this:
> ======================
> g++ -D_DEBUG -g -shared -o libiif.so -O3 -v -Wl,-bexpfull -Wl,-G
> -Wl,-brtl ../src/BMCIIF_Source.d -L/usr/lib/threads -L../lib_aix
> -L../lib -L/usr/local/lib -L/usr/lib  -lstdc++ -liiapi  -lm -lnsl
> -lpthread  -lnsl  -lm -lc -ltli

You appear to be using "unconventional" naming -- I assume
BMCIIF_Source.d is actually an object file.

Adding -lstdc++ and -lc is entirely bogus (g++ will add them itself),
but this shouldn't cause a crash.

Also, my (incomplete) understanding is that you do not need -brtl
when linking the shared object, only when linking the main exe. But
this should no cause a crash either.


> The way I use it in EXE is as follows:
> ============================
> g++ -o PROGRAMEXE../src/main.o -O3 -v  -L/usr/lib/threads
> -L/usr/local/lib -L/usr/lib -L./../../libs/aix -lstdc++ -lgcc -lgcc_eh
> -liiapi -lm -lnsl -lpthread -lc
> -Wl,-blibpath:/home/work/product/libs/aix -Wl,-brtl -liif

Again, -lstdc++ -lgcc -lgcc_eh and -lc are bogus.
What happens if you remove them all?

> After running this it gives a core at the source code containing
> following code in BMCIIF_Source.cpp:
> string l_str;
> l_str = "somethingstring";

You show absolutely no evidence that that source has anything to
do with the problem.

> The core trace shows:
> =================
> Program terminated with signal 11, Segmentation fault.
> #0  0xd025deb8 in ?? () from /usr/lib/libc.a(shr.o)

Gdb was not able to interpret core correctly.

I've seen this happen on aix, and switching to a different version
of gdb helps sometimes.

What happens if you run the program under gdb from the start?

Cheers,
-- 
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]