Opened 9 years ago

Closed 9 years ago

#5717 closed bug (fixed)

[Deskbar] crash in BMenu::_UpdateWindowViewSize ()

Reported by: diver Owned by: pulkomandy
Priority: normal Milestone: R1/alpha2
Component: Kits/Interface Kit Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: All

Description

After booting Haiku right after Deskbar load click on ProcessController replicant and select some menu like "Memory usage". While updating it's menu Deskbar could crash.
It started to happen after hrev35962.

Tested with hrev36205 in VirtualBox 3.0.12.

Attachments (1)

Deskbar crash (2.5 KB) - added by diver 9 years ago.

Download all attachments as: .zip

Change History (8)

Changed 9 years ago by diver

Attachment: Deskbar crash added

comment:1 Changed 9 years ago by pulkomandy

Owner: changed from axeld to pulkomandy
Status: newin-progress

It happens on real hardware too. Apparently having things hapenning in the menu seems to make it crash sooner (run a jam of haiku sourcecode in the background for example).

comment:2 in reply to:  1 Changed 9 years ago by jackburton

Replying to pulkomandy:

It happens on real hardware too. Apparently having things hapenning in the menu seems to make it crash sooner (run a jam of haiku sourcecode in the background for example).

I think the cause of this is hrev35962. I remember having this very problem much time ago (I think there is a ticket for it). Then recently I removed this "hack" and tested, and the problem didn't seem to happen anymore. Obviously it's still there.

Since some time, I don't have a working internet connection anymore at home, so I won't be able to work on it in the foreseeable future.

comment:3 Changed 9 years ago by jackburton

Connection is back (even if intermittently).

I could reproduce this exactly once (inside virtualbox). Do you have any idea on how to reproduce it more often ? Unfortunately, since it doesn't happen so often, it's not easy to fix (except reverting the commit, but I wouldn't like to do that, since the previous code was wrong, too).

comment:4 Changed 9 years ago by pulkomandy

The more you have changes hapenning in processcontroller display, the more likely it will happen. I think it is a race condition when two items are trying to redraw at the same time or something like that.

For me, downloading the haiku sourcecode and jamming it, which creates and deletes a lot of small processes, create enough activity to make it crash everytime.

comment:5 Changed 9 years ago by bonefish

Also running the POSIX test suite (cd src/tests/system/libroot/posix/posixtestsuite/; ./run_tests THR) seems to trigger it pretty reliably (since some tests hang, best reduce the TIMEOUT_VAL in the Makefile to 10 or so). It's completely sufficient to open the ProcessController menu and wait for a bit (no need to open any submenu).

comment:6 Changed 9 years ago by bonefish

Milestone: R1R1/alpha2

comment:7 Changed 9 years ago by jackburton

Resolution: fixed
Status: in-progressclosed

Should be fixed in hrev36369.

Note: See TracTickets for help on using tickets.