312: Wrong handle type

[stevengraff]

The script below is intended to handle any number of urls. However, somewhere between 750 and 850 urls (it seems somewhat random)  it throws an error "for no apparent reason."

Anything pop out as needing improving?



if  buf <> "xyzzy" then buf = binaryFree( buf )
(6352734) ==>TRUE=> 0

tophandle=iBegin(0,"","")
(6352734) VALUE INT => 13369348

datahandle=iurlopen(tophandle,url)
(6352750) VALUE INT => 13369348

size=10000
(6352750) VALUE INT => 10000

buf=BinaryAlloc(size)
(6352750) VALUE BINBUF => 987659

bufaddr=IntControl (42, buf, 0, 0, 0)
(6352750) VALUE STRING => "324834472"

BinaryEodSet(buf, size)
(6352750) VALUE INT => 0

xx=iReadDataBuf(datahandle,bufaddr,size)
(6352750) VALUE INT => 0

EXTENDER ERROR SUPPRESSED =>312 (312: Wrong handle type. Need iUrlOpen iFtpOpen iHttpOpen or iGopherOpen)

===============

Here's a "good" version:

if  buf <> "xyzzy" then buf = binaryFree( buf )
(6343812) ==>TRUE=> 0

tophandle=iBegin(0,"","")
(6343812) VALUE INT => 13369348

datahandle=iurlopen(tophandle,url)
(6344016) VALUE INT => 13369356

size=10000
(6344016) VALUE INT => 10000

buf=BinaryAlloc(size)
(6344016) VALUE BINBUF => 987659

bufaddr=IntControl (42, buf, 0, 0, 0)
(6344016) VALUE STRING => "324834472"

BinaryEodSet(buf, size)
(6344016) VALUE INT => 0

xx=iReadDataBuf(datahandle,bufaddr,size)
(6344016) VALUE INT => 188

===============

The iReadDataBuff value ALWAYS is 188... until it's not. That's when it crashes.

[td]

If you are trying to debug with any kind of error suppression, turn off the error suppression.  The fact that it happens after a number of iterations suggest you are not properly cleaning up after yourself.  Otherwise, there isn't enough information to make any kind of semi useful suggestions.

[stevengraff]

It's just that the entire script is HUGE, and I'm a little challenged trying to isolate the potentially errant parts.

[td]

It does seem a bit strange that your top handle and your url handle have the same integer value.  That should not be but it does lend some credence to the notion that you are not cleaning up after yourself.

[stevengraff]

Good observation... but they're only equal when it works.

My intuition, also, is that I'm failing to "clean up." But this part of the script is supposed to show both the construction and demolition. Do you see anything I create that I'm not dismantling?

[stevengraff]

I don't suppose the number 312 is in any way revealing of the root cause?

[td]

Good observation... but they're only equal when it works.

My intuition, also, is that I'm failing to "clean up." But this part of the script is supposed to show both the construction and demolition. Do you see anything I create that I'm not dismantling?

But your debug trace show them only being equal when it fails based on the trace with the error.

[td]

I don't suppose the number 312 is in any way revealing of the root cause?

It means exactly what the message says and what is expected when a tophandle gets passed to an extender function expecting a URL handle.

[stevengraff]

Maybe so, but... I've passed it the same thing 750 times without a problem. Why should #751 break it?

[td]

The successful trace shows different tophandle and urlhandle values and the faulting trance shows the handles being identical.  So the question is why are the handles identical on the 751th iteration?  The best guess answer is that you have not properly release resources and the Windows WinInet subsystem is not entirely happy about it.   But that is only a guess.

[stevengraff]

In this part:

datahandle=iurlopen(tophandle,url)
(6344016) VALUE INT => 13369356

the datahandle comes back different... could this be because the url is "bad?"

[td]

I would expect the returned handle to be 0 when the URL is poorly formed or pointing to a non existent resource.   However, we are dealing with a Windows subsystem that isn't know to be to most robust and consistent part of the operating system.  We will look into this a bit more on Monday.  BTW, which version of Windows is your script running on?   We might be able to tack down a reported operating system bug, if we have that bit of info. 

[stevengraff]

Windows Server 2003, probably R2, but it's a client's system and I don't have ready access to it.

[td]

A search of available information has not produced any indication that there is a known bug in the WinINet subsystem of Windows 2003 that can cause this problem.  A code review of the Extenders source files also indicate that there are no problems in the extenders implementation that could cause this condition to exist.

By way of review, the traces file snippets you have provided indicates that  the function iurlOpen is returning the same handle returned by the iBegin function in the failing trace you posted

tophandle=iBegin(0,"","")
(6352734) VALUE INT => 13369348  <- connection handle

datahandle=iurlopen(tophandle,url)
(6352750) VALUE INT => 13369348 <- same as connection handle but it should not be!

xx=iReadDataBuf(datahandle,bufaddr,size) <- produces  a 312 error because the 13369348 value is a top level connection handle
(6352750) VALUE INT => 0
EXTENDER ERROR SUPPRESSED =>312 (312: Wrong handle type. Need iUrlOpen iFtpOpen iHttpOpen or iGopherOpen)

The iReadDataBuf function returns the 312 error when passed the handle in the variable datahandle because it correctly identifies the handle as being a top level connection handle instead of a down level handle of the type returned by the  iurlOpen function function.

The only recommendation at this point is to conduct a careful code review of your script and attempt to identify a possible flaw in the script's logic that would explain this outcome.  There isn't much more we can offer given the information at hand.  The only other suggestion might be to add some logic to your script to detect when the handle returned by the iUrlOpen function is identical to the top level connection handle returned by iBegin.  You would need to decide what is the best course of action when the condition exists and modify your script accordingly.

[stevengraff]

Thanks for all your efforts. I will try your suggestions. In particular, it seems to me that the only thing with the potential to change between the good pass and the bad is the url. I bet this traces back to a garbage url when it blows up.

[td]

We have tested iUrlOpen with all manor of bad URL and it always returns 0.  So the underlying cause is more than just a bad URL.  The best guess at this point is that the OS's WinInet handle table implementation has a bug that causes the return of the  root handle when either a 0 or sub handle should be returned under certain undetermined conditions.