Summary: | Latest CVS leads to crash in sauerbraten | ||
---|---|---|---|
Product: | Mesa | Reporter: | David Ronis <David.Ronis> |
Component: | Drivers/DRI/R100 | Assignee: | Default DRI bug account <dri-devel> |
Status: | RESOLVED FIXED | QA Contact: | |
Severity: | normal | ||
Priority: | medium | ||
Version: | git | ||
Hardware: | Other | ||
OS: | All | ||
Whiteboard: | |||
i915 platform: | i915 features: | ||
Attachments: |
Backtrace
Xorg.log file corresponding to the backtrace just uploaded.. Second backtrace (different hang?) 3rd backtrace Better backtrace Better backtrace, different crash This attachement is the result of kill -ABRT (program hung). Crash backtrace Backtrace after make clean; this one SIGSEGV's Backtrace (SIGSEGV) Valgrind log file Backtrace has changed slightly |
Description
David Ronis
2009-08-18 19:49:17 UTC
You should updated your tree andtest again. It should have been fixed already before you finished compiling updates :) I just rebuilt/reinstalled the git master's for mesa and xf86-video-ati; the problem remains. By "tree" did you have something else in mind? mesa and drm only packages that affect opengl so that was wht I referred to. That map validation bug was found and fixed in mesa for other applications so ifthere is still crash it is something else. It would help if you provide backtrace with debug symbols installed. After installing debug symbols: 1. ulimit -c unlimited (enable core dumps to be written out) 2. run sauerbraten 3. gdb --core=core sauerbraten 4. bt full 5. press enter as long as you return back to gdb prompt 6. quit Then save the output to file and attach it to this bug report, please. Also xorg.log might have useful info. Thanks. Created attachment 28798 [details]
Backtrace
This is a backtrace made after rebuilding saurbraten, mesa and drm with "-O0 -g". The program hung and I had to exit X (ctrl-alt-f2) and kill it with -ABRT.
Created attachment 28799 [details]
Xorg.log file corresponding to the backtrace just uploaded..
As requested: xorg.log
Created attachment 28802 [details]
Second backtrace (different hang?)
Here's another backtrace created from a different hang (haven't checked to see how it differs)
Created attachment 28803 [details]
3rd backtrace
This time the program core'd with a SIGSEGV.
Mass version move, cvs -> git Created attachment 28910 [details]
Better backtrace
This is a case the SIGSEGV'd. I'd updated/rebuilt drm and mesa as well (I'd messsed up the -g flags earlier). Looks like there is a null pointer issue in radeon_bo_unref.
Created attachment 28911 [details]
Better backtrace, different crash
Here's a better backtrace, different from 28910
(In reply to comment #10) > Created an attachment (id=28911) [details] > Better backtrace, different crash > > Here's a better backtrace, different from 28910 > Does the latest mesa version work now for you? Swtcl was fixed yesterday that seems like cause of your 2nd problem. Created attachment 28965 [details]
This attachement is the result of kill -ABRT (program hung).
I just did:
git pull --rebase
./autogen.sh --prefix=/usr
make
sudo make install
in mesa and reran sauerbrauten. The program hung or crashed, depending on which game I selected. This attachment corresponds to the hang. I'll upload the crash next.
Created attachment 28966 [details]
Crash backtrace
Try running make clean before rebuilding Mesa. Created attachment 29198 [details]
Backtrace after make clean; this one SIGSEGV's
I ran make clean before rebuilding. If I understand the backtrace correctly, it looks like it's trying to dereference bo which is NULL in thread 1. Also not I get the following message on the console:
*********************************WARN_ONCE*********************************
line -1207660556nction ÃCÑ
Leaking dma buffer object!
***************************************************************************
which is garbled.
Created attachment 29548 [details]
Backtrace (SIGSEGV)
Now I see
*********************************WARN_ONCE*********************************
File radeon_dma.c function radeonReleaseDmaRegions line 345
Leaking dma buffer object!
***************************************************************************
on the console before SIGSEGV. I've attached a copy of the backtrace, although, it probably equivalent to one's I've attached in the past.
I'm using tonight's git master drm and mesa (as well as xf-video-ati and xserver and related required modules).
P.S., can anybody reproduce this bug? As I mentioned before, it looks like a null pointer dereference is the cause.
It doesn't reproduce with KMS and kernel memory manager. So if you want to test in your system yo ucan upgrade to 2.6.31 kernel and enable stagging drivers to build KMS support. You will need user-space driver support for KMS. http://xorg.freedesktop.org/wiki/radeonBuildHowTo I tried setting up KMS as described in the wiki. I'm not sure I was successful, but if so, there's no change with the bug. Couple of things: 1. I didn't activate any of the device specific staging drivers in the kernel (just the overall staging CONFIG_STAGING=y option). 2. XOrg.0.log shows only one reference to KMS: (II) [KMS] drm report modesetting isn't supported. Created attachment 29611 [details]
Valgrind log file
I've run under valgrind --trace-children=yes (which is painful). Perhaps this will help track down the bug. There are several mesa related issues that show up.
Created attachment 29887 [details]
Backtrace has changed slightly
The latest git master of mesa and/or drm seem to have changed the crash. The backtrace is attached.
I upgraded mesa today--there were several r200 fixes. They seem to have fixed the problem. (In reply to comment #21) > I upgraded mesa today--there were several r200 fixes. They seem to have fixed > the problem. > Closing. See bug #25179 if you are still getting this: *********************************WARN_ONCE********************************* File radeon_dma.c function radeonReleaseDmaRegions line 302 Leaking dma buffer object! *************************************************************************** |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.