Bug 16984 - "Create and Call" and "Create and Execute" display lists cause crash.
Summary: "Create and Call" and "Create and Execute" display lists cause crash.
Status: RESOLVED WORKSFORME
Alias: None
Product: Mesa
Classification: Unclassified
Component: Mesa core (show other bugs)
Version: 7.0
Hardware: x86 (IA32) Linux (All)
: high critical
Assignee: mesa-dev
QA Contact:
URL: https://bugs.launchpad.net/armagetron...
Whiteboard:
Keywords: NEEDINFO
Depends on:
Blocks:
 
Reported: 2008-08-04 18:13 UTC by Monkey
Modified: 2009-10-19 23:42 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments

Description Monkey 2008-08-04 18:13:55 UTC
This happens on a game called Armagetron Advanced. All of the information you should need is here:

https://bugs.launchpad.net/armagetronad/+bug/245925

Note that I had issues trying to install a newer version of Mesa but I checked to see if this bug had already been reported and it did not seem to have been.
Comment 1 Michel Dänzer 2008-08-05 01:00:57 UTC
I can't reproduce this on a Debian system with the r300 driver, neither with a self-built pre-7.1 Git snapshot nor with the Debian 7.0.3 packages (which are actually based on a post 7.0.3 snapshot of the Git mesa_7_0_branch). Can you try a snapshot from either of these Git branches?

Note that Debian's version of armagetronad only knows 'On' or 'Off' for display lists, but I assume 'On' corresponds to one of the options that fail for you.
Comment 2 epsy 2008-08-05 02:52:12 UTC
You will need a recent version in order to reproduce it, the stable version of arma doesn't reproduce the bug.

