[EXRTranslator] translator causes BeOS built apps to crash

[deejam]

When changing the skin in CL-Amp the program crashes. The problem started with hrev39571. As discussed on ​Haikuware, this affects more software than just CL-Amp.

This is on r1a3, but it can be reproduced from hrev39571 until (at least) the current revision.

How to reproduce the problem

1. Download CL-Amp_v371_x86-inc-skin.zip (attached).
2. Unzip to preferred location.
3. Start CL-Amp.
4. Press alt+s (opens the Skin selector).
5. Select Nucleo NLog v102 .wsz.

CL-Amp crashes (see attached debug.txt).

6. Make a backup of /boot/system/add-ons/Translators/EXRTranslator.
7. Replace /boot/system/add-ons/Translators/EXRTranslator with EXRTranslator-hrev39570 (attached).
8. Perform steps 3-5 (CL-Amp will not crash).

9. Replace /boot/system/add-ons/Translators/EXRTranslator with EXRTranslator-hrev39571 (attached).
10. Perform steps 3-5 (CL-Amp will crash).

Thanks to hey68you who discovered that changing to an older EXRTranslator solves the problem.

[deejam]

Cl-Amp incl. the Nucleo NLog skin

[deejam]

EXRTranslator hrev39570

[deejam]

EXRTranslator hrev39571

[deejam]

Debug output

[ttcoder]

Sounds similar to #6963 (caused by #1259)

[pulkomandy]

Also happens with Opera for BeOS ( ​http://pulkomandy.lexinfo.fr/~beosarchive/www.emupt.com/beos/o/WORKING/Opera_for_BeOS_Installer-Final.bin , chmod+x the installer to run it)

Crashes in the same place :

#0  0x00b4a464 in __class_type_info::dcast () from /boot/system/lib/libroot.so
#1  0x00b4a471 in __class_type_info::dcast () from /boot/system/lib/libroot.so
#2  0x00b4aca6 in __throw_type_match_rtti () from /boot/system/lib/libroot.so
#3  0x00b48451 in __cplus_type_matcher () from /boot/system/lib/libroot.so
#4  0x00b46bf4 in __eh_rtime_match () from /boot/system/lib/libroot.so
#5  0x02026547 in EXRTranslator::DerivedIdentify () from /boot/system/add-ons/Translators/EXRTranslator
#6  0x02027d45 in BaseTranslator::BitsIdentify () from /boot/system/add-ons/Translators/EXRTranslator
#7  0x02027db4 in BaseTranslator::Identify () from /boot/system/add-ons/Translators/EXRTranslator
#8  0x0071251c in BTranslatorRoster::Private::Identify () from /boot/system/lib/libtranslation.so
#9  0x0071503d in BTranslatorRoster::Translate () from /boot/system/lib/libtranslation.so
#10 0x0070e820 in BTranslationUtils::GetBitmap () from /boot/system/lib/libtranslation.so
#11 0x003bc860 in OSplashView::AttachedToWindow ()
#12 0x005eb224 in BView::_Attach () from /boot/system/lib/libbe.so
#13 0x005e7c69 in BView::_AddChild () from /boot/system/lib/libbe.so
#14 0x005e7b01 in BView::AddChild () from /boot/system/lib/libbe.so
#15 0x005edd47 in BWindow::AddChild () from /boot/system/lib/libbe.so
#16 0x003bcd39 in ODoSplash ()
#17 0x00324348 in ShowSplashScreen ()
#18 0x002dfb9c in WinMain ()
#19 0x003abd8a in WApplication::MessageReceived ()
#20 0x00b50327 in thread_entry () from /boot/system/lib/libroot.so
#21 0x78033fec in ?? ()

[anevilyak]

Looked into it a little....oddly enough, simply replacing libilmimf.so with a debug build makes this problem magically go away. Leaving that one as a release build but adding in a debug version of EXRTranslator still results in the above backtrace, but indicates that frame 5 is at the return B_OK line at the end of that function. Quite curious.

[pulkomandy]

Noticed this happens with Sawteeth 1.2 (compiled under BeOS), but not a trunk build compiled under Haiku. There weren't too much changes in the code in between. So this only affects software built on BeOS.

[pulkomandy]

This is a problem for any BeOS app using the translation kit. I sugest we stop providing this translator for gcc2.

[Disreali]

Replying to pulkomandy:

This is a problem for any BeOS app using the translation kit. I sugest we stop providing this translator for gcc2.

So these issues are caused by the weak-signal support that was added in hrev39571?

If EXRTranslator is the only problem translator, then yes, it is reasonable for it to be excluded from gcc2 and gcc2-hybrid images.

[Disreali]

​JukeBox crashes on hrev43475-2hn because of this issue.

Is it really worth keeping the translator in the image if it is only going to cause many BeOS apps to crash, especially since the only way to get an affected BeOS app to work is to delete the translator.

[AGMS]

It also makes NetPenguin 1.64 (a graphical FTP client for BeOS) crash on startup, using Haiku R1A4.1.

[Giova84]

hrev45692. This bug still occurs. If i attempt to run an old BeOS app (eg Netpenguin) it will crash due EXRTranslator. If i remove EXRTranslator from /boot/system/add-ons/Translators Netpenguin will properly start.

[bonefish]

Given that the crash happens in the dynamic cast code, this is probably caused by an uninitialized type info. #1259 explains how this is possible. In this case we're talking about the std::exception type info, respectively the one of the derived class (if any) that is actually caught in EXRTranslator::DerivedIdentify().

[korli]

Replying to bonefish:

Given that the crash happens in the dynamic cast code, this is probably caused by an uninitialized type info. #1259 explains how this is possible. In this case we're talking about the std::exception type info, respectively the one of the derived class (if any) that is actually caught in EXRTranslator::DerivedIdentify().

Question: Would using "catch (...)" instead of "catch (const std::exception &e)" help to avoid using std::exception type info (provided it's not used anywhere else which I doubt)?

[bonefish]

I doubt it, but you can try.

[stippi]

I wasn't aware of the ticket, and found out BeOS apps crash this way when testing some PKGs, NetPenguin in my case. I seem to have had the same idea as korli in comment:14 and it does indeed fix the crash. At least I can run NetPenguin now on an image with this change. Closing ticket, please re-open if some apps still crash, or my testing has mislead me to believe the issue is fixed... I know it is not satisfying that what is probably the real bug (#1259) is not fixed.

Fixed in hrev46924.