RE: Bug fix to HTHost.c

Hi,

I have the similar problem in my app which uses libwww. I built it on
Windows but without WWW_WIN_ASYNC so it should use the same code as built on
Unix.

In my application, I perform the following :

CRequester::PostToServer(...)
{
	// Create request, set attributes etc...

	// POST the source to the dest
	BOOL status = HTPostAnchor(pParentAnchor, pDstAnchor, pRequest);

	// Go into the event loop ...
	if (status == YES)
		status = HTEventList_newLoop();
}

The problem I will describe does not happen on Win2000 & Win98, but it
happen all the time when running my application on WinNT.
Then, when going into the loop, the select statement in HTEventList_loop
(HTEvtLst.c) returns -1, with a Winsock error of WSAEINVAL since the
FDArrays are empty (!?)
This of course causes the EventLoop to exit immediately without performing
any read/write to/from the socket.

Peter,
Is that the same problem you have faced ?
I have tried using your fix but it did not solve my problem ?

All others,
Did anyone see this before ?
Can anyone give my an idea what is wrong here ?
Are there some configuration / initialization points I am missing ?

Any help would be appreciated,
Yovav

~~~~~~~~~~~~~~~
Yovav Meydad
Software Engineer
Contact Networks
www.contact.com
~~~~~~~~~~~~~~~


-----Original Message-----
From: www-lib-request@w3.org [mailto:www-lib-request@w3.org]On Behalf Of
Francois Nicot
Sent: Tuesday, May 23, 2000 6:53 PM
To: peter.kocks@baygate.com
Cc: www-lib@w3.org
Subject: Re: Bug fix to HTHost.c


Peter Kocks wrote:

> Hi all,
>
> I'm new to this list and have both a
> bug to report and a solution.
>
> I can reproducibly crash a custom webbot program
> that uses libwww.  The program crashes under a
> couple of circumstances (gdb stack traces are
> attached at the bottom of this message), but
> both are related to two lines of code in HTHost.c
>
> In HTHost.c, starting at line 1099 (current cvs)
> HTChannel_delete(host->channel, status);
> host->channel = NULL;
>
> The second line (host->channel = NULL) is both
> unnecessary and causes libwww crash under certain
> conditions.  For  example, any subsequent code that
> calls HTChannel_socket(host->channel)) will return
> a socket number of "-1".  This will cause a
> segfault if something is keyed on socket
> number.  E.g. HTEventList_unregister().
>
> I'm not sure what the procedure is, but I'd
> like the line host->channel = NULL deleted from
> the code base because it is causing some
> of my programs to crash.
>
> Thanks in advance
>
> Peter Kocks
>
> Stack traces follow.
>
> -----------------------------------------------------
>
> Program received signal SIGSEGV, Segmentation fault.
> 0xdff47971 in HTEventList_unregister (s=-1, type=HTEvent_READ)
>     at HTEvtLst.c:457
> 457         while (cur && (pres = (SockEvents *) HTList_nextObject(cur)))
{
> (gdb) where
> #0  0xdff47971 in HTEventList_unregister (s=-1, type=HTEvent_READ)
>     at HTEvtLst.c:457
> #1  0xdfeaca8c in HTEvent_unregister (s=-1, type=HTEvent_READ) at
> HTEvent.c:52
> #2  0xdfeaf391 in HTHost_recoverPipe (host=0x8074958) at HTHost.c:841
> #3  0xdfeb38fb in HTNet_delete (net=0x80834b0, status=200) at HTNet.c:912
> #4  0xdff162ee in HTTPCleanup (req=0x8083310, status=200) at HTTP.c:168
> #5  0xdff183ea in HTTPEvent (soc=9, pVoid=0x80827a0, type=HTEvent_READ)
>     at HTTP.c:1290
> #6  0xdfeae58e in HostEvent (soc=9, pVoid=0xffffffff, type=HTEvent_READ)
>     at HTHost.c:196
> #7  0xdff475e1 in EventOrder_executeAndDelete () at HTEvtLst.c:321
> #8  0xdff48045 in HTEventList_loop (theRequest=0x8072b50) at
HTEvtLst.c:762
> #9  0x805222c in main (argc=17, argv=0x8047b5c) at RobotMain.c:593
>
> --------------------------------------------------------------------------
--
>
> #0  redirection_handler (request=0x8072c30, response=0x8077060, param=0x0,
>     status=302) at HTRobot.c:992
> #1  0xdfab2b3a in HTNetCall_executeAfter (list=0x8073210,
request=0x8072c30,
>     status=302) at HTNet.c:314
> #2  0xdfab2db5 in HTNet_executeAfterAll (request=0x8072c30, status=302)
>     at HTNet.c:420
> #3  0xdfab3a8b in HTNet_delete (net=0x8073f48, status=302) at HTNet.c:920
> #4  0xdfb16332 in HTTPCleanup (req=0x8072c30, status=302) at HTTP.c:168
> #5  0xdfb18452 in HTTPEvent (soc=-1, pVoid=0x8070db0, type=HTEvent_READ)
>     at HTTP.c:1294
> #6  0xdfb17b7d in HTLoadHTTP (soc=-1, request=0x8072c30) at HTTP.c:967
> #7  0xdfab384c in HTNet_newClient (request=0x8072c30) at HTNet.c:808
> #8  0xdfab7450 in HTLoad (me=0x8072c30, recursive=-8 'ø') at
HTReqMan.c:1685
> #9  0xdfb443e5 in launch_request (request=0x8072c30, recursive=0 '\000')
>     at HTAccess.c:77
> #10 0xdfb44742 in HTLoadAnchorToChunk (anchor=0x8072ba0,
request=0x8072c30)
>     at HTAccess.c:243
> #11 0x8050d73 in get_robots_txt (
>     uri=0x8072970 "http://www.seattletimes.com/robots.txt") at
> HTRobot.c:1548
> #12 0x8052063 in main (argc=17, argv=0x8047bc0) at RobotMain.c:527

Peter,

I am happy you have found a work around to fix that bug that spoils my days.

but, could anyone  from w3.org confirm that it is ok .

When is the next official libwww  release that might include this patch ?

thanks.

Francois Nicot

Received on Tuesday, 23 May 2000 13:33:16 UTC