Crash with client 0.2.8 from svn

voodoo · Post by **voodoo** » Thu Feb 14, 2008 11:28 am

Hi all,

I've build the last 0.2.8 from svn (several different build since the beginning of the week, all with the same behavior) and got a crash after a few sec while playing or even once right in the game menu.
That's on macosx with last libraries from macports.
I've attached the full crash report.

Some system detail:
Mac OS 10.5
ZThread 2.3.2
shttpd 1.38
ftgl @2.1.2_0 (The package available in mcport is broken so there a small fix to apply during compilation)

Any idea how to figure out what's going on here ? Any other macos users have a similar issue ? thx in advance.

Website · Post by **Z-Man** » Thu Feb 14, 2008 11:36 am

That'll be my new display list geometry caching code. What graphics card do you use? You should be able to work around the bug by disabling display lists in the Performance Tweaks submenu.

Edit: hey wait, the crash is in another thread! But the appearance of the display list code in the callstack of thread 0 and the temporal coincidence that the crashes started this week still tell me it has something to do with the display lists. I don't know what the signal code is supposed to be doing, maybe thread 0 raised a signal and thread 1 crashed on catching it (probably, since there is a raise() in thread 0's callstack), maybe thread 1 crashed and thread 0 is just receiving the signal.

Edit2: Could we also get a crash report when it crashes already in the menu? AFAIK, no real display lists are used until you at least connect to a server. There may be an empty one in the console display.

voodoo · Post by **voodoo** » Thu Feb 14, 2008 3:52 pm

I'll try to catch a crash from the menu.

I've tested the game with display list disabled and it did not crash after 2mn.
It still crashed each time I'm leaving the game though so there's probably different issues there. Here is the report:

Process: Armagetron Advanced [1563]
Path: /Users/erollet/Sources/Armagetron/fromsvn/0.2.8/armagetronad/MacOS/build/Debug/Armagetron Advanced.app/Contents/MacOS/Armagetron Advanced
Identifier: com.sourceforge.ArmagetronAdvanced
Version: 0.2.8_alpha20080131 (???)
Code Type: X86 (Native)
Parent Process: launchd [87]

Date/Time: 2008-02-14 15:49:09.540 +0100
OS Version: Mac OS X 10.5.2 (9C31)
Report Version: 6

Exception Type: EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Crashed Thread: 0

Thread 0 Crashed:
0 libSystem.B.dylib 0x914410ea __kill + 10
1 libSystem.B.dylib 0x914b83f2 raise + 26
2 libSystem.B.dylib 0x914c79af abort + 73
3 libstdc++.6.dylib 0x90d2c005 0x90ce4000 + 294917
4 libstdc++.6.dylib 0x90d2a10c __gxx_personality_v0 + 1108
5 libstdc++.6.dylib 0x90d2a14b std::terminate() + 29
6 libstdc++.6.dylib 0x90d2a261 __cxa_throw + 101
7 libZThread-2.3.2.dylib 0x0049c67c ZThread::ThreadImpl::current() + 220
8 libZThread-2.3.2.dylib 0x0049e9f7 ZThread::ThreadQueue::~ThreadQueue() + 23
9 libSystem.B.dylib 0x913fb53c __cxa_finalize + 241
10 libSystem.B.dylib 0x913fb430 exit + 33
11 ...rceforge.ArmagetronAdvanced 0x00002bcc -[NSString(ReplaceSubString) stringByReplacingRange:with:] + 0 (SDLMain.mm:137)
12 com.apple.Foundation 0x93bd4cdc _nsnote_callback + 364
13 com.apple.CoreFoundation 0x91ad29da __CFXNotificationPost + 362
14 com.apple.CoreFoundation 0x91ad2cb3 _CFXNotificationPostNotification + 179
15 com.apple.Foundation 0x93bd1fd0 -[NSNotificationCenter postNotificationName:object:userInfo:] + 128
16 com.apple.Foundation 0x93bdb668 -[NSNotificationCenter postNotificationName:object:] + 56
17 com.apple.AppKit 0x958d8eff -[NSApplication _postDidFinishNotification] + 125
18 com.apple.AppKit 0x958d8e0e -[NSApplication _sendFinishLaunchingNotification] + 77
19 com.apple.AppKit 0x958528aa -[NSApplication(NSAppleEventHandling) _handleAEOpen:] + 284
20 com.apple.AppKit 0x958520a3 -[NSApplication(NSAppleEventHandling) _handleCoreEvent:withReplyEvent:] + 98
21 com.apple.Foundation 0x93bfa1df -[NSAppleEventManager dispatchRawAppleEvent:withRawReply:handlerRefCon:] + 655
22 com.apple.Foundation 0x93bf9eef _NSAppleEventManagerGenericHandler + 223
23 com.apple.AE 0x91546648 aeDispatchAppleEvent(AEDesc const*, AEDesc*, unsigned long, unsigned char*) + 144
24 com.apple.AE 0x9154657e dispatchEventAndSendReply(AEDesc const*, AEDesc*) + 44
25 com.apple.AE 0x91546425 aeProcessAppleEvent + 177
26 com.apple.HIToolbox 0x908f9f61 AEProcessAppleEvent + 38
27 com.apple.AppKit 0x9584f9ed _DPSNextEvent + 1189
28 com.apple.AppKit 0x9584f08e -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 128
29 com.apple.AppKit 0x958480c5 -[NSApplication run] + 795
30 com.apple.AppKit 0x9581530a NSApplicationMain + 574
31 ...rceforge.ArmagetronAdvanced 0x00002ebe main + 366 (SDLMain.mm:209)
32 ...rceforge.ArmagetronAdvanced 0x000020f6 _start + 216
33 ...rceforge.ArmagetronAdvanced 0x0000201d start + 41

