BTranslationUtils::GetBitmap() segfaults in EXRTranslator::DerivedIdentify()

[ttcoder]

When launching TS (TuneStacker) it crashes as it tries to load its PNG ressources.

This is from a nightly I've installed to a partition, from this file: haiku-nightly-hrev39648-x86gcc2hybrid-raw.tar.xz

I'm picking "Translator Add-ons" for category for now, though this might be libroot.so or something else (see notes).

Notes:

• TS no longer crashes if I delete the translator at /boot/system/add-ons/Translators/EXRTranslator
• TS crashes in nightly hrev39648 but did not crash in R1/alpha2
• another app I have doing the same gig (loading PNG images from its ressources, though of a different origin) works fine in nightly.
• I've looked thoroughly in the source browser and to the best of my understanding, the code referred to in the back trace (methods in class BaseTranslator ..etc) seems to have not changed since 3 years ago or whereabouts, so it's hard to say why it has regressed in the last few months.. It might be exception related though, maybe the exception throwing mechanism has changed and crashes the "catch" statement in EXRTranslator::DerivedIdentify() ?

[bonefish]

Might be related to the changes for weak symbol support (hrev39571). If you could try an earlier Haiku revision (replacing the runtime_loader should suffice, I think), that would help to support/disprove the suspicion. At any event, a test case would be great. Ideally a minimal test case, e.g. just a main() loading the resources.

[korli]

Replying to bonefish:

Might be related to the changes for weak symbol support (hrev39571).

I thought weak symbol support only affected gcc4 build. It affects also gcc2 then.

[ttcoder]

I've checked haiku-files.org but builds only go back one week or so, 39571 is no longer there. And I'm not setup for building from source..

So I've prepared a bare-bones test case this morning, and found something interesting: the crash only occurs if I link against my KISSlib.so (even though it's not used at all in this test case); if I remove the -lKISSlib parameter when building, the crash no longer occurs.

Here's an 'overview' of the zip-file I'm going to upload, tell me if it's useful for you to troubleshoot this problem or if I should investigate more on my own (and if yes, how -- I dunno where to take it from here :-)..

~/_develop/BeOSRADIO_scripter/test-case_ticket-6963> ls -R 
.: 
Application.cpp  Application.o  TuneStacker.rsrc  probably_not_useful 
Application.h    TuneStacker    lib 
 
./lib: 
KISSlib.so 
 
./probably_not_useful: 
Jamfile 
~/_develop/BeOSRADIO_scripter/test-case_ticket-6963> head -25 Application.cpp  
 
/* 
For convenience, here's a few lines on which to do "Command-Enter" in Pe 
(first line will have to be edited of course): 
 
INIT: 
cd /boot/home/_develop/test-case_ticket-6963 
 
BUILD: 
gcc -c -o Application.o -I. Application.cpp 
gcc  -o TuneStacker  Application.o lib/KISSlib.so -lbe -ltranslation   
xres -o TuneStacker TuneStacker.rsrc  
 
Exec: 
./TuneStacker 
 
        --> Boom, on execution TuneStacker segfaults with this gdb output: 
                [Switching to team ./TuneStacker (1832) thread TuneStacker (1832)]  
                0x005259f0 in __class_type_info::dcast () from /boot/system/lib/libroot.so  
 
*/ 
 
 
// libroot.so 
#include <stdio.h>

[ttcoder]

On second thought, can't hurt to to provide the test-case immediately

[bonefish]

Replying to korli:

Replying to bonefish:

Might be related to the changes for weak symbol support (hrev39571).

I thought weak symbol support only affected gcc4 build. It affects also gcc2 then.

Both support for weak symbols and symbol preemption are implemented in the runtime loader and should work for gcc 2 as well. The latter will have no effect, since our gcc 2 links with -Bsymbolic. Due to -Bsymbolic the resolution of weak symbols should also work the same in almost all cases. Only when a weak symbol is overridden by a global one (I believe something that doesn't even happen unless the developer explicitly creates such a situation), the behavior is different now (i.e. correctly resolving to the global symbol). If anything that should only improve things. I wouldn't rule out that I have overlooked something or screwed something up.

Replying to ttcoder:

I've checked haiku-files.org but builds only go back one week or so, 39571 is no longer there. And I'm not setup for building from source..

There are older ones available -- you probably just missed the "Show all files ..." link at the bottom of the page. The closest one is ​http://haiku-files.org/raw/haiku-nightly-r39567-x86gcc2hybrid-raw.tar.xz.

So I've prepared a bare-bones test case this morning, and found something interesting: the crash only occurs if I link against my KISSlib.so (even though it's not used at all in this test case); if I remove the -lKISSlib parameter when building, the crash no longer occurs.

Here's an 'overview' of the zip-file I'm going to upload, tell me if it's useful for you to troubleshoot this problem or if I should investigate more on my own (and if yes, how -- I dunno where to take it from here :-)..

Thanks! If I can reproduce the bug with the attached objects, that should suffice to track it down. Will try to make some time soon.

[bonefish]

The main cause is that KISSlib.so has apparently been built under BeOS. It contains a type info for std::exception, but no type info function. This triggers the issue described in #1259.

The likely reason why the issue didn't show in earlier revisions is the second part of hrev39375. It's actually not even directly related to the weak symbol or symbol preemption features. It just changes the symbol resolution order to one that should be somewhat more robust when add-ons are involved. It could be reverted for gcc 2, but that would only fix this particular situation and might break using your library in a different situation instead. So I don't think there's much point in doing that.

Possible solutions for your problem:

• Preferred: Fixing #1259.
• Rebuilding KISSlib.so under Haiku.
• Could work: Build your application under BeOS. This would trigger Haiku's runtime loader's compatibility mode which might work around the issue.

Closing as duplicate of #1259.

[ttcoder]

Glanced too fast at the nightlies: indeed they go back, way way back!

Segfault-wise, I checked and the behavior is the same, whether TuneStacker is built on BeOS R5 or Haiku. But re-building the kisslib on Haiku indeed fixes the problem! So that's another workaround I have now for continuing testing, thanks.

Will keep an eye on #1259 anyhow.

[stippi]

While #1259 has not been fixed, yet, the symptoms observed in this bug have been fixed in hrev46924. (Note the link for the commit does not resolve to the actual commit which fixed it.)