if i define "DEBUG_VM" i get the error "Bad VM instruction"

when i set a breakpoint at "Com_Error( ERR_DROP, "Bad VM instruction" );"
and do a bt i get:
#0  VM_CallInterpreted (vm=0x3c04b0, args=0xbfffc590) at /Users/julian/Desktop/quake3/code/qcommon/vm_interpreted.c:413
#1  0x003bf340 in VM_Call (vm=0x3c04b0, callnum=0) at /Users/julian/Desktop/quake3/code/qcommon/vm.c:757
#2  0x006ff288 in CL_InitUI () at /Users/julian/Desktop/quake3/code/client/cl_ui.c:1160
#3  0x0052f3c0 in CL_StartHunkUsers () at /Users/julian/Desktop/quake3/code/client/cl_main.c:2164
#4  0x0035a1a4 in Com_Init (commandLine=0x43c0b0 "") at /Users/julian/Desktop/quake3/code/qcommon/common.c:2492
#5  0x00302e78 in -[Q3Controller quakeMain] (self=0x41f640, _cmd=0x3051dc) at /Users/julian/Desktop/quake3/code/macosx/Q3Controller.m:372
#6  0x00301d04 in -[Q3Controller applicationDidFinishLaunching:] (self=0x41f650, _cmd=0x41f6f0, notification=0x4150a0) at /Users/julian/Desktop/quake3/code/macosx/Q3Controller.m:51
[...]

Reproduceable on Linux/PPC

The values of r0 and programCounter are in the "WTF?!!!!" range (Several times the size of the instructionPointers array!)

Well, this appears to confirm what I already thought of commercial programming.

The root cause of this appears to lie in the [absurd] assumption that an array of integers is going to automatically initialise all of its members to 0, namely the stack array.

Fixing that, however, is not where such problems end....

so does that mean:
1.) there is a simple fix to get it running (initialize the array to 0)?

2.) neither ID nor someone else has recently compiled the source with gcc/pcc (because obviously it doesn't work)?

this seems unrealistic since then there wouldn't be any xcode project files in there...

This means that:

(1) There's what looks like a simple fix.

(2) Having applied (1), a whole pile of other stuff still doesn't work.

Theoretically, if the bytecode is being loaded properly, then the uninitialised array shouldn't matter because all the elements that should be being accessed to be read sould already be written to -- if it wasn't named by an untrained monkey, then the stack should be accessed in a FILO order, but unfortunately it would seem that the simians have been here.  If I maintain my high hopes that there's something elemental wrong in maybe two or three places in the code, then there's no actual logic to initialising the array to zeroes.   What happens then is you get a bunch of bad opcodes (0 does not appear to be a valid code), which indicates that something else is wrong somewhere.  Unforunately, not having the sources to the VM files, it's hard to trace exactly where.

It's most likely that a change to the VM systems in ioq3 has inadvertently broken the PPC build. I suggest you try compiling virgin Q3 sources to see if it works, and if it does, find the first revision of ioq3 where it stops working.

This is probably fixed in revision 179. Please confirm.

(In reply to comment #7)
> This is probably fixed in revision 179. Please confirm.
> 

i can confirm that this issue is fixed (on macosx).
a short test play reveals some other issues (on macosx) like the quake3 text rendering not shown at the root menu, bots only rendered the lower half (headless ;), rockets not rendered and some error messages printed to console (something like "100 GL errors printed to console"). should i file new and seperate bugs for this? 

Yes, file a new bug. I won't be able to help much though. The only way I managed to fix this one was by running xcode on pearpc. Obviously this has no GL, so I can't really address OS X client problems. If you can identify a build that does work properly and then the build where it stops working I may be able to be of some help.

Fixed on Linux/PPC also.

Setting a QA contact on all ioquake3 bugs, even resolved ones. Sorry if you get a flood of email from this, it should only happen once. Apologies for the incovenience.

--ryan.