Using time() leads to binary incompatibility of static executables

Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Using time() leads to binary incompatibility of static executables

Peter Keller
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-- ------------------

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Using time() leads to binary incompatibility of static executables

Niels Thykier
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

Loading...