Opened 10 years ago

Closed 10 years ago

#3282 closed bug (fixed)

app_server crashed into GDB while switching workspaces

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

Description

A brief description of what I did leading up to the crash:

After starting up hrev28868 on my PIII 866 box with 384mb RAM and nvidia Riva TNT video, I tested out sound and video playback this morning.

I then copied several files and folders over from a second BFS partition mounted readonly.

I had been messing around with compiling nasm and it's documentation, so I had a terminal window and Pe open.

I then went to switch workspaces to be greeted with the attached image of a crash in app_server (in GDB).

Attachments (3)

app_server_crash1.jpg (287.3 KB) - added by umccullough 10 years ago.
app_server crash in gdb
app_server_crash2.jpg (263.4 KB) - added by umccullough 10 years ago.
backtrace
app_server_crash3.jpg (302.9 KB) - added by rossi 10 years ago.

Download all attachments as: .zip

Change History (23)

Changed 10 years ago by umccullough

Attachment: app_server_crash1.jpg added

app_server crash in gdb

Changed 10 years ago by umccullough

Attachment: app_server_crash2.jpg added

backtrace

comment:1 Changed 10 years ago by umccullough

I will leave the machine in this state for a while if there is anything I can check further to help diagnose the issue.

comment:2 Changed 10 years ago by anevilyak

Component: Servers/app_serverDrivers/Graphics/nVidia

This looks like it's probably a bug in the nvidia accelerant specifically with respect to its TNT support.

comment:3 Changed 10 years ago by umccullough

I've seen similar random app_server crashes on other machines as well - especially my G33 with the intel_extreme driver.

I wonder if it's overlay-related as it may only occur some time after using VLC with overlay mode.

I'll see if I can reproduce it on another machine with similar activities.

comment:4 Changed 10 years ago by rossi

Cc: rossi@… added
Component: Drivers/Graphics/nVidia- General

Until hrev29005 I didn't have this issue at all, since I just upgraded to hrev29059 I also get the issue quite requently. The backtrace is either the same as in the attachements from umccullough (attachment #1, #2) or like the backtrace in attachment #3.

Since in my case the FontCache seems to be regularly involved and my system was stable until hrev29005, I'll try again, with hrev29046.

I can reproduce this issue quite reliable by just opening the BeBook in Firefox and browse three or four pages. Always.

Since my system doesn't have any NVIDIA graphics, I would assume it's an issue with the NVIDIA accelerant. Maybe the component of this bug should be set to Servers/app_server?

Changed 10 years ago by rossi

Attachment: app_server_crash3.jpg added

comment:5 Changed 10 years ago by rossi

Component: - GeneralDrivers/Graphics/nVidia

Did some quick testing with hrev29046 and the steps to reproduce, which always worked for hrev29059 don't reproduce the issue now. I guess that we are therefore at least talking about two bugs here. I'll use hrev29046 now and see whether the issue reappears later, after some more stress and uptime.

Also set the component back to Drivers/Graphics/nVidia, as I accidentially changed it with my last edit.

comment:6 in reply to:  5 Changed 10 years ago by anevilyak

Replying to rossi:

Did some quick testing with hrev29046 and the steps to reproduce, which always worked for hrev29059 don't reproduce the issue now. I guess that we are therefore at least talking about two bugs here. I'll use hrev29046 now and see whether the issue reappears later, after some more stress and uptime.

The backtrace you submitted looks to have been caused by hrev29047. This is a completely different bug and probably should have a separate ticket filed, as it seems to be trying to delete either already freed or uninitialized font cache pointer, which is a separate issue from the originally reported crash in this ticket.

comment:7 Changed 10 years ago by rossi

The backtrace I provided is from hrev29059, anyhow I file a new ticket, as this is a different bug.

comment:8 in reply to:  7 Changed 10 years ago by anevilyak

Replying to rossi:

The backtrace I provided is from hrev29059, anyhow I file a new ticket, as this is a different bug.

Yes, but the backtrace matches up perfectly with the change made in hrev29047. As hrev29059 is newer, it obviously also contains that change. This also perfectly explains why your tests on hrev29046 would not exhibit the problem.

comment:9 Changed 10 years ago by stippi

Yep, that change was a bit dull. Sorry about that. Fixed in hrev29061.

comment:10 Changed 10 years ago by umccullough

Just to clarify, the original issue in this bug is *not* fixed right? - only the new issue reported by rossi in ticket #3379

comment:11 Changed 10 years ago by anevilyak

Correct.

comment:12 Changed 10 years ago by umccullough

I can't remember seeing any workspace-switching crashes in a while.

comment:13 Changed 10 years ago by mmlr

The screenshots of the original bug show a crash in Overlay::Suspend() which I have seen relatively recently (like two weeks ago). The issue usually crops up when you had some window open that used overlay but closed it. Then when switching workspaces it seems like the app_server thinks the overlay is still valid and tries to suspend it while it (or some needed parts of it) in fact is gone.

comment:14 Changed 10 years ago by umccullough

Ok - thanks for the explanation :)

I don't remember seeing any commits to explicitly fix this, so I'll trust that it's still an issue.

comment:15 Changed 10 years ago by umccullough

Component: Drivers/Graphics/nVidiaServers/app_server

Also changing component, hopefully this is correct?

comment:16 Changed 10 years ago by humdinger

I recently also opened a ticket of a crash while switching workspaces: #4207

I didn't reuse this ticked, because the backtrace is a bit different and since it's from running in VirtualBox, it's not related to the nvidia driver, this ticket's original component.

comment:17 Changed 10 years ago by umccullough

FWIW, I'm pretty certain I've seen the Overlay::Suspend() crash on an intel_extreme based computer also - so I don't think it's nvidia-specific.

comment:18 Changed 10 years ago by mmlr

Yes, two of my current machines have a chip supported by the intel_extreme driver, and I've seen it happen on them, so it's not certainly not nvidia specifc.

comment:19 Changed 10 years ago by axeld

Status: newassigned

I've found a reproducible test case: use MediaPlayer with overlay, (probably optionally) switch workspaces, quit MediaPlayer, switch mode.

comment:20 Changed 10 years ago by axeld

Resolution: fixed
Status: assignedclosed

Fixed in hrev32454.

Note: See TracTickets for help on using tickets.