On Mon, 19 Nov 2001, Christoph Reichenbach wrote: > > > It's not very relevant what happens afterwards, it'd be more interesting > > > to know what triggers the invalid send/selector read. > > > > We actually figured this out before -- it's a bad selector(?) being passed > > kCanBeHere. > > Not a bad selector; CanBeHere() is passed an object and a list of objects. > Of couse that'd make it much easier to track it down (snk); inspecting > objects can be done with 'obj <address>', whereas lists can be dumped with > 'listinfo <address>'.
I have verified it's in the list passed to CanBeHere(). Output from the debugger after the VM crash: "Lookup selector functions: Method selector offset 12ffb of object at b7d0 is invalid GFX Warning: E:\src\freesci\src\gfx\operations.c, L1659:Attempt to verify loop/cel values for invalid view 20082 Warning: Attempt to get priority band 3385 pc=58ba acc=0000 o=3002 fp=6076 sp=607c prev=ffff sbase=5ffe globls=21cc &restmod=0 Step #1892746 58ba: [B] callk CanBeHere[51] 04 Kernel params: (3002, 85f6)" Now I look at the parameters passed to CanBeHere right before the crash. Note that after the crash, the list and it's entries can no longer be examined. Why? Looking at heapobj 0x3002 looks ok. listinfo 0x85f6 gives us: ">listinfo 0x85f6 List at 85f6: - Node at b50c: Key=3002 Val=3002 - Node at b5d8: Key=b566 Val=b566 - Node at b820: Key=b7d0 Val=b7d0 - Node at b846: Key=95ea Val=95ea 4 registered nodes." Note that this is the list after a "restart" is issued. The list is different during the intro before the restart. I don't know if this matters or not. So, the error message from the VM says object 0xb7d0 is the the problem, which happens to be in the list at 0x85f6. heapobj 0xb7d0 gives us: ">heapobj 0xb7d0 Clone AutoDoor Species=b6fe, Superclass=b6fe Local variables @ 0x0000 Variable selectors: species[0000] = b6fe %AutoDoor superClass[0001] = b6fe %AutoDoor -info-[0002] = 0001 (1) name[0017] = b7b2 y[0003] = 0064 (100) x[0004] = 0084 (132) yStep[0037] = 0002 (2) view[0005] = 0008 (8) loop[0006] = 0000 (0) cel[0007] = 0000 (0) priority[003f] = 0006 (6) underBits[0008] = 0000 (0) signal[0011] = 4000 nsTop[0009] = 003e (62) nsLeft[000a] = 0079 (121) nsBottom[000b] = 0065 (101) nsRight[000c] = 008f (143) lsTop[000d] = 003e (62) lsLeft[000e] = 0079 (121) lsBottom[000f] = 0065 (101) lsRight[0010] = 008f (143) brTop[0013] = 0063 (99) brLeft[0014] = 0079 (121) brBottom[0015] = 0065 (101) brRight[0016] = 008f (143) cycleSpeed[009f] = 0000 (0) script[0075] = 0000 (0) cycler[00a3] = 0000 (0) timer[006e] = 0000 (0) doorControl[011b] = 4000 entranceTo[011c] = 0002 (2) facingLoop[011d] = ffff (-1) locked[011e] = 0001 (1) openSnd[011f] = 0000 (0) closeSnd[0120] = 0000 (0) --INVALID--[0121] = 0000 (0) code[0104] = 0000 (0) illegalBits[0012] = 0000 (0) -- View information: cel 8/0/0 at (132,100) Priority = 6 (band starts at 95) nsRect: [121..143]x[62..101] lsRect: [121..143]x[62..101] brRect: [121..143]x[99..101] new nsRect: [121..143]x[62..101] new clipped nsRect: [121..143]x[95..101] new brRect: [121..143]x[99..101] signals = 4000: 4000: ignore_actor" Note the "--INVALID--". I'm assuming that's the problem. I resampled heapobj 0xb7d0 at the beginning of the game, and the output is the same except "0004: no_update" is in the signals list, and lsTop/Left/Bottom/Right are all 0. It still contains the "--INVALID--" in the same place then. > > The next step was to try and figure out why/where the bad selector came > > from. This is where I'm not sure how to proceed. > > This will require finding the last CanBeHere() call before that (with the > same parameters) and then checking for the object to go bad. Easiest way > to do this would be some interpreter hackery. As stated above, the object appears to be "bad" as soon as it exists. It isn't created until ego gets out of the car at the beginning of the game, which is the first time I check it. Now that I see the "--INVALID--", where do I go from here? -- http://www.clock.org/~matt
