Bug 64281 - glibc-2.2.5-34 static linked mkstemp fails with "errno: 22 (Invalid argument)"
glibc-2.2.5-34 static linked mkstemp fails with "errno: 22 (Invalid argument)"
Product: Red Hat Linux
Classification: Retired
Component: glibc (Show other bugs)
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2002-05-01 11:13 EDT by Henrik Nordstrom
Modified: 2016-11-24 10:00 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2002-05-01 12:36:36 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Henrik Nordstrom 2002-05-01 11:13:12 EDT
From Bugzilla Helper:
User-Agent: Mozilla/4.78 [en] (X11; U; Linux 2.4.16-0.4custom i686)

Description of problem:
mkstemp always fails with "errno: 22 (Invalid argument)" on statically linked

Dynamically linked applications work just fine

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
---- test program ----
#include <stdlib.h>
#include <stdio.h>
#include <errno.h>
#include <string.h>
    char tmp[256] = "/tmp/test-XXXXXX";
    int fd = mkstemp(tmp);
    printf("FD: %d errno: %d (%s)\n", fd, errno, strerror(errno));
--- end ---

gcc -static test.c

Actual Results:  FD: -1 errno: 22 (Invalid argument)

Expected Results:  FD: 3 errno: 0 (Success)

this is also the result seen if the program is linked dynamically

gcc test.c

Additional info:

I were previosly running another rawhide version 2.2.90-something. There the
problem was not seen.

The problem started after upgrading to 2.2.5-something, but I did not realise
statically linked mkstemp was the culpit until today after upgrading to
Comment 1 Henrik Nordstrom 2002-05-01 12:36:31 EDT
Seems to be a compiler or linker problem. The glibc code is correct.

The failing line is

	if (len < 6 || strcmp (&tmpl[len - 6], "XXXXXX"))

more specifically the strcmp call..

[len < 6]
0x8059f22 <__gen_tempname+46>:  repnz scas %es:(%edi),%al
0x8059f24 <__gen_tempname+48>:  not    %ecx
0x8059f26 <__gen_tempname+50>:  lea    0xffffffff(%ecx),%eax
0x8059f29 <__gen_tempname+53>:  cmp    $0x5,%eax
[so far everything OK..]
0x8059f2c <__gen_tempname+56>:  jle    0x8059f4d <__gen_tempname+89>

0x8059f2e <__gen_tempname+58>:  mov    0x8(%ebp),%edx
0x8059f31 <__gen_tempname+61>:  lea    0xfffffffa(%eax,%edx,1),%ebx
0x8059f35 <__gen_tempname+65>:  mov    %ebx,%esi
[so far fine.. esi points to the last 6 characters of tmpl]

0x8059f37 <__gen_tempname+67>:  mov    $0x809ce49,%edi

[oops.. what happened here.. $0x809ce49 ougt to be the address of the  "XXXXXX" 
string constant, but the value is " medium type".]

0x8059f3c <__gen_tempname+72>:  mov    $0x7,%ecx
0x8059f41 <__gen_tempname+77>:  repz cmpsb %es:(%edi),%ds:(%esi)
0x8059f43 <__gen_tempname+79>:  seta   %dl

Looking closer... extracting tempname.o from libc.a. The above reference is 0x21
in .rodata.str.1.1, which correcly is "XXXXXX", so this seems to be some kind of
problem with binutils, not glibc.

I am currently using binutils- (the current RedHat-7.2 version).

Will now try your current version of binutils.

Works just fine. Sorry for wasting your time.

To help others who incrementally upgrade their development system you might want
to consider making glibc-devel-2.2.5 require a new version of binutils.

Note You need to log in before you can comment on or make changes to this bug.