[PackageBuilder] crash on File->Open

[diver]

PackageBuilder and many other BeOS apps crash on file dialog, see back trace.

[jackburton]

BeIDE Crashes with the same backtrace. Maybe we aren't binary compatible in some place ? I think we should add some tests to see if we are. Or at least compare the size of our classes with the size of the beos's classes.

[jackburton]

Diver, can you name some other apps (beside BeIDE and PackageBuilder) which crash with the same backtrace ?

[jackburton]

Axel, I think you changed the location of the some reserved members with hrev15060... since BView has some friends classes, this could lead to bc problems, I think. Check also Window.h, hrev13131.

[axeld]

Replying to jackburton: See ​https://lists.berlios.de/pipermail/haiku-commits/2005-June/001681.html I'll have a look one day :)

[jackburton]

Replying to axeld:

Replying to jackburton: See ​https://lists.berlios.de/pipermail/haiku-commits/2005-June/001681.html I'll have a look one day :)

What about MenuBar.h hrev18649 ? Doesn't adding a virtual method require removing another virtual ?

[axeld]

Replying to jackburton:

What about MenuBar.h hrev18649 ? Doesn't adding a virtual method require removing another virtual ?

This is not a new virtual of class BMenuBar - it's a new virtual method in BView, and a virtual slot has been removed there. If you have any other ideas, feel free to shoot :-)

[xed]

just a note that maybe can help: If you run the application (BeIDE or PackageBuilder) with 'spybmessage' it just works as expected..

[jackburton]

I was thinking if this isn't a case like the one described here (since the crash happened in type_info also in that case): ​http://dl.hirschkaefer.de/gcc/

"Every app is now automatically linked against a (new) object file named

fix_bdirectwin_typeinfo.o As a result of the multiple / single symbol space issue, older compilers generate typeinfo-functions in each object file that uses them (via dynamic_cast). As this compiler uses a single symbol space when optimizing, type-info functions are not kept in each object file, but they are taken from the library which "defines" the class that is the target of the dynamic_cast. This works fine for most cases, but the Be-libraries seem to contain a broken version of the BDirectWindow-typeinfo-function."

If BeIDE and some other methods contained some broken type_info function, at least it would be a good explanation.

Maybe Oliver could tell ?

[jackburton]

Replying to jackburton:

If BeIDE and some other methods

and some other _applications_

[bonefish]

I've started to work on this one. It does indeed smell like a compatibility problem.

The dynamic_cast() that segfaults is on a BPrivate::BHScrollBar object (defined in libtracker), when trying to cast it from BHandler* to BView* in BWindow::_FindView(int32). I've compared the Haiku and Be headers for BScrollBar, BView, BHandler, BArchivable and they look compatible to me.

Will dig deeper...

[bonefish]

Doesn't seem to be a simple binary compatibility problem (different object/vtable size). The __si_type_info::dcast() works recursively. It is invoked for the parent class' type info until the type info of the right class is found (or the bottom is hit). In this case the BPrivate::BHScrollBar type info tries to calls dcast() of the super class, namely BScrollBar, type info. Apparently our loader chose the BScrollBar type info living in the PackageBuilder executable. In memory this one has a NULL vtable pointer, which causes the segfault, when the dcast() method is tried to be resolved.

I don't know yet, why that pointer is NULL. I haven't understood yet, how it usually should be initialized. There don't seem to be relocation entries. So there's probably special initialization code responsible for those initializations. Maybe our loader doesn't call it for the executable in this case for any reason.

[bonefish]

Fixed in hrev21290.

[jackburton]

Ingo: you are THE MAN!