W3C home > Mailing lists > Public > www-lib@w3.org > January to March 2004

serious libwww timers bug

From: Grushinskiy, Mikhail, ALABS <mgrushinskiy@att.com>
Date: Mon, 1 Mar 2004 17:18:40 -0600
Message-ID: <1C9A50113894DC459E8AF995EC23112E07250DA5@OCCLUST03EVS1.ugd.att.com>
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

This archive was generated by hypermail 2.3.1 : Tuesday, 18 February 2014 13:20:04 UTC