Opened 16 years ago
Closed 16 years ago
#2712 closed bug (fixed)
Tracker crashes when deleting a replicant
| Reported by: | jackburton | Owned by: | aldeck |
|---|---|---|---|
| Priority: | normal | Milestone: | R1 |
| Component: | Kits/Interface Kit | Version: | R1/pre-alpha1 |
| Keywords: | Cc: | ||
| Blocked By: | Blocking: | ||
| Platform: | All |
Description (last modified by )
100% reproducible on a gcc4 build: Drag a replicant (for example DeskCalc) to the tracker's background. Delete it. You'll get a crash.
Attachments (4)
Change History (17)
comment:1 by , 16 years ago
| Description: | modified (diff) |
|---|
comment:2 by , 16 years ago
comment:4 by , 16 years ago
| Component: | Applications/Tracker → Kits/Interface Kit |
|---|---|
| Resolution: | fixed |
| Status: | closed → reopened |
Can reproduce it again. Reopening.
comment:5 by , 16 years ago
Can reproduce here, hrev29385 either with gcc2 or gcc4. Reproducible in ShelfTest (which builds again in hrev29385).
I can't find a reliable testcase, but what seems to help is to have at least 2 replicants of the same view/app and playing with mouse focus on them before trying to delete one.
Crash happens either in BView::_Pulse or BWindow::_FindView, not sure why yet.
comment:6 by , 16 years ago
| Owner: | changed from to |
|---|---|
| Status: | reopened → new |
Found an always reproducible testcase (here at least):
Create two Deskcalc replicants on the desktop or ShelfTest, without clicking anything else, delete the firstly created replicant. It will crash Tracker or ShelfTest. There are three different crashes, backtraces follow.
Working on it, let's see what i can do :)
by , 16 years ago
by , 16 years ago
by , 16 years ago
comment:8 by , 16 years ago
| Blocking: | 3029 added |
|---|
comment:8 by , 16 years ago
| Blocking: | 3029 removed |
|---|
comment:9 by , 16 years ago
Ingo, if you're watching, i was playing in the marvelous KDL for debugging, and saw strange things when looking at the backtrace. Specifically BView::_Pulse() shows lots of arguments where it shouldn't, isn't this a demangler issue? If you confirm this, i can create a specific ticket if you'd like. See attached file.
by , 16 years ago
| Attachment: | bt3_from_kdl.txt added |
|---|
comment:10 by , 16 years ago
Forget the previous comment, memory is corrupted after unload_add_on(image) in BShelf::_DeleteReplicant, the crash happens on a BView method call (of the second replicant):
http://dev.haiku-os.org/browser/haiku/trunk/src/kits/interface/Shelf.cpp#L1170
At least, commenting this line avoids the crash, investigating :)
comment:11 by , 16 years ago
Ok, with some help from korli, i found out that the unload_add_on logic is flawed, it will always unload the image on (and only on) deleting the first instance, even if the image is still needed by the other instances. Working on a fix.
Can't attach the stack trace due to a Trac bug