Debugging Help - Game Won't Display

Posts: 81
Joined: 2007.07
Post: #1
A user tries to open my game on his Mac, and it only opens a blank window then crashes. He sent me the debug report, but I don't know what to make of it, I included the first part of it below.

It looks like it could be 2 things, first the path is weird, it is on a foreign language machine though, so that may be normal, second, it looks like glut might not be installed or valid, as thats the only thing in the callstack. I know my game is working on thousands of machines just fine, intel and ppc, so I would think it is something specific to his machine. Does anyone have any ideas?


Host Name:      PowerBook-G4-12
Date/Time:      2007-12-11 01:02:04.901 +0800
OS Version:     10.4.11 (Build 8S165)
Report Version: 4

Command: Game
Path:    /éŪ戲程式/Game/
Parent:  WindowServer [91]

Version: ??? (1.0)

PID:    887
Thread: 0

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_PROTECTION_FAILURE (0x0002) at 0x00000044

Thread 0 Crashed:
0   <<00000000>>     0x00010768 0 + 67432
1   <<00000000>>     0x000cbb30 0 + 834352
2   <<00000000>>     0x000e765c 0 + 947804
3       0x97c61a98 -[GLUTView _commonMouseUp:] + 300
4     0x937dc9e0 -[NSWindow sendEvent:] + 4728
5       0x97c5cc70 -[GLUTWindow sendEvent:] + 56
6     0x937859b4 -[NSApplication sendEvent:] + 4172
7       0x97c690e0 -[GLUTApplication _runMainLoopUntilDate:autoreleasePool:] + 100
8       0x97c69210 -[GLUTApplication run] + 188
9       0x97c79954 glutMainLoop + 164
10  <<00000000>>     0x0004379c 0 + 276380
11  <<00000000>>     0x000432c0 0 + 275136
12  <<00000000>>     0x0003c7ec 0 + 247788
13  <<00000000>>     0x00002410 0 + 9232
14  <<00000000>>     0x000022b8 0 + 8888

Thread 0 crashed with PPC Thread State 64:
  srr0: 0x0000000000010768 srr1: 0x000000000200f030                        vrsave: 0x0000000000000000
    cr: 0x42002242          xer: 0x0000000000000007   lr: 0x000000000003abf0  ctr: 0x0000000090b8b428
    r0: 0x00000000000cbb30   r1: 0x00000000bfffbc70   r2: 0x0000000000000140   r3: 0x0000000000000000
    r4: 0x00000000bfffe51c   r5: 0x0000000000000006   r6: 0x0000000000000000   r7: 0x00000000bfffe5ac
    r8: 0x0000000000000001   r9: 0x00000000bfffbe58  r10: 0x0000000062bf534e  r11: 0x00000000000000f0
   r12: 0x0000000000000008  r13: 0x00000000bfffe51c  r14: 0x0000000000094708  r15: 0x0000000000000000
   r16: 0x0000000000000006  r17: 0x0000000000000001  r18: 0x0000000000120000  r19: 0x0000000000000000
   r20: 0x0000000000000000  r21: 0x00000000bfffbe58  r22: 0x0000000000000000  r23: 0x0000000000000000
   r24: 0x0000000000000000  r25: 0x00000000bfffe5ac  r26: 0x00000000bfffe51c  r27: 0x0000000000000078
   r28: 0x000000000000009b  r29: 0x000000000000013e  r30: 0x00000000000000a0  r31: 0x0000000000094708
Quote this message in a reply
Posts: 3,591
Joined: 2003.06
Post: #2
That does look weird. I can't imagine GLUT would be the problem though. Maybe it is some other path related issue manifesting itself. Do be sure you're using UTF8 strings throughout for foreign path compatibility. Maybe you could pass the user a stripped down bare-basic GLUT app with like a spinning square or something to see if that works, as a sanity check on the GLUT installation. I dunno, just an idea...
Quote this message in a reply
Posts: 834
Joined: 2002.09
Post: #3
Regardless of how you handle strings, the crash report shouldn't look like that. You must've got some bad mojo with a buffer overrun or the like, I'm afraid.
Quote this message in a reply
Posts: 834
Joined: 2002.09
Post: #4
A little more help to get you in the right direction:
- you're on a kernel protection failure, that means that you're following an invalid pointer. The address is 0x44 which is 68 in decimal. I don't know if that's a number that jumps out at you in any way, given your source base.
- GLUT will be properly installed on 10.4.11, so that's not the case. What's happening is that GLUT is calling a function and then crashing. The last GLUT call is commonMouseUp; which will probably call out to your glutMouseFunc.
- it does look as if your mouse function then survives a couple of more calls deep before dying, so look for uninitialized pointers in functions called by your mouse func.

Hope this helps, these things can be a bitch to track down.
Quote this message in a reply
Posts: 1,140
Joined: 2005.07
Post: #5
Accessing an address near 0 (such as 0x44) is most likely from trying to access a member of a structure from a NULL pointer. For example, if you're trying to access the item x from the class Foo, the address offset might be 0x44, so with a base address of NULL, or 0, it's trying to access 0 + 0x44 = 0x44.

Regardless, it looks like you might have a buffer overrun overwriting internal structures for holding the functions associated with objects, given the fact that you have numerous functions with a starting address of 0.
Quote this message in a reply
Posts: 254
Joined: 2005.10
Post: #6
Check out this blog post on crash logs by Daniel Jalkut. You can find out what those unknown functions are (possibly).
Quote this message in a reply
Posts: 81
Joined: 2007.07
Post: #7
Thanks guys, great advice! Yeah it isn't a GLUT problem, I was just thinking maybe the user did something to their machine where they hosed GLUT, but it is probably my app overwriting memory as you suggest.

It just pisses me off these things never happen on my machine, is there anyway to get some kind of OS config dump and copy it to my Mac, so it is running with the exact same OS settings as a users machine? Probably not since the hardware is probably different.

Do you guys generally get your games working on everyones machines? Or is there always a few crashes on someones machine?
Quote this message in a reply
Post Reply 

Possibly Related Threads...
Thread: Author Replies: Views: Last Post
  debugging framework source in XCode squozebrain 3 10,250 Aug 16, 2006 05:47 PM
Last Post: squozebrain
  Confused While Debugging Nick 2 4,714 Feb 24, 2005 10:04 AM
Last Post: Nick