Opened 13 years ago

Closed 12 years ago

Last modified 12 years ago

#889 closed bug (fixed)

[PackageBuilder] crash on File->Open

Reported by: diver Owned by: bonefish
Priority: normal Milestone: R1
Component: Kits/Interface Kit Version: R1/pre-alpha1
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: All

Description

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

Attachments (1)

PackageBuilder.txt (2.3 KB ) - added by diver 13 years ago.

Download all attachments as: .zip

Change History (15)

by diver, 13 years ago

Attachment: PackageBuilder.txt added

comment:1 by jackburton, 13 years ago

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.

comment:2 by jackburton, 12 years ago

Component: Kits/Application KitKits/Interface Kit

comment:3 by jackburton, 12 years ago

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

comment:4 by jackburton, 12 years ago

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.

in reply to:  4 ; comment:5 by axeld, 12 years ago

in reply to:  5 ; comment:6 by jackburton, 12 years ago

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 ?

in reply to:  6 comment:7 by axeld, 12 years ago

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 :-)

comment:8 by xed, 12 years ago

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

comment:9 by jackburton, 12 years ago

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 ?

in reply to:  9 comment:10 by jackburton, 12 years ago

Replying to jackburton:

If BeIDE and some other methods

and some other _applications_

comment:11 by bonefish, 12 years ago

Owner: changed from axeld to bonefish
Status: newassigned

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...

comment:12 by bonefish, 12 years ago

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.

comment:13 by bonefish, 12 years ago

Resolution: fixed
Status: assignedclosed

Fixed in hrev21290.

comment:14 by jackburton, 12 years ago

Ingo: you are THE MAN!

Note: See TracTickets for help on using tickets.