• Using time() leads to binary incompatibility of static executables

    From Peter Keller@21:1/5 to All on Wed Aug 2 16:40:01 2017
    Dear all,

    We have come across a binary compatibility problem involving
    Debian-testing: an executable built from the trivial test program at
    the end of this message segfaults on Debian-testing in the call to the
    time() function, when the executable was built on a CentOS 6 or CentOS
    5 system. We have tested this (both compiling and running) on a
    variety of other distributions, and we have found that the following
    conditions must all be satisfied to trigger the segfault:

    * compilation/linking (with 'gcc -g --static test_time.c'):
    - on CentOS 5 or CentOS 6
    - the executable must be static
    - the executable must be 64-bit
    * running
    - must be run on Debian-testing (kernel 4.11)

    The other distributions that we have used to investigate this further
    include:

    * Debian Stretch (kernel 4.9)
    * CentOS 7 (stock kernel, also kernels 4.4 and 4.12 from <http://elrepo.org/>)
    * openSUSE 42.2 (kernel 4.4)
    * openSUSE Tumbleweed (kernel 4.11)
    * Fedora 26 (kernel 4.11)

    In our hands, the segfault does not happen if the executable is either
    built on one of these other distributions, run on one of them, or
    both.

    For what it is worth, we observe the same behaviour when building with
    various versions of the Intel compilers.

    We have not tested building the executable on RedHat or Scientific Linux systems, but it seems likely that the behaviour would be the same.

    I have tried to search the existing bug list to see if anyone else has
    reported this. I haven't found anything, but my efforts may not have
    been very effective: the search terms for this problem are rather
    general, and some of the search engines that are linked to in the
    section "Searching bug reports" on <https://www.debian.org/Bugs/>
    appear to be broken.

    We would be grateful for any comments from someone with more expertise
    than us in this area. In particular:

    * have we found a bug in Debian-testing, or is binary compatibility
    not to be expected under these circumstances?

    * if it is a bug, which package should we report it under? (glibc?
    linux? some other package?)

    * have upcoming changes in unstable or experimental already
    addressed this issue?

    We are concerned about the possibility that this behaviour might be
    present in Debian Buster when it is officially released.

    Regards,
    Peter Keller

    --------------- test_time.c begins here ------------------
    #include <stdio.h>
    #include <time.h>
    int main()
    {
    time_t now;
    char buffer[26];
    struct tm* tm_info;
    now = time(NULL);
    tm_info = localtime(&now);
    strftime(buffer, 26, "%Y-%m-%d %H:%M:%S", tm_info);
    puts(buffer);
    return 0;
    }
    --------------- test_time.c ends here-- ------------------

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Niels Thykier@21:1/5 to All on Sun Aug 20 08:50:01 2017
    Peter Keller:
    Dear all,


    Hi Peter,

    Thanks for your interest and for testing the issue.

    We have come across a binary compatibility problem involving
    Debian-testing: an executable built from the trivial test program at
    the end of this message segfaults on Debian-testing in the call to the
    time() function, when the executable was built on a CentOS 6 or CentOS
    5 system. We have tested this (both compiling and running) on a
    variety of other distributions, and we have found that the following conditions must all be satisfied to trigger the segfault:

    * compilation/linking (with 'gcc -g --static test_time.c'):
    - on CentOS 5 or CentOS 6
    - the executable must be static
    - the executable must be 64-bit
    * running
    - must be run on Debian-testing (kernel 4.11)


    We very recently got a kernel 4.12.2 in Debian testing:

    * Could you test if that fixes the problem?

    * FYI, there was a glibc migration today. So both has been updated
    recently.

    If not, let us move on to filing an actual bug.

    [...]

    We would be grateful for any comments from someone with more expertise
    than us in this area. In particular:

    * have we found a bug in Debian-testing, or is binary compatibility
    not to be expected under these circumstances?


    I suspect you have found a bug, but I am not entirely sure. At first
    glance, I believe it should work/be compatible. However, I would prefer
    to let people, who understand the technical aspect of the problem,
    answer this part if it has not been fixed by the recent changes. :)

    * if it is a bug, which package should we report it under? (glibc?
    linux? some other package?)


    Good question. When you tested in debian testing with linux 4.9 and
    linux 4.11, was the only different the kernel? If so, I would go for
    the linux kernel.

    If you want/need to retest it, please remember that we have the snapshot.debian.org service, which can provide you with versions of the
    archive as they looked on a given day.

    * have upcoming changes in unstable or experimental already
    addressed this issue?


    Not that I know of, but I have not tried. To be honest, I think you
    might be a better judge of that if you are willing to test unstable. :)

    Anyway, if the recent updates have not fixed the issue, please let us
    look into filing a bug. :)

    Hope it was helpful. :)

    Thanks,
    Niels

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Peter Keller@21:1/5 to Niels Thykier on Wed Aug 23 13:50:03 2017
    Dear Niels,

    Thanks for responding.

    On 20/08/17 06:41, Niels Thykier wrote:
    Peter Keller:
    Dear all,


    Hi Peter,

    Thanks for your interest and for testing the issue.

    We have come across a binary compatibility problem involving
    Debian-testing: an executable built from the trivial test program at
    the end of this message segfaults on Debian-testing in the call to the
    time() function, when the executable was built on a CentOS 6 or CentOS
    5 system. We have tested this (both compiling and running) on a
    variety of other distributions, and we have found that the following
    conditions must all be satisfied to trigger the segfault:

    * compilation/linking (with 'gcc -g --static test_time.c'):
    - on CentOS 5 or CentOS 6
    - the executable must be static
    - the executable must be 64-bit
    * running
    - must be run on Debian-testing (kernel 4.11)


    We very recently got a kernel 4.12.2 in Debian testing:

    * Could you test if that fixes the problem?

    * FYI, there was a glibc migration today. So both has been updated
    recently.

    OK, after doing:

    apt-get update
    apt-get install linux-image-4.12.0
    apt-get upgrade

    and rebooting into the new kernel, the problem persists. On the system I
    set up for testing this, 'uname -a' now gives:

    Linux deb-testing 4.12.0-1-amd64 #1 SMP Debian 4.12.6-1 (2017-08-12)
    x86_64 GNU/Linux

    If not, let us move on to filing an actual bug.

    OK - thanks.


    [...]

    We would be grateful for any comments from someone with more expertise
    than us in this area. In particular:

    * have we found a bug in Debian-testing, or is binary compatibility
    not to be expected under these circumstances?


    I suspect you have found a bug, but I am not entirely sure. At first
    glance, I believe it should work/be compatible. However, I would prefer
    to let people, who understand the technical aspect of the problem,
    answer this part if it has not been fixed by the recent changes. :)

    * if it is a bug, which package should we report it under? (glibc?
    linux? some other package?)


    Good question. When you tested in debian testing with linux 4.9 and
    linux 4.11, was the only different the kernel? If so, I would go for
    the linux kernel.

    Well, this problem came to our attention when a user of our software
    reported problems. He told us that our software worked or failed on
    almost identical systems that differed only in the running kernel (4.9
    and 4.11). We then narrowed it down to the time() function.

    Unfortunately, our Debian guru is on holiday and I am more familiar with
    other distros. I haven't been able to work out a way of installing
    kernel 4.9 into Debian-testing that I am happy with, so I haven't tested
    this myself. Is it OK to put something like the following in /etc/apt/sources.list:

    deb http://ftp.uk.debian.org/debian/ stable main

    and do 'apt-get install linux-image-4.9.0', or would that cause other
    problems?

    Sorry for the long-winded answer, but it looks at the moment that it
    does depend on the kernel.

    If you want/need to retest it, please remember that we have the snapshot.debian.org service, which can provide you with versions of the archive as they looked on a given day.

    Thanks, I'll bear that in mind.


    * have upcoming changes in unstable or experimental already
    addressed this issue?


    Not that I know of, but I have not tried. To be honest, I think you
    might be a better judge of that if you are willing to test unstable. :)

    Anyway, if the recent updates have not fixed the issue, please let us
    look into filing a bug. :)

    Hope it was helpful. :)

    Yes, very, many thanks. What are the next steps towards filing this a
    bug? With a hint about the proper way to install kernel 4.9 into Debian-testing, I could easily check with that kernel version first.

    Regards,
    Peter.

    --
    Peter Keller Tel.: +44 (0)1223 353033
    Global Phasing Ltd., Fax.: +44 (0)1223 366889
    Sheraton House,
    Castle Park,
    Cambridge CB3 0AX
    United Kingdom

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)