Opened 14 years ago
Closed 14 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: | ||
| Platform: | All |
Attachments (1)
Change History (8)
by , 14 years ago
| Attachment: | Deskbar crash added |
|---|
follow-up: 2 comment:1 by , 14 years ago
| Owner: | changed from to |
|---|---|
| Status: | new → in-progress |
comment:2 by , 14 years ago
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 by , 14 years ago
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 by , 14 years ago
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 by , 14 years ago
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 by , 14 years ago
| Milestone: | R1 → R1/alpha2 |
|---|
comment:7 by , 14 years ago
| Resolution: | → fixed |
|---|---|
| Status: | in-progress → closed |
Should be fixed in hrev36369.
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).