Hi all,
I noticed a 32 bit overflow in the Timer::Connection sleep functions and triggers. Calling usleep or trigger_once with an hour (3 600 000 000 us) works but calling it with two hours (7 200 000 000 us) causes something to overflow and stop the timer after 2 905 032 704 us which equals 7 200 000 000 & (2^32 - 1).
As far as I have checked this these functions use the unsigned long which is indeed 64 bit but I think at some point only 32 bit are used.
Is this intended behaviour? If so I think it would make sense to give out a warning at least.
Regards, Johannes
Johannes,
Unsigned longs are 4 bytes. Unsigned long longs are 8 bytes. One byte equals 8 bits.
Bob Stewart
Get Outlook for Androidhttps://aka.ms/ghei36
________________________________ From: Johannes Kliemann <kliemann@...543...> Sent: Sunday, February 18, 2018 6:01:36 AM To: Genode OS Framework Mailing List Subject: 32 bit overflow in timer
Hi all,
I noticed a 32 bit overflow in the Timer::Connection sleep functions and triggers. Calling usleep or trigger_once with an hour (3 600 000 000 us) works but calling it with two hours (7 200 000 000 us) causes something to overflow and stop the timer after 2 905 032 704 us which equals 7 200 000 000 & (2^32 - 1).
As far as I have checked this these functions use the unsigned long which is indeed 64 bit but I think at some point only 32 bit are used.
Is this intended behaviour? If so I think it would make sense to give out a warning at least.
Regards, Johannes
------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Hi Bob,
The long is not necessarily defined as 4 bytes. I have checked the GNU reference manual [1] and it states
The 32-bit unsigned long int data type can hold integer values in the range of at least 0 to 4,294,967,295. (Depending on your system, this data type might be 64-bit, in which case its range is identical to that of the unsigned long long int data type.) You may also refer to this data type as unsigned long.
So it can be 64bit long. I have tested this on x86_64 Linux and x86_64 Genode on NOVA and in both cases the sizeof(unsigned long) returned 8. So it is a 64 bit integer type. I also tested this by assigning 2^32 which should yield 0 on a 32 bit type but it didn't.
Regarding this the overflow is most probably happening at some lower level (I have not checked the exact implementation of the timer).
Regards, Johannes
[1]: https://www.gnu.org/software/gnu-c-manual/gnu-c-manual.html#Integer-Types
Am 18.02.2018 um 20:59 schrieb Bob Stewart:
Johannes,
Unsigned longs are 4 bytes. Unsigned long longs are 8 bytes. One byte equals 8 bits.
Bob Stewart
Get Outlook for Android https://aka.ms/ghei36
*From:* Johannes Kliemann <kliemann@...543...> *Sent:* Sunday, February 18, 2018 6:01:36 AM *To:* Genode OS Framework Mailing List *Subject:* 32 bit overflow in timer  Hi all,
I noticed a 32 bit overflow in the Timer::Connection sleep functions and triggers. Calling usleep or trigger_once with an hour (3 600 000 000 us) works but calling it with two hours (7 200 000 000 us) causes something to overflow and stop the timer after 2 905 032 704 us which equals 7 200 000 000 & (2^32 - 1).
As far as I have checked this these functions use the unsigned long which is indeed 64 bit but I think at some point only 32 bit are used.
Is this intended behaviour? If so I think it would make sense to give out a warning at least.
Regards, Johannes
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot
genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Hi Johannes, That's interesting, I did the sizeof test on my base-hw kernel set up on 17.11 before I sent that reply. Bob
Get Outlook for Androidhttps://aka.ms/ghei36
________________________________ From: Johannes Kliemann <kliemann@...543...> Sent: Sunday, February 18, 2018 3:59:43 PM To: genode-main@lists.sourceforge.net Subject: Re: 32 bit overflow in timer
Hi Bob,
The long is not necessarily defined as 4 bytes. I have checked the GNU reference manual [1] and it states
The 32-bit unsigned long int data type can hold integer values in the range of at least 0 to 4,294,967,295. (Depending on your system, this data type might be 64-bit, in which case its range is identical to that of the unsigned long long int data type.) You may also refer to this data type as unsigned long.
So it can be 64bit long. I have tested this on x86_64 Linux and x86_64 Genode on NOVA and in both cases the sizeof(unsigned long) returned 8. So it is a 64 bit integer type. I also tested this by assigning 2^32 which should yield 0 on a 32 bit type but it didn't.
Regarding this the overflow is most probably happening at some lower level (I have not checked the exact implementation of the timer).
Regards, Johannes
[1]: https://www.gnu.org/software/gnu-c-manual/gnu-c-manual.html#Integer-Types
Am 18.02.2018 um 20:59 schrieb Bob Stewart:
Johannes,
Unsigned longs are 4 bytes. Unsigned long longs are 8 bytes. One byte equals 8 bits.
Bob Stewart
Get Outlook for Android https://aka.ms/ghei36
*From:* Johannes Kliemann <kliemann@...543...> *Sent:* Sunday, February 18, 2018 6:01:36 AM *To:* Genode OS Framework Mailing List *Subject:* 32 bit overflow in timer
Hi all,
I noticed a 32 bit overflow in the Timer::Connection sleep functions and triggers. Calling usleep or trigger_once with an hour (3 600 000 000 us) works but calling it with two hours (7 200 000 000 us) causes something to overflow and stop the timer after 2 905 032 704 us which equals 7 200 000 000 & (2^32 - 1).
As far as I have checked this these functions use the unsigned long which is indeed 64 bit but I think at some point only 32 bit are used.
Is this intended behaviour? If so I think it would make sense to give out a warning at least.
Regards, Johannes
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot
genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Hi Johannes,
El 18/02/18 a las 12:01, Johannes Kliemann escribió:
Hi all,
I noticed a 32 bit overflow in the Timer::Connection sleep functions and triggers. Calling usleep or trigger_once with an hour (3 600 000 000 us) works but calling it with two hours (7 200 000 000 us) causes something to overflow and stop the timer after 2 905 032 704 us which equals 7 200 000 000 & (2^32 - 1).
As far as I have checked this these functions use the unsigned long which is indeed 64 bit but I think at some point only 32 bit are used.
Is this intended behaviour? If so I think it would make sense to give out a warning at least.
I printed sizeof(unsigned) (Timer::Connection::usleep takes unsigned), and it says 4. Therefore, it seems natural to me that you can't input numbers greater than 71 minutes and 34 seconds which are approximately 2^32 us. For greater timeouts you could use msleep(unsigned) (up to 49 days and 17 hours). The best way, however, would be to use the higher-level Timeout framework (see Timer::Periodic_timeout and Timer::One_shot_timeout). Admittedly, we try to get rid of directly using the Timer::Connection entirely. The new framework is safer and adds features like scheduling one timer session among multiple timeouts. By now, it doesn't support timeouts greater than 71 minutes and 34 seconds but it is on my TODO list to fix this soon.
Cheers, Martin
A small remark...
On Mon, Mar 05, 2018 at 02:49:18PM +0100, Martin Stein wrote:
For greater timeouts you could use msleep(unsigned) (up to 49 days and 17 hours).
This will not work as msleep(ms) just calls usleep(1000*ms).
El 05/03/18 a las 15:29, Christian Helmuth escribió:
A small remark...
On Mon, Mar 05, 2018 at 02:49:18PM +0100, Martin Stein wrote:
For greater timeouts you could use msleep(unsigned) (up to 49 days and 17 hours).
This will not work as msleep(ms) just calls usleep(1000*ms).
Oh, sorry, I wasn't aware of that. Thanks for the clarification!
-
Bob Stewart -
Christian Helmuth -
Johannes Kliemann -
Martin Stein