To grab a copy of a more recent arma which reproduces on Monkey's hardware, use bzr co lp:armagetronad/0.2.8
then use the regular build process: ./bootstrap.sh && ./configure && make && make run
Comment 3 Monkey 2008-08-05 06:23:50 UTC
Early versions of bzr (bazaar) may not have all of the functionality you need (Debian stable I think is too old). According to their site
http://bazaar-vcs.org/Download the current stable version should be available in apt repository (I would guess in testing or unstable).
Comment 4 Michel Dänzer 2008-08-05 08:56:55 UTC
(In reply to comment #2)
> To grab a copy of a more recent arma which reproduces on Monkey's hardware, use
> bzr co lp:armagetronad/0.2.8

Done, still can't seem to reproduce with this with neither the Mesa setups I mentioned and with neither the armagetronad settings mentioned. So it would definitely be good if you could try a newer Mesa snapshot or at least the 7.0.3 release.
Comment 5 Monkey 2008-08-05 15:29:27 UTC
https://bugs.launchpad.net/armagetronad/+bug/245925 updated.

Also, track this thread as it grows: http://forums.armagetronad.net/viewtopic.php?t=18264&sid=a162d27d3661873b90576883119cdf9f
Note that "hoop" also has this problem. He uses Ubuntu and also he seems to be on Mesa 7.0.3-rc2. Some had no problems with versions of Mesa as low as mine.

If you are going to test then make sure you play on a server over the network with as many people on as possible. It took me 15 minutes sometimes to get the bug today. It also seems that maybe if you reduce your detail settings and preferences it may happen more quickly?

Finally, for me to try to install newer versions of Mesa (which I did try) I discovered I will need Xorg 1.5 and things like that which I dont have and would be nightmare for me (I'm no expert yet).
Comment 6 Michel Dänzer 2008-08-06 02:17:37 UTC
Okay, I guess I just haven't tried hard enough to reproduce it.

Please attach a gdb backtrace from the assertion failure, preferably with Mesa debugging symbols.
Comment 7 Monkey 2008-08-18 06:49:07 UTC
(In reply to comment #6)

For some reason, when running via gdb, Armagetron Advanced only crashes at the end of the round of play. 

Anyway, here is a backtrace (I'm not sure how to get the Mesa debugging symbols yet).Create and Call and Create and Execute produce the same backtrace (other than the hex numbers):

#0  0xb7994c66 in raise () from /lib/libc.so.6
#1  0xb7996571 in abort () from /lib/libc.so.6
#2  0xb798de60 in __assert_fail () from /lib/libc.so.6
#3  0xb7582514 in _tnl_draw_prims () from /usr/lib/xorg/modules/dri/r200_dri.so
#4  0xb75817b9 in vbo_save_playback_vertex_list () from /usr/lib/xorg/modules/dri/r200_dri.so
#5  0xb7520493 in ?? () from /usr/lib/xorg/modules/dri/r200_dri.so
#6  0x08302e98 in ?? ()
#7  0x087e4738 in ?? ()
#8  0xbfa01608 in ?? ()
#9  0xb75203ee in ?? () from /usr/lib/xorg/modules/dri/r200_dri.so
#10 0x085dc970 in ?? ()
#11 0x087e4734 in ?? ()
#12 0x08302e98 in ?? ()
#13 0x00a98f7c in ?? ()
#14 0x000000a1 in ?? ()
#15 0xb7ab3128 in main_arena () from /lib/libc.so.6
#16 0xb7ab1ff4 in ?? () from /lib/libc.so.6
#17 0xb7a98f7c in ?? () from /lib/libc.so.6
#18 0xb7ab1ff4 in ?? () from /lib/libc.so.6
#19 0x00000000 in ?? ()
Comment 8 Joe Krahn 2008-09-11 21:20:04 UTC
(In reply to comment #0)
> This happens on a game called Armagetron Advanced. All of the information you
> should need is here:
> 
> https://bugs.launchpad.net/armagetronad/+bug/245925
> 
> Note that I had issues trying to install a newer version of Mesa but I checked
> to see if this bug had already been reported and it did not seem to have been.
> 

The location of the crash is easy to find from the debug message. I have come across this occasionally on software for which I do not have the source code. The problem seems to come from NULL vertex (or other) triangle array pointer compiled into a display list. Maybe this occurs in the context of a "zero sized" object where the relevant pointer data is not actually referenced. If someone has the source code where this can be reproduced, maybe you can add a some checks to array pointer calls to look for NULLs.
Comment 9 Manuel Moos 2008-12-10 00:53:01 UTC
(Another Armagetron Advanced Developer reporting)

We're using custom C++ array classes to feed pointers to OpenGL; they always have a valid data pointer, unlike most STL implementations. Passing NULL pointers into OpenGL is definitely not the problem. I've been using BuGLe to trace our OpenGL usage recently, analyzing the resulting call traces with a small Python program for anomalies; the few (harmless ones; like calling glDeleteLists while recording another list, which should be legal) have been eliminated. glBegin/End pairs definitely match, and all commands inside display lists are legal, no undefined display lists are used.

What *may* be the problem is that we're using display list as geometry caches in the new alpha versions (not in previous stable releases, there we only use them for static geometry). We have lots of geometry that is in principle dynamic, but doesn't change often on a frame-to-frame basis; so to optimize rendering, we put it into display lists and only update the lists when something changes. The way we do this can result in *empty* display lists from time to time.

Anyway, at least for software rendering, it seems Mesa 7.2 is no longer afffected by this problem: https://bugs.launchpad.net/armagetronad/+bug/245925/comments/10
I'm asking the DRI users to verify this.

Assuming 7.2 turns out to be clean for them, too: If you still want us to get down to the root of the issue for 7.0.x and 7.1, I can reproduce the crash there rather reliably now with the debug recording attached to the linked comment.
Comment 10 Ian Romanick 2009-09-22 15:22:43 UTC
This bug is against fairly old versions of Mesa that are no longer supported.  Is this issue reproducible on more recent versions?  The last comment seems to indicate that it may have been fixed in 7.2.
Comment 11 Ian Romanick 2009-10-19 23:42:59 UTC
A month with no reply.  Closing.


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.