[quake3] Mac OS X Universal Binary (2nd try)

Thilo Schulz arny at ats.s.bawue.de
Thu Jun 8 12:10:44 EDT 2006


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thursday 08 June 2006 12:13, Daniel Lord wrote:
> Program received signal EXC_BAD_ACCESS, Could not access memory.
> Reason: KERN_PROTECTION_FAILURE at address: 0x386ae000
> 0xffff0a3f in ___memcpy () at /System/Library/Frameworks/
> System.framework/PrivateHeaders/i386/cpu_capabilities.h:186
> 186     /System/Library/Frameworks/System.framework/PrivateHeaders/
> i386/cpu_capabilities.h: No such file or directory.
>          in /System/Library/Frameworks/System.framework/
> PrivateHeaders/i386/cpu_capabilities.h
> (gdb) list
> 181     in /System/Library/Frameworks/System.framework/PrivateHeaders/
> i386/cpu_capabilities.h
>
> (gdb) backtrace
> #0  0xffff0a3f in ___memcpy () at /System/Library/Frameworks/
> System.framework/PrivateHeaders/i386/cpu_capabilities.h:186
> #1  0x000e5a78 in VM_Compile (vm=0x942580, header=0x34895538) at code/
> qcommon/vm_x86.c:1100
> #2  0x0005f766 in VM_Create (module=0xfc718 "ui", systemCalls=0x18713
> <CL_UISystemCalls>, interpret=VMI_COMPILED) at code/qcommon/vm.c:587
> #3  0x00018610 in CL_InitUI () at code/client/cl_ui.c:1154
> #4  0x0002f371 in Com_Init (commandLine=0x1b2bf62 "0") at code/
> qcommon/common.c:2539
> #5  0x000e8c93 in SDL_main (argc=4, argv=0x1b06880) at code/unix/
> unix_main.c:1423

This looks like it is crashing in the Com_Memcpy call, not at execution from 
the compiled code if you look at the callstack.
Maybe there is some stuff wrong with the input buffer. To determine where the 
error happens, it would be interesting what the pointer address of 
vm->codeBase and the pointer address of the local variable buf look like.

print vm->codeBase
print buf

these addresses set into relation with the address at which the protection 
failure happened would be helpful as debugger output.

> > My last build caught signal 4 when loading the x86 vm, so I assumed
> > this was
> > the same problem that was giving WinXP SP2 users grief with the
> > NoExec (NX)
> > thing. I was hoping I could just piggy-back on the linux version of
> > the NX vm
> > loading. Guess not.

I fixed that problem for Win32 in the icculus codebase by making windows 
builds use the calls VirtualAlloc and VirtualProtect to allocate memory that 
is executable.
If MacOSX has the mmap syscall, which I guess is pretty likely given its 
ancestry, you can make it define on macosx in the vm_x86.c file, too. At the 
moment, VM_X86_MMAP only gets defined if the code is compiled on Linux.

- -- 
Thilo Schulz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQFEiEwJZx4hBtWQhl4RAta2AJ9DATQ+o0ok+CMvzJFD7GXL38jnlQCg3VIJ
TWxUylOdolYgLaqVSF724QY=
=S4Oa
-----END PGP SIGNATURE-----



More information about the quake3 mailing list