- From: Will Dietz <w@wdtz.org>
- Date: Tue, 9 Jul 2013 14:32:59 -0500
- To: www-lib@w3.org
Hi all, While doing research on integer overflows in software I encountered the following issue with libwww related to the way it represents time on 32bit systems: Normal behavior: $ sudo date -s "Sat Jun 1 09:50:20 2013"; install/bin/w3c http://localhost Sat Jun 1 09:50:20 EDT 2013 Looking up localhost Looking up localhost Contacting localhost Fatal Error: connect operation failed (Connection refused) Triggering the bug: $ sudo date -s "Sat Jun 1 09:49:20 2013"; install/bin/w3c http://localhost Sat Jun 1 09:49:20 EDT 2013 Looking up localhost Looking up localhost Contacting localhost Segmentation fault The underlying issue is that w3c tracks time as milliseconds-since-epoch but on 32bit systems stores that value in a 32bit integer. Quick math suggests this means every 50 days time wraps, which is the cause of the failure shown above. It's likely there are other issues related to timing bugs when time unexpectedly wraps. This seems moderately important as it means w3c has a chance to fail or other act incorrectly once every 50 days. The suggested solution is to simply always use a 64bit value for representing time. I have a shim library implementation of gettimeofday() that can be used with LD_PRELOAD to cause this and related timing bugs without having to play with the system time. I've thrown this up on github in case this is useful to someone[1]. Please let me know if you need more information or have any questions. Thanks, ~Will [1] https://github.com/dtzWill/gtod-shim
Received on Tuesday, 9 July 2013 20:12:34 UTC