64bit integer division broken on 32bit armhf

[Wolfgang Wendnagel]

Integer division for 64 bit integers is emulated on 32 bit devices. Unfortunately it does not work properly on armhf (see example below):

Since this problem seems to be in libgcc_s.so.1 many programs are theoretically affected and may therefore crash. I have tested it with Ubuntu 16.04 on different devices with an ARMv7 SOC (e.g. Nano Pi Duo, OrangePi) .

Output of valgrind --leak-check=yes ./test :
--------------------------------------------

==7342== Memcheck, a memory error detector
==7342== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==7342== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==7342== Command: ./test
==7342==
==7342== Invalid write of size 4
==7342== at 0x4867B52: ??? (in /lib/arm-linux-gnueabihf/libgcc_s.so.1)
==7342== Address 0xbdc10470 is on thread 1's stack
==7342== 16 bytes below stack pointer
==7342==
==7342== Conditional jump or move depends on uninitialised value(s)
==7342== at 0x48692FE: __udivmoddi4 (in /lib/arm-linux-gnueabihf/libgcc_s.so.1)
==7342==
==7342== Use of uninitialised value of size 4
==7342== at 0x4869300: __udivmoddi4 (in /lib/arm-linux-gnueabihf/libgcc_s.so.1)
==7342==
==7342== Use of uninitialised value of size 4
==7342== at 0x4867BA2: ??? (in /lib/arm-linux-gnueabihf/libgcc_s.so.1)
==7342==
==7342==
==7342== HEAP SUMMARY:
==7342== in use at exit: 0 bytes in 0 blocks
==7342== total heap usage: 1 allocs, 1 frees, 1,024 bytes allocated
==7342==
==7342== All heap blocks were freed -- no leaks are possible
==7342==
==7342== For counts of detected and suppressed errors, rerun with: -v
==7342== Use --track-origins=yes to see where uninitialised values come from
==7342== ERROR SUMMARY: 5 errors from 4 contexts (suppressed: 6 from 3)

Code:
-----

#include <stdio.h>

int main(){

 signed long long int value1 = 999;
 signed long long int value2 = -333;
 value1 = value1 / value2;

 printf("value1: %lli\n", value1);

 return 0;
}

lsb_release -rd :
-----------------

Description: Ubuntu 16.04.4 LTS
Release: 16.04

[Seth Arnold (seth-arnold)]

Rumours suggest this is a valgrind issue.

[Jamie Strandboge (jdstrand)]

I took a look at this and am unable to reproduce. The test program compiles and ran fine on an Ubuntu 16.04 system:

$ ./test
value1: -3

Running this under valgrind I see:

$ valgrind --leak-check=yes ./test
==16237== Memcheck, a memory error detector
==16237== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==16237== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==16237== Command: ./test
==16237==
==16237== Invalid write of size 4
==16237== at 0x1049A: ??? (in /home/jdstrand/test)
==16237== Address 0xbdf19540 is on thread 1's stack
==16237== 16 bytes below stack pointer
==16237==
==16237== Conditional jump or move depends on uninitialised value(s)
==16237== at 0x10610: __udivmoddi4 (in /home/jdstrand/test)
==16237==
==16237== Use of uninitialised value of size 4
==16237== at 0x10612: __udivmoddi4 (in /home/jdstrand/test)
==16237==
==16237== Use of uninitialised value of size 4
==16237== at 0x104EA: ??? (in /home/jdstrand/test)
==16237==
value1: -3
==16237==
==16237== HEAP SUMMARY:
==16237== in use at exit: 0 bytes in 0 blocks
==16237== total heap usage: 1 allocs, 1 frees, 1,024 bytes allocated
==16237==
==16237== All heap blocks were freed -- no leaks are possible
==16237==
==16237== For counts of detected and suppressed errors, rerun with: -v
==16237== Use --track-origins=yes to see where uninitialised values come from
==16237== ERROR SUMMARY: 5 errors from 4 contexts (suppressed: 6 from 3)

(not free from errors, but it didn't crash and value is correct).

$ lsb_release -a
Distributor ID: Ubuntu
Description: Ubuntu 16.04.6 LTS
Release: 16.04
Codename: xenial

$ gcc --version
gcc (Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.11) 5.4.0 20160609

The test was performed on a Beagle Bone Black, raspberry pi2 and pi3. There does not appear to be a general problem with current gcc-5 on Ubuntu 16.04. Unmarking as security for now, but please provide more info on how to reproduce and this can be revisited. Since this doesn't seem to be an issue with valgrind, marking that as invalid and gcc-5 as Incomplete.

[Jamie Strandboge (jdstrand)]

I do not have access to and Orange Pi or NanoPi Duo. I suggest trying again with an updated toolchain and see if you still have the issue, and if so, specify the gcc invocation and board information. Thanks!

[Launchpad Janitor (janitor)]

[Expired for gcc-5 (Ubuntu) because there has been no activity for 60 days.]