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 ?
>> Please solve these problems and please send me a revised patch.
Thanks,
-Garrett
------------------------------------------------------------------------------
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
