Opened 10 years ago
Closed 3 years ago
#12024 closed bug (fixed)
Preflet crashed while trying to select wifi network
| Reported by: | haiqu | Owned by: | pulkomandy |
|---|---|---|---|
| Priority: | critical | Milestone: | R1/beta4 |
| Component: | Preferences/Network | Version: | R1/Development |
| Keywords: | Cc: | ||
| Blocked By: | Blocking: | #12023, #14414, #15848 | |
| Platform: | All |
Description
Using the Network preflet, experienced a crash twice in a row trying to select the network from the dropbox. Attachments.
Attachments (3)
Change History (19)
by , 10 years ago
| Attachment: | Network-692-debug-26-04-2015-19-47-26.report added |
|---|
comment:1 by , 10 years ago
| Blocking: | 12023 added |
|---|
comment:2 by , 8 years ago
comment:3 by , 8 years ago
Since repopulating a menu shouldn't be problematic as long as you don't assume your BMenuItem will still be alive when you get its message (it doesn't seem to be the problem here), I would rather like to see the actual bug being fixed.
comment:4 by , 8 years ago
Well, changing items in the BMenu from the main window thread, while the menu is doing its own things as a separate thread, and without any locking, seems a bit strange. Is BMenu really designed for this to work?
Shouldn't we at least lock the menu when adding and removing items from it? Or does it lock the parent window looper when active to avoid such problems?
comment:5 by , 8 years ago
| Keywords: | preferences added |
|---|
comment:6 by , 8 years ago
@korli: Why do we need a "preferences" keyword? This is already in a "Preferences" component.
comment:7 by , 8 years ago
@waddlesplash otherwise this ticket doesn't come up in a trac search "network preferences crash".
comment:8 by , 6 years ago
| Blocking: | 14414 added |
|---|
comment:10 by , 4 years ago
| Blocking: | 15848 added |
|---|---|
| Priority: | normal → critical |
| Resolution: | fixed |
| Status: | closed → reopened |
This bug is unfortunately back.
by , 4 years ago
| Attachment: | Network-910-debug-19-01-2021-18-20-58.report added |
|---|
Network-910-debug-19-01-2021-18-20-58.report
comment:11 by , 4 years ago
It wasn't fixed properly in hrev52336 -- the test did not involve the menu tracking thread AFAICS. Isn't ProcessController doing something similar with its thread menus? I can't remember seeing it crash there. What does it do differently?
comment:12 by , 3 years ago
ProcessController calls Window()->{Begin|End}ViewTransaction() in Pulse(). We probably want to do the same thing in Network's InterfaceView::Pulse()?
comment:14 by , 3 years ago
| Keywords: | preferences removed |
|---|---|
| Milestone: | Unscheduled → R1 |
comment:15 by , 3 years ago
Duplicated on hrev55444.
Same issue, but slightly different crash report. Including it just in case.
by , 3 years ago
| Attachment: | Network-1417-debug-22-09-2021-16-37-29.report added |
|---|
comment:16 by , 3 years ago
| Milestone: | R1 → R1/beta4 |
|---|---|
| Resolution: | → fixed |
| Status: | reopened → closed |
Fix was merged in hrev55562.
The menu is periodically emptied and re-populated with an up to date list of wifi networks. It seems that it does not go fine if you are trying to select an item in the menu at the same time. I'm not sure what to do however, because there doesn't seem to be a way to lock the menu (doing that crashes the app even more easily), nor knowing wether it is open to stop updating it.
Maybe it would be better to not rebuild the menu in Pulse as it is done currently, but use the MenusBeginning hook to populate it just as it opens?