Opened 14 years ago

Closed 2 years ago

#6484 closed bug (not reproducible)

[app_server] crash in Desktop::SetFocusWindow ()

Reported by: diver Owned by: nobody
Priority: normal Milestone: R1/beta4
Component: Servers/app_server Version: R1/beta2
Keywords: Cc:
Blocked By: Blocking:
Platform: All

Description

This is hrev38300 in VirtualBox 3.0.12.

On the first workspace I started Terminal with installoptionalpackage -l which consumed 100% of cpu. Then I launched WebPositive and the same moment it's window appeared on screen I clicked on the second workspace using workspaces replicant. Boom.

#5124 looks similar.

Attachments (2)

app_server.png (18.6 KB ) - added by diver 14 years ago.
app_server-69-debug-05-01-2013-16-25-32.report (11.9 KB ) - added by diver 11 years ago.

Download all attachments as: .zip

Change History (12)

by diver, 14 years ago

Attachment: app_server.png added

comment:1 by diver, 11 years ago

I've just run into a similar issue in hrev45130. This time app_server crashed when I tried to reproduce screen_blanker crash by clicking Test button in ScreenSaver preflet several times either with Flurry or Gravity or screensaver selected. The crash is reproducible.

event loop , id: 105, state: Exception (Segment violation)
Frame		IP			Function Name
-----------------------------------------------
0x7019cce4	0x26fb69	Desktop::SetFocusWindow(Window*) + 0x195
[...]
0x7019cd34	0x26d3fc	Desktop::ActivateWindow(Window*) + 0x28c
0x7019cd74	0x3328de	StackAndTile::_ActivateWindow(SATWindow*) + 0xae
0x7019cda4	0x332230	StackAndTile::WindowActitvated(Window*) + 0x30
0x7019cdd4	0x275495	DesktopObservable::NotifyWindowActivated(Window*) + 0x51
0x7019ce24	0x26d1ed	Desktop::ActivateWindow(Window*) + 0x7d
0x7019ce84	0x2aadbe	Window::MouseDown(BMessage*, BPoint, ClickTarget&, &, ClickTarget&) + 0x13a
0x7019cef4	0x26aa26	MouseFilter::Filter(BMessage*, EventTarget*, void*, EventTarget*) + 0x1ea
0x7019cf84	0x27c5cd	EventDispatcher::_EventLoop() + 0x29d
0x7019cfb4	0x27cc3a	EventDispatcher::_event_looper(void*) + 0x1a
0x7019cfdc	0x8cc751	thread_entry + 0x21
00000000	0x7019cfec	?

comment:2 by axeld, 7 years ago

Owner: changed from axeld to nobody
Status: newassigned

comment:3 by diver, 5 years ago

Resolution: fixed
Status: assignedclosed

Never seen it after. Assuming fixed.

comment:4 by nielx, 4 years ago

Milestone: R1R1/beta2

Assign tickets with status=closed and resolution=fixed within the R1/beta2 development window to the R1/beta2 Milestone

comment:5 by diver, 4 years ago

Resolution: fixed
Status: closedreopened

According to https://dev.haiku-os.org/ticket/15728#comment:11 it's still reproducible in hrev54154+110.

comment:6 by Pete, 4 years ago

If this is the same bug, it has resurfaced after 10 years! I have never experienced the crash with any revision before 54154. It has happened at least 3 times since. The app_server has also crashed a couple of times, in the same hrev, when starting Youtube from W+. I'd suspect a common cause.

comment:7 by pulkomandy, 4 years ago

Milestone: R1/beta2R1/beta3
Version: R1/DevelopmentR1/beta2

comment:8 by pulkomandy, 3 years ago

Hi, can anyone reporduce this crash? Or did the refactoring and fixes in app_server fixed it?

comment:9 by pulkomandy, 3 years ago

Milestone: R1/beta3R1/beta4

Move unsolved issues to beta 4 since there is no chance of fixing them now.

comment:10 by waddlesplash, 2 years ago

Resolution: not reproducible
Status: reopenedclosed

I would personally suspect memory corruption due to the alpha-mask issues. As it has not been apparently reproduced since, let's close it again.

Note: See TracTickets for help on using tickets.