[VW 7.4.1] Debugging an access violation

Hi,

I am trying to debug an access violation in an external DLL which I'm
calling via DLLCC. It probably has something to do with data which I'm
passing as parameter of a C function - a level of pointers missing, a
wrong cast, or something along this line. I'm working on Windows XP SP2
with VW 7.4.1 NC, and I don't have Visual C++, only WinDbg (the debugger
which can be downloaded from Microsoft). And of course I don't have the
symbol files for the DLL... :-(

I followed the advice at
http://wiki.cs.uiuc.edu/VisualWorks/debugging+at+the+virtual+machine+level
which says that I should attach the debugger to the VisualWorks process
(using the debug engine), and that I could get a stack trace of all
processes by calling dumpAllProcessesToFile(0), but this produces an
error message:

        Couldn't resolve error at 'mpAllProcessesToFile(0)'

The same with dumpAllToFile:

        0:000> dumpAllToFile(1,1)
        Couldn't resolve error at 'mpAllToFile(1,1)'

Does anybody know what that means and how it can be corrected?

I also tried the debug engine with the option -o10s, but it seems that
it stopped recording Smalltalk messages a bit too early (maybe some
buffer was not flushed to disk). I faintly remember another object
engine command line option which is supposed to print a smalltalk stack
trace to stdout or a file when an OE crash happens, but I don't remember
the details - it was something like -xq. Does anyone know if this still
exists and how exactly it is used?

I tried to debug this using the VisualWorks debugger, but whenever the
debugger comes close to the source of the error, it invokes a method
which causes the access violation (computation of printString, hash,
whatever). I suppose that I have to become a bit more creative about my
debugging techniques. ;-)

Thanks in advance for any advice,
Joachim Geidel

Hallo Joachim,
I don't have WinDbg here, so I can only guess; but it seems to me that
WinDbg interprets the first two letter as a command and all the rest
as parameters to that command.
In VisualStudio's command window the command to evaluate an expression
is '?', so >? dumpAllToFile(1,1) would work there.
You could try to find WinDbg's evaluate command, or enter dumpAllToFile(1,1)
in WinDbg's watch or QuickWatch window - if Windbg has such a windows.

In VisualStudio you have to select one of the VMs stack frames in the call stack window,
or VisualStudio will tell you that dumpAllToFile does not exist. Maybe the same
applies to Windbg.

>
> I also tried the debug engine with the option -o10s, but it seems that
> it stopped recording Smalltalk messages a bit too early (maybe some
> buffer was not flushed to disk).
The debug output is flushed to disk immediately, but no output happens
in the case of linked sends. That means if a method is called several times
from the same place, only at the first time you get output with -o10s.
You could try additionally turning off linked sends ( -o33792 instead of -o10s).


> I faintly remember another object
> engine command line option which is supposed to print a smalltalk stack
> trace to stdout or a file when an OE crash happens, but I don't remember
> the details - it was something like -xq.
-xq prints a smalltalk stack, if the OE quits without crashing, so it will
not help in your case.

> Does anyone know if this still
> exists and how exactly it is used?
Starting the VW with -? lists all supported options for that VM,
note that the supported options differ slightly between the normal and the debug VM.
Ralf Propach
Georg Heeg eK