After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 783841 - test_GDateTime_new_from_timeval_overflow fails on 32 bit systems
test_GDateTime_new_from_timeval_overflow fails on 32 bit systems
Status: RESOLVED FIXED
Product: glib
Classification: Platform
Component: general
2.53.x
Other Linux
: Normal normal
: ---
Assigned To: gtkdev
gtkdev
Depends on:
Blocks:
 
 
Reported: 2017-06-15 22:00 UTC by Iain Lane
Modified: 2017-06-21 10:22 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
gdatetime: Fix a potential overflow in overflow calculations (1.25 KB, patch)
2017-06-16 11:47 UTC, Philip Withnall
committed Details | Review
tests: Fix GDateTime overflow tests on 32-bit architectures (2.55 KB, patch)
2017-06-16 11:47 UTC, Philip Withnall
committed Details | Review
tests: Fix overflows in find_maximum_supported_tv_sec() (1.67 KB, patch)
2017-06-19 12:59 UTC, Philip Withnall
committed Details | Review

Description Iain Lane 2017-06-15 22:00:13 UTC
I just uploaded 2.53.2 to Ubuntu, where we run the installed-tests for all arches. We're seeing:

# Start of new_from_timeval tests
# Bug Reference: http://bugzilla.gnome.org/782089
**
GLib:ERROR:../../../../../glib/tests/gdatetime.c:417:test_GDateTime_new_from_timeval_overflow: 'dt' should be NULL
# GLib:ERROR:../../../../../glib/tests/gdatetime.c:417:test_GDateTime_new_from_timeval_overflow: 'dt' should be NULL
FAIL: glib/gdatetime.test (Child process killed by signal 6)

on i386 and armhf (32 bit architectures).

I don't know what all the overflow cases are here, but

  tv.tv_sec = G_MAXLONG;

on 32 bit is going to be < G_MAXINT64, so the check in g_date_time_new_from_timeval doesn't trigger us to return NULL.
Comment 1 Philip Withnall 2017-06-16 11:47:05 UTC
Created attachment 353888 [details] [review]
gdatetime: Fix a potential overflow in overflow calculations

I can’t remember whether glong (tv.tv_sec) needs to be explicitly
promoted to gint64 here, or whether C does it automatically. Safer to
make the cast explicit to avoid overflow issues on 32-bit platforms,
where glong is 32-bit.

Signed-off-by: Philip Withnall <withnall@endlessm.com>
Comment 2 Philip Withnall 2017-06-16 11:47:11 UTC
Created attachment 353889 [details] [review]
tests: Fix GDateTime overflow tests on 32-bit architectures

On architectures where sizeof(glong) == 32 bits, there are no problems
with overflow when constructing a GDateTime from a GTimeVal. Adjust the
test for this by basing it on the maximum supported tv_sec value it can
calculate, rather than a fixed ‘known unsupported’ value.

Signed-off-by: Philip Withnall <withnall@endlessm.com>
Comment 3 Philip Withnall 2017-06-16 11:50:48 UTC
I don’t have a 32-bit system to test these on, so if you could give them some review and a test run, that would be great. Thanks.
Comment 4 Iain Lane 2017-06-16 17:54:23 UTC
(In reply to Philip Withnall from comment #3)
> I don’t have a 32-bit system to test these on, so if you could give them
> some review and a test run, that would be great. Thanks.

I'm running it now in an Ubuntu VM, and I think the test (test_GDateTime_new_from_timeval_overflow) is spinning.

find_maximum_supported_tv_sec is alternating between

(MSG: trying tv.tv_sec = 715827882, highest_success = 3579139413, lowest_failure = 2147483647)
(MSG: trying tv.tv_sec = 3579139413, highest_success = 715827882, lowest_failure = 2147483647)

Sorry, don't have time right this second to dig into it further. I can either over the weekend or on Monday morning if you'd like
Comment 5 Philip Withnall 2017-06-19 12:59:12 UTC
Created attachment 354041 [details] [review]
tests: Fix overflows in find_maximum_supported_tv_sec()

The addition (highest_success + lowest_failure) could have overflowed,
and typically would do on 32-bit platforms where the real
highest_success should be G_MAXLONG. Fix that, and introduce special
handling of the corner case of (highest_success = G_MAXLONG).

Signed-off-by: Philip Withnall <withnall@endlessm.com>
Comment 6 Philip Withnall 2017-06-19 13:00:04 UTC
(In reply to Iain Lane from comment #4)
> (In reply to Philip Withnall from comment #3)
> > I don’t have a 32-bit system to test these on, so if you could give them
> > some review and a test run, that would be great. Thanks.
> 
> I'm running it now in an Ubuntu VM, and I think the test
> (test_GDateTime_new_from_timeval_overflow) is spinning.

Oops, looks like there was an overflow problem in it. The latest attached patch should fix that but, as before, I’ve only been able to test it on a 64-bit machine.
Comment 7 Iain Lane 2017-06-19 14:54:57 UTC
(In reply to Philip Withnall from comment #5)
> Created attachment 354041 [details] [review] [review]
> tests: Fix overflows in find_maximum_supported_tv_sec()
> 
> The addition (highest_success + lowest_failure) could have overflowed,
> and typically would do on 32-bit platforms where the real
> highest_success should be G_MAXLONG. Fix that, and introduce special
> handling of the corner case of (highest_success = G_MAXLONG).
> 
> Signed-off-by: Philip Withnall <withnall@endlessm.com>

This seems to make sense to me, and it makes the tests pass, thanks!

I just applied it manually and ran the one test; doing a full build now and will report back if it fails. If I don't comment again, then you can assume it worked.
Comment 8 Philip Withnall 2017-06-21 10:22:09 UTC
I’m assuming that’s all fine then. Thanks for testing!

Attachment 353888 [details] pushed as 2db7aa4 - gdatetime: Fix a potential overflow in overflow calculations
Attachment 353889 [details] pushed as 30fed3b - tests: Fix GDateTime overflow tests on 32-bit architectures
Attachment 354041 [details] pushed as 428acd9 - tests: Fix overflows in find_maximum_supported_tv_sec()