On 3/5/10, Garrett Cooper <[email protected]> wrote: > On Thu, Mar 4, 2010 at 9:54 PM, Silesh C V <[email protected]> wrote: >> On 3/4/10, Rishikesh K Rajak <[email protected]> wrote: >>>>Rishi, >>> >>>>Can you test this patch on the machine on which the tests got stuck >>>>earlier? >>> >>> Yes i tested and found that, it is failing. >> >> It is supposed to fail :) . What we wanted was a way to come out of >> the tests if the >> alarm fails to ring. >> >> >>> >>> [r...@x335a rtc]# ./rtc-test /dev/rtc >>> rtc01 0 TINFO : RTC READ TEST: >>> rtc01 1 TPASS : RTC READ TEST Passed >>> rtc01 0 TINFO : Current Date/time is 03/03/10 12:38:26 PM >>> rtc01 0 TINFO : RTC ALARM TEST : >>> rtc01 0 TINFO : Alarm time set to 12:38:31. >>> rtc01 0 TINFO : Waiting 5 seconds for the alarm... >>> rtc01 2 TFAIL : Timed out waiting for the alarm >>> rtc01 0 TINFO : RTC UPDATE INTERRUPTS TEST : >>> rtc01 0 TINFO : Waiting for 5 update interrupts... >>> rtc01 0 TINFO : Update interrupt 1 >>> rtc01 0 TINFO : Update interrupt 2 >>> rtc01 0 TINFO : Update interrupt 3 >>> rtc01 0 TINFO : Update interrupt 4 >>> rtc01 0 TINFO : Update interrupt 5 >>> rtc01 3 TPASS : RTC UPDATE INTERRUPTS TEST Passed >>> rtc01 0 TINFO : RTC Tests Done! >>> [r...@x335a rtc]# ls -l /dev/rtc* >>> crw-r--r-- 1 root root 10, 135 Feb 20 13:51 /dev/rtc >>> [r...@x335a rtc]# >>> >>> >>> >>> In fact while compiling there is some warning also. >>> [r...@x335a rtc]# make >>> cc rtc-test.c -O2 -Wall -I ../../../../include/ -L ../../../../lib/ >>> -lltp -o rtc-test >>> rtc-test.c: In function ‘read_alarm_test’: >>> rtc-test.c:64: warning: dereferencing type-punned pointer will break >>> strict-aliasing rules >> >> I did not get this warning on gcc-4.3.0 . Anyways I think we can get rid >> of this >> warning by using -fno-strict-aliasing option at the cost of some >> optimizations. >> I will send you another patch. >> > > Or maybe just fix the code to not type-pun by converting everything to > struct tm on the fly? > > Let's look at the difference between the two structures: > > struct rtc_time { > int tm_sec; > int tm_min; > int tm_hour; > int tm_mday; > int tm_mon; > int tm_year; > int tm_wday; > int tm_yday; > int tm_isdst; > }; > > struct tm > { > int tm_sec; /* Seconds. [0-60] (1 leap second) */ > int tm_min; /* Minutes. [0-59] */ > int tm_hour; /* Hours. [0-23] */ > int tm_mday; /* Day. [1-31] */ > int tm_mon; /* Month. [0-11] */ > int tm_year; /* Year - 1900. */ > int tm_wday; /* Day of week. [0-6] */ > int tm_yday; /* Days in year.[0-365] */ > int tm_isdst; /* DST. [-1/0/1]*/ > > #ifdef __USE_BSD > long int tm_gmtoff; /* Seconds east of UTC. */ > __const char *tm_zone; /* Timezone abbreviation. */ > #else > long int __tm_gmtoff; /* Seconds east of UTC. */ > __const char *__tm_zone; /* Timezone abbreviation. */ > #endif > }; > > Note the extra fields down below -- they increase the structure size > by a non-trivial amount (12 bytes on 32-bit, 16 bytes on 64-bit), > which means that if one of the following two cases are made in > strftime tomorrow: > > 1. They use one of the timezone fields and it isn't properly cleared > (not the case today, but it could be on some older versions of Linux). > 2. They make assumptions about the size of the memory allocated and > thus go out of bounds. > > BOOM! Segfault... could worse happen in this case after the ioctl is > written out to /dev/rtc ?
OK. Can we drop strftime then ? > >>> Please solve these problems and please send me a revised patch. > > Thanks, > -Garrett > -- Silesh ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Ltp-list mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ltp-list
