- From: Grushinskiy, Mikhail, ALABS <mgrushinskiy@att.com>
- Date: Mon, 1 Mar 2004 17:37:11 -0600
- To: <www-lib@w3.org>
I think there is a serious bug in implementation of internal timers in libwww.
I see cases when HTTimer_new() with valid parameter values causes endless
recursion and stack overfloating.
Here is what I think is a root cause:
HTTimer_new() makes use of HTGetTimeInMillis function which supposed to return
number of milliseconds since EPoch (00:00 January 1, 1970, UTC)
in Library/src/HTInet.c
PUBLIC ms_t HTGetTimeInMillis (void)
{
#ifdef WWW_MSWINDOWS
return GetTickCount();
#else /* WWW_MSWINDOWS */
#ifdef HAVE_GETTIMEOFDAY
struct timeval tp;
gettimeofday(&tp, NULL);
return(tp.tv_sec * 1000) + (tp.tv_usec / 1000);
#else
return((ms_t) 0);
#endif
#endif /* !WWW_MSWINDOWS */
}
ms_t is declared as
typedef unsigned long ms_t;
in Library/src/wwwsys.h
On my system unsigned long is 4 bytes or 32 bits.
Currently number of millisecods since epoch
will be something like: 1 078 179 223 000
which simply doesn't fit into ms_t (unsigned long) - 4 bytes
max 4 294 967 296
This causes major problems with timers (which end-up
in endless recursion sometimes) due to arithmetics in
HTTimer.c
ms_t now = HTGetTimeInMillis();
ms_t expires;
HTTimer * pres;
CHECKME(timer);
expires = millis;
if (relative)
expires += now;
else
millis = expires-now;
I think correct declaration for ms_t in Library/src/wwwsys.h
should have been
typedef unsigned long long ms_t;
See stack trace below for described problems
#0 0xc00a6d20 in ltostr ()
#1 0xc00a6e28 in ltostr ()
#2 0xc00a7584 in malloc ()
#3 0xc00824c0 in calloc ()
#4 0xc0b6c37c in HTMemory_calloc (nobj=1, size=8) at HTMemory.c:88
#5 0xc0b6b364 in HTList_addList (me=0x40041088, newObject=0x40041098 "") at HTList.c:88
#6 0xc0bd010c in HTTimer_new (timer=0x40041098, cbf=0x4000ea42, param=0x0, millis=600000, relative=1 '\001',
repetitive=1 '\001') at HTTimer.c:251
#7 0xc0bcf75c in Timer_dispatch (cur=0x400410b8, last=0x40041088) at HTTimer.c:112
#8 0xc0bd0190 in HTTimer_new (timer=0x40041098, cbf=0x4000ea42, param=0x0, millis=600000, relative=1 '\001',
repetitive=1 '\001') at HTTimer.c:259
#9 0xc0bcf75c in Timer_dispatch (cur=0x400410b8, last=0x40041088) at HTTimer.c:112
#10 0xc0bd0190 in HTTimer_new (timer=0x40041098, cbf=0x4000ea42, param=0x0, millis=600000, relative=1 '\001',
repetitive=1 '\001') at HTTimer.c:259
#11 0xc0bcf75c in Timer_dispatch (cur=0x400410b8, last=0x40041088) at HTTimer.c:112
#12 0xc0bd0190 in HTTimer_new (timer=0x40041098, cbf=0x4000ea42, param=0x0, millis=600000, relative=1 '\001',
repetitive=1 '\001') at HTTimer.c:259
#13 0xc0bcf75c in Timer_dispatch (cur=0x400410b8, last=0x40041088) at HTTimer.c:112
#14 0xc0bd0190 in HTTimer_new (timer=0x40041098, cbf=0x4000ea42, param=0x0, millis=600000, relative=1 '\001',
repetitive=1 '\001') at HTTimer.c:259
#15 0xc0bcf75c in Timer_dispatch (cur=0x400410b8, last=0x40041088) at HTTimer.c:112
#16 0xc0bd0190 in HTTimer_new (timer=0x40041098, cbf=0x4000ea42, param=0x0, millis=600000, relative=1 '\001',
repetitive=1 '\001') at HTTimer.c:259
#17 0xc0bcf75c in Timer_dispatch (cur=0x400410b8, last=0x40041088) at HTTimer.c:112
#18 0xc0bd0190 in HTTimer_new (timer=0x40041098, cbf=0x4000ea42, param=0x0, millis=600000, relative=1 '\001',
...
this goes on
I hope this will get fixed in CVS.
--MG
PS. Sorry if this is repost. My first mail seems didn't make it to the list.
Received on Monday, 1 March 2004 19:50:10 UTC