Modify

Opened 9 years ago

Closed 8 years ago

#1410 closed Bug (Fixed)

Using Pointer type with COM-object throws error.

Reported by: monoceres Owned by: Jon
Milestone: 3.3.7.9 Component: AutoIt
Version: 3.3.3.3 Severity: None
Keywords: com pointer idispatch Cc:

Description

AutoIt doesn't seem to have any code dealing with variables of pointer type when using COM, the following simple example throws com error 00000005.

$oMyError = ObjEvent("AutoIt.Error", "_Au3Obj_Err")
Func _Au3Obj_Err()
	MsgBox(48, 'COM Error', 'An error occured:' & @CRLF & $oMyError.description    & @CRLF & _
             "err.number is: "         & @TAB & hex($oMyError.number,8))
EndFunc   ;==>_Au3Obj_Err


$sh = ObjCreate("ScriptControl")
$sh.Language="VbScript"
$sh.Eval(Ptr(0))

Attachments (0)

Change History (6)

comment:1 in reply to: ↑ description Changed 9 years ago by anonymous

Replying to monoceres:

$sh.Eval(Ptr(0))

What is it, what you are trying to do here?
I personally would expect this code to crash: Eval() apparently needs a string (Variant/VT_BSTR) and you submit a pointer (VT_PTR). COM error is the most harmless case here, if ScriptControl didn't validate arguments you would end up with access violation, since memory at address 0x00000000 isn't a valid read pointer.

comment:2 follow-up: Changed 9 years ago by ProgAndy

The example is bad. This example is straight forward and fails, too.

$oMyError = ObjEvent("AutoIt.Error", "_Au3Obj_Err")
Func _Au3Obj_Err()
	MsgBox(48, 'COM Error', 'An error occured:' & @CRLF & $oMyError.description    & @CRLF & _
             "err.number is: "         & @TAB & hex($oMyError.number,8))
EndFunc   ;==>_Au3Obj_Err


$oDict = ObjCreate("Scripting.Dictionary")
; just to show the objetc works:
$oDict.add("valname", "test")
MsgBox(0, 'The object works:', "'valname' has the value: " & $oDict.Item('valname'))

;Error (crash without ErrorHandler): 
$oDict.add("ptr", Ptr(1234)) ; save a pointer in the dictionary object
MsgBox(0, 'Ptr does not work:', "'ptr' has the value: " & $oDict.Item('ptr'))

comment:3 in reply to: ↑ 2 ; follow-up: Changed 9 years ago by doudou

Replying to ProgAndy:

The example is bad. This example is straight forward and fails, too.

I see what you mean, but comment on the 1st example applies here too: you convert the parameter to VT_PTR and the COM object tries to read the memory from that pointer (not the pointer value) which results in a crash. Not only you both supply an imaginary (invalid) memory address, I would also suspect no normally programmed COM component (at least none I've ever encountered) would expect VT_PTR and would know what do with it.

comment:4 in reply to: ↑ 3 Changed 9 years ago by monoceres

Replying to doudou:

Replying to ProgAndy:

The example is bad. This example is straight forward and fails, too.

I see what you mean, but comment on the 1st example applies here too: you convert the parameter to VT_PTR and the COM object tries to read the memory from that pointer (not the pointer value) which results in a crash. Not only you both supply an imaginary (invalid) memory address, I would also suspect no normally programmed COM component (at least none I've ever encountered) would expect VT_PTR and would know what do with it.

Come on! What the pointer points to is irrelevant. We just supplied imaginary pointers to display the issue. There are components that need the value in the field that is guarantied to be the same size as the pointer size on the system. Taking a window handle (HWND) is a good example.

comment:5 Changed 9 years ago by Jpm

  • Owner set to Jon
  • Status changed from new to assigned

comment:6 Changed 8 years ago by Jon

  • Milestone set to 3.3.7.9
  • Resolution set to Fixed
  • Status changed from assigned to closed

Fixed by revision [6124] in version: 3.3.7.9

Guidelines for posting comments:

  • You cannot re-open a ticket but you may still leave a comment if you have additional information to add.
  • In-depth discussions should take place on the forum.

For more information see the full version of the ticket guidelines here.

Add Comment

Modify Ticket

Action
as closed The owner will remain Jon.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.