- From: Grushinskiy, Mikhail, ALABS <mgrushinskiy@att.com>
- Date: Mon, 1 Mar 2004 17:18:40 -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
Received on Monday, 1 March 2004 19:51:11 UTC