Hyperion Entertainment Message Boards

Posted: **Sun Feb 23, 2014 1:10 pm**

I maintain (or rather, i try to) the port of ScummVM.

Lately i'm getting a crash which points to the very same address in the code (every single time)....unfortunately that happens randomly which is quite annyoing (one time the program starts up, the next time it crashes).
The port consists of different engines which can be left out through configure.

That crash address was pointing to one of those engines.
When i remove the engine it will point to the very same address as before...but this time inside the next engine in line and so forth.

So i'm assuming it's not something in the source that is crashing but rather a shared object thats acting up.
Because building the very same codebase (that crashed) without .so's works perfectly fine

My question is now, how can i debug such a case?

gdb is not very helpful as it tends to crash before the program

db101 asks me if it should load libstdc++ when it has load in all objects (after that it tells me the program has crashed - why i'm also pointing at libstdc++, but of course without any proof)
Unfortunately db101 will also crash/freeze if i try to look at the variables (the author is investigating)

Can anyone help me with this?
Is there some kind of shared objects debugging or is it planned to add such functionality to GrimReaper or shared objects?

What else can i do to debug?
The difference in size regarding shared objects is only marginal (2.5MB on a 40MB executeable), still i wouldn't want to completely drop .so's.
I like them

Thanks in advance

Posted: **Sun Feb 23, 2014 5:37 pm**

Mick raised an interesting question.

Do i need to add "-fPIC" every time i compile something with -use-dyn-ld?

and i know this is better suited in "General Developer Support"...sorry i missed that sub forum

Posted: **Sun Feb 23, 2014 6:32 pm**

Here is the crashlog...and it is indeed libstdc++ which is crashing

Hidden Text - Click to Show :

Posted: **Sun Feb 23, 2014 7:11 pm**

Raziel wrote:Mick raised an interesting question.

Do i need to add "-fPIC" every time i compile something with -use-dyn-ld?

No. You should only use -fPIC when you are compiling source code files to build a shared object. You should not use -fPIC for any other reason.

As a matter of fact if you want to build both a static library and a shared object from the same source code you have to compile it twice for this reason, once without -fPIC for the static library and once with -fPIC for the shared object.

Also it's -use-dynld, not -use-dyn-ld.

An option which might be worth adding if you are having problems with shared objects is "-Wl,--export-dynamic" (without the quotes). This should be added to the command line that is used to link the executable the same as -use-dynld (LDFLAGS is usually a good place for it).

Posted: **Sun Feb 23, 2014 8:33 pm**

@salass00

Thanks for the hints, i will try that

Yes the dynld was a typo of mine i have it right in the CPPFLAGS

Posted: **Mon Feb 24, 2014 10:30 am**

salass00 wrote: An option which might be worth adding if you are having problems with shared objects is "-Wl,--export-dynamic" (without the quotes). This should be added to the command line that is used to link the executable the same as -use-dynld (LDFLAGS is usually a good place for it).

The crash is gone.

I have to check with further updates to the code and more builds, but so far it works

Thank you very much for the hint

Posted: **Tue Feb 25, 2014 8:14 am**

Too early i'm afraid

After some more commits to the code it's again crashing with the exact same address and libstdc++.so

There seems to be something else causing it, probably a bug in libsrdc++ together with pthreads!?

Posted: **Tue Feb 25, 2014 6:38 pm**

Raziel wrote:There seems to be something else causing it, probably a bug in libsrdc++ together with pthreads!?

See here -> http://solie.ca/articles/map/threading/threading.html

Posted: **Wed Feb 26, 2014 9:48 pm**

ssolie wrote:
Raziel wrote:There seems to be something else causing it, probably a bug in libsrdc++ together with pthreads!?
See here -> http://solie.ca/articles/map/threading/threading.html

I see, thanks for the link Steven

I need to check if pthreads.so is built into the shared version of ScummVM.
If i understand you correctly than even if no pthread.so is used, the pogram itself may handle threadin internally, which in turn can still crash?

What if i link pthread (and only pthread) statically rather than as a shared object?
Would that work, or do i have to try it out myself?

Are there plans to support (shared) threading on amigaos4 at one day?

Thanks for all the help guys, will check in with the ScummVM devs to see if i can draw any more information

Posted: **Wed Feb 26, 2014 10:52 pm**

Raziel wrote:What if i link pthread (and only pthread) statically rather than as a shared object?

I don't think you understand. As long as "g++ -v" returns "Thread model: single" the C++ language itself and the C++ standard library are not thread aware. You will mistakenly believe everything is fine until a C++ exception is thrown in one thread and is caught in another thread (i.e. undefined behaviour).

The easiest workaround is to compile your C++ project with no threading support. Another workaround is to turn off C++ exceptions and RTTI support (both optional language features).

If anybody would like to work on creating a C++ compiler which is thread aware, the source code is available on SourceForge.

Hyperion Entertainment Message Boards

Help with debugging a shared objects(?) crash

Help with debugging a shared objects(?) crash

Re: Help with debugging a shared objects(?) crash

Re: Help with debugging a shared objects(?) crash

Re: Help with debugging a shared objects(?) crash

Re: Help with debugging a shared objects(?) crash

Re: Help with debugging a shared objects(?) crash

Re: Help with debugging a shared objects(?) crash

Re: Help with debugging a shared objects(?) crash

Re: Help with debugging a shared objects(?) crash

Re: Help with debugging a shared objects(?) crash