Am Dienstag, 7. November 2006 19:26 schrieb Troman: > >----- Original Message ----- > >From: "Dennis Schridde" <[EMAIL PROTECTED]> > >To: "Development list" <[email protected]> > >Sent: Tuesday, November 07, 2006 6:58 PM > >Subject: Re: [Warzone-dev] BOOL used to store pointers? > > > >Am Dienstag, 7. November 2006 18:06 schrieb Per Inge Mathisen: > >> On 11/7/06, Dennis Schridde <[EMAIL PROTECTED]> wrote: > >> > The interesting thing is _why_ does it break with BOOL not being int? > >> > Means: _Who_ is relying on BOOL, which logically could be 1bit, to >be > >> > 32bit long? Why does this make WZ segfault? ... > >> > >> Could be due to loading a binary file in which bool is assumed to be > >> of 32 bit width? Then the rest of the data will come out garbled. > > > >Would be sensible... > >Does the scripting engine use binary files somewhere? I thought they were > >compiled on every run... > > > >--Dennis > > No, binary files are not used, unless you load a savegame. > I'm currently looking at it. > Currently having some connection problems, hopefully will be able to access > internet in the next days. > > I traced a path of an in-script boolean value, here's what we have: > Whenever Bison encounters a boolean/integer value in the script it casts it > to UDWORD and stores with PUT_DATA: > > #define PUT_DATA(ip, data) \ > *ip = (UDWORD)(data); \ > ip += 1 > > Later on this bool seems to be converted to SDWORD with: > sVal.v.ival = (SDWORD)(*(ip+1)); > > in interpRunScript() before pushing values to the stack. > > ival is an SDWORD member of a union which is used to store different data > types that occur in the script. Pumpkin uses standard approach for > scripting languages here as union is a good way of storing different data > types for scripts. > > I don't see how this could cause a crash, so the problem is probably > somewhere else. > > Do we know where exactly the crash occurs? What script opcode causes it? If you look at this part of the debug session I posted in the first mail:
Breakpoint 4, interpRunScript (psContext=0xb41ad4fc, runType=IRT_EVENT, index=0, offset=0) at ../lib/script/interp.c:733 733 TRCPRINTFUNC( (SCRIPT_FUNC) (*(InstrPointer+1)) ); (gdb) p opcode $16 = 7 (gdb) p InstrPointer $17 = (UDWORD *) 0xa858c28 (gdb) call cpPrintFunc(*(InstrPointer+1)) never: setBackgroundFog (gdb) c Continuing. Program received signal SIGSEGV, Segmentation fault. interpRunScript (psContext=Cannot access memory at address 0xbf000008 ) at ../lib/script/interp.c:744 744 InstrPointer += aOpSize[opcode]; (gdb) p opcode Cannot access memory at address 0xbeffffc4 (gdb) p InstrPointer Cannot access memory at address 0xbeffffc0 It seems like setBackgroundFog is causing trouble. There was one call before it, but I didn't print the name of it. :( > And do we have any reasons to assume bool values store pointers somewhere? Not necessarily. But somehow it addresses a faulty position in memory... Perhaps the opcode gets modified after the call? --Dennis
pgpEyXd1dKUYq.pgp
Description: PGP signature
_______________________________________________ Warzone-dev mailing list [email protected] https://mail.gna.org/listinfo/warzone-dev
