Opened 11 years ago

Closed 9 years ago

#3066 closed bug (fixed)

[app_server] crash in BRegion::_SetSize

Reported by: diver Owned by: axeld
Priority: normal Milestone: R1
Component: Servers/app_server Version: R1/pre-alpha1
Keywords: Cc: umccullough@…
Blocked By: Blocking:
Has a Patch: no Platform: All

Description


Attachments (2)

back_trace.png (25.5 KB) - added by diver 11 years ago.
back_trace_2.png (23.4 KB) - added by diver 11 years ago.
Another back trace with same steps

Download all attachments as: .zip

Change History (13)

Changed 11 years ago by diver

Attachment: back_trace.png added

comment:1 Changed 11 years ago by diver

  1. Ok I've found a way to reproduce it. Back trace sometime differs like in #3073, but anyway.
  2. Start WonderBrush, the click Leaf menu and open Applications folder.
  3. Now select all apps (alt+a) and drop them to the WonderBrush canvas.

This step will generate about 20 alert messages, close them.
Now if it didn't crashed repeat step 3 untill it will.

comment:2 Changed 11 years ago by diver

If you try to drop on canvas /boot/beos/bin content and while error messages appearing start to switch workspaces it will crash much faster :-)
Oh, BTW, I'm using hrev28510 in VirtualBox.

Changed 11 years ago by diver

Attachment: back_trace_2.png added

Another back trace with same steps

comment:3 Changed 11 years ago by diver

I also get back trace like in #3073.

comment:4 Changed 10 years ago by anevilyak

I can also relatively reliably reproduce this one while testing ticket #3195. If I very rapidly click to dismiss the read-only error dialogs, I hit the following backtrace every single time:

BRegion::_SetSize()
BRegion::operator= ()
RegionPool::GetRegion()
Window::SetFocus()
Desktop::SetFocusWindow()
Desktop::ActivateWindow()
Window::MouseDown()
MouseFilter::Filter()
EventDispatcher::_EventLoop()
EventDispatcher::_event_looper()
thread_entry()

I suspect there's a subtle race condition going on here, something like the window being set to the focus window right as it's being destroyed, or something along those lines.

comment:5 Changed 10 years ago by luroh

Still seeing crashes in hrev28845 when rapidly dismissing the dialogs, although with a slightly different backtrace:

BRegion::_SetSize ()
BRegion::BRegion ()
BRegion::IntersectWith ()
Window::VisibleContentRegion ()
Window::GetEffectiveDrawingRegion ()
ServerWindow::_UpdateCurrentDrawingRegion ()
ServerWindow::_DispatchViewDrawingMessage ()
ServerWindow::_DispatchViewMessage ()
ServerWindow::_DispatchMessage ()
ServerWindow::_MessageLooper ()
MessageLooper::_message_thread ()
thread_entry ()

comment:6 Changed 10 years ago by umccullough

Cc: umccullough@… added

Hit the same backtrace shown in the first image attached here using Haiku hrev29395

It's sitting in GDB now if there's anything that can be gathered further.

comment:7 Changed 10 years ago by stippi

I think without having added some debugging or tracing output, at least I couldn't make much use of the GDB session. :-\

comment:8 Changed 10 years ago by umccullough

Well, I'll reboot it when I get home tonight... Let me know if you think of anything before then (perhaps something spit out from KDL instead?)

In the event of an app_server crash like this, would ssh access to the box be helpful in any way? I suppose if there's nothing useful that can be retrieved from a gdb, session, perhaps it wouldn't help.

comment:9 Changed 10 years ago by stippi

Maybe someone else could extract useful info. But I am not fluent with GDB at all. :-\

comment:10 Changed 9 years ago by diver

This crash is not reproducible anymore. Feel free to close it.

comment:11 Changed 9 years ago by anevilyak

Resolution: fixed
Status: newclosed
Note: See TracTickets for help on using tickets.