Opened 16 years ago
Closed 15 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: | ||
| 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)
Change History (23)
by , 16 years ago
| Attachment: | app_server_crash1.jpg added |
|---|
comment:1 by , 16 years ago
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 by , 16 years ago
| Component: | Servers/app_server → Drivers/Graphics/nVidia |
|---|
This looks like it's probably a bug in the nvidia accelerant specifically with respect to its TNT support.
comment:3 by , 16 years ago
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 by , 16 years ago
| Cc: | 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?
by , 16 years ago
| Attachment: | app_server_crash3.jpg added |
|---|
follow-up: 6 comment:5 by , 16 years ago
| Component: | - General → Drivers/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 by , 16 years ago
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.
follow-up: 8 comment:7 by , 16 years ago
The backtrace I provided is from hrev29059, anyhow I file a new ticket, as this is a different bug.
comment:8 by , 16 years ago
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:10 by , 16 years ago
Just to clarify, the original issue in this bug is *not* fixed right? - only the new issue reported by rossi in ticket #3379
comment:13 by , 15 years ago
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 by , 15 years ago
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 by , 15 years ago
| Component: | Drivers/Graphics/nVidia → Servers/app_server |
|---|
Also changing component, hopefully this is correct?
comment:16 by , 15 years ago
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 by , 15 years ago
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 by , 15 years ago
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 by , 15 years ago
| Status: | new → assigned |
|---|
I've found a reproducible test case: use MediaPlayer with overlay, (probably optionally) switch workspaces, quit MediaPlayer, switch mode.
app_server crash in gdb