Debugger problem (?)

I am wrapping an ActiveX control and keep getting GPF:s when I evaluate some
of the methods of the control:

09:55:11, den 4 januari 2002: 'Invalid access to memory location. Reading
0x1, IP 0xA395681 (C:\Documents and Settings\Mikael\Mina dokument\Dolphin
Smalltalk 4.0\6dx_atl.dll)'
ProcessorScheduler>>gpFault:
[] in ProcessorScheduler>>vmi:list:no:with:
BlockClosure>>ifCurtailed:
ProcessorScheduler>>vmi:list:no:with:
SmallInteger(Object)>>doesNotUnderstand:
SmallInteger(IA6DX)>>get_Device:pVal:
IA6DX>>device:
R6DX>>getDevice:
UndefinedObject>>{unbound}doIt

6dx_atl.dll is the control and obviously the error is not caused by Dolphin.
But I am seeing some very strange things in the debugger. The first method
that I examine in the debugger is IA6DX>>device: (where IA6DX is an
IDispatch subclass generated by the ActiveX component wizard). The method
IA6DX>>device: looks like this:

device: deviceNumber
    "Answers the <sdword> value of the 'Device' property of the receiver.
Helpstring: 'property Device'"
| answer |

answer := (SDWORD new).
self get_Device: deviceNumber
    pVal: answer.
^answer asObject

The debugger says that:

"self" is an IA6DX(an ExternalAddress(16rA583F38)).
"deviceNumber is 1 (which is the value that I passed to the method).
"answer" is a SDWORD(0)

Nothing seems strange so far. But if I instead step into the
get_Device:pVal: method I get the GPF. If I examine the IA6DX>>device method
it still looks the same and self, deviceNumber and answer haven't changed
(which is also correct, of course). The method causing the GPF
(IA6DX>>get_Device:pVal:) looks like this:

IA6DX>>get_Device: deviceNumber pVal: pVal
    "Private - Get the value of the 'Device' property of the receiver.
Helpstring 'property Device'
HRESULT __stdcall Device(
[in] long* DeviceNumber,
[out, retval] long* pVal);
"
<virtual stdcall: hresult 13 sdword* sdword*>
^ self invalidCall

If I examine this method in the debugger it is listed as
SmallInteger(IA6DX)>>get_Device:pVal: in the top left list of the debugger,
instead of IA6DX>>getDevice:pVal:. Entering the method, the debugger says
that:

"self" is 106431056
"deviceNumber" is IA6DX>>device: (an instance of CompiledMethod; actually of
the CompiledMethod that called this method)
"pVal" is 106431050

This is very strange. If I go back one step, IA6DX>>device and it's values
haven't changed at all, but going forward to #get_Device:pVal:, I still see
the strange values. What causes the deviceNumber argument to change from 1
to a CompiledMethod instance between two frames? How can the SDWORD(0)
become the SmallInteger 106431050? Why is self no longer an instance of
IA6DX? Is the GPF caused in the control by Dolphin sending the wrong
arguments to the control? If someone could explain this, I would be very
grateful. By the way, I have tried this after reinstalling Dolphin and the
results are the same.

Thanks in advance,

Mikael Svane
[hidden email]

By the way, the problem I asked about yesterday was solved. Indeed, I should
have sent the AXControlSite asParameter to the control, not the Shell.
Thanks Blair and Bill.

Mikael

You wrote in message news:a13snk$nkh9u$[hidden email]...
> I am wrapping an ActiveX control and keep getting GPF:s when I evaluate
some
> of the methods of the control:
>
>...[walkback snipped]...
>
> 6dx_atl.dll is the control and obviously the error is not caused by
Dolphin.
> But I am seeing some very strange things in the debugger. ...

These are symptoms of the GPF. Usually Dolphin is able to recover
successfully from a GPF in an external call, but there can be no guarantee
that damage has not been done or that the stack will be correct.

I would imagine the error is caused by the fact that you are passing 1 as
the device number argument by value, whereas the control appears to be
expecting it to be passed by reference (i.e. a pointer to a storage location
holding a 32-bit signed integer). The IDL would appear to be:

HRESULT __stdcall Device(
 [in] long* DeviceNumber,
 [out, retval] long* pVal);

Its not clear why to me the [in] only device number argument should be a
pointer (you'd have to check the control docs for that), but since it is you
will have to pass the integer by-reference. As far as Dolphin's type-library
analyzer can tell, the [in] argument is declared as a pointer, and so it can
only generate wrapper methods that expose that. If you pass a SmallInteger
as the device number argument then Dolphin's VM will pass it through
directly as the address (e.g. if you pass 0, then the function will be
passed a null pointer), so in this case you have passed it the address 1,
which is always invalid.

You could invoke the high-level #deviceNumber: wrapper with an SDWORD
argument, e.g.

    obj deviceNumber: (SDWORD fromInteger: 1)

But assuming there is really no need to pass an addresses to the control (I
can't see why there would be, but then someone must have written that IDL so
it could be deliberate) I would suggest using modifying the #deviceNumber:
wrapper method to create the SDWORD internally. Remember to take the
modified method out of the '**auto-generated**' category so it is not
overwritten should you regenerate the interface.

Regards

Blair

Blair,

>
> These are symptoms of the GPF. Usually Dolphin is able to recover
> successfully from a GPF in an external call, but there can be no guarantee
> that damage has not been done or that the stack will be correct.
>
> I would imagine the error is caused by the fact that you are passing 1 as
> the device number argument by value, whereas the control appears to be
> expecting it to be passed by reference (i.e. a pointer to a storage
location
> holding a 32-bit signed integer). The IDL would appear to be:
>
> HRESULT __stdcall Device(
>  [in] long* DeviceNumber,
>  [out, retval] long* pVal);
>
> Its not clear why to me the [in] only device number argument should be a
> pointer (you'd have to check the control docs for that),

I don't understand that either but I will check with the manufacturer of the
control. Actually the control is still a beta version and it is probably a
bug. The errors were so strange that I didn't know where the bug was. Thanks
for the help!

Best regards,

Mikael Svane
[hidden email]