Website · Post by **Z-Man** » Thu Feb 14, 2008 4:08 pm

That's indeed a totally different one, it looks like some ZThread object does not like to be allocated statically. I'm committing an experimental fix that puts it somewhere where it will be destroyed a little earlier. If that doesn't work, please send another exit crash error report; with a bit more effort, we can put it somewhere where it will be deleted even earlier. Failing that, we can make ZThread usage disabled by default, like it is on Linux. It's only used by the serverside authentication code anyway.

voodoo · Post by **voodoo** » Thu Feb 14, 2008 4:24 pm

Still no crash ingame and also still crashing when leaving the game.
I can post a crash log if needed but it crashed in thread 0 with barely the same result in the crash report.

Website · Post by **Z-Man** » Fri Feb 15, 2008 1:56 am

Against the exit crash, the only solution I found so far is to kick out ZThread from the project.

The OpenGL crash is a bit mysterious; similar calls in other places seem to be harmless. I committed a workaround, but will have a closer look with an OpenGL debugger later.

voodoo · Post by **voodoo** » Fri Feb 15, 2008 12:33 pm

I rebuild it this morning with the last changes.
No more GL crashes, no more threading crash neither ...
I've test with all display list options ...

Website · Post by **Z-Man** » Fri Feb 15, 2008 12:45 pm

The debug session showed the likely cause: The display list implementation you and me are using on the Mac (don't know if it affects all OSX version or just ATI drivers) does not like this:

Code: Select all

glNewList(list, GL_COMPILE);
...
glColor3f(1,1,1);
glColor3f(1,1,1);
...
glEndList();

That's the second perfectly legal (albeit, in this case, slightly stupid) display list that crashes on some implementation. I'll be building another alpha version this weekend so we can get more test coverage, but skimming over the libbugle trace log, the other display lists are free of redundancies of this kind, and free of the points at infinite distance that crashed the NVidia Linux driver.

voodoo · Post by **voodoo** » Fri Feb 15, 2008 1:56 pm

Actually my graphic card is a nvidia one. Here are the details (in french

) :

Jeu de composants : GeForce 8600M GT
Type : Moniteur
Bus : PCIe
Longueur de la voie PCIe : x16
VRAM (totale) : 256 Mo
Fournisseur : NVIDIA (0x10de)
Identifiant du périphérique : 0x0407
Identifiant de révision : 0x00a1
Révision de la ROM : 3175

Website · Post by **Z-Man** » Fri Feb 15, 2008 2:22 pm

That makes it a general Mac problem

The crash callstack didn't look deep enough to come from a driver anyway.

Post by **dlh** » Fri Feb 15, 2008 6:28 pm

Z-Man wrote:[...] Failing that, we can make ZThread usage disabled by default, like it is on Linux. It's only used by the serverside authentication code anyway.

Isn't it also used to send login requests when made instead of at round end?

Website · Post by **Z-Man** » Fri Feb 15, 2008 6:32 pm

No. The clientside bit of the protocol only uses our asynchronous UDP protocol, the only reason the server uses threads in the first place is that we don't have a library supporting the same for HTTP requests (I think. nanohttp isn't very well documented.), and it was easier to just put the server/authority communication into threads.