Bug 64281

Summary: glibc-2.2.5-34 static linked mkstemp fails with "errno: 22 (Invalid argument)"
Product: [Retired] Red Hat Linux Reporter: Henrik Nordstrom <redhat>
Component: glibcAssignee: Jakub Jelinek <jakub>
Status: CLOSED RAWHIDE QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: medium    
Version: 7.2CC: fweimer
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2002-05-01 16:36:36 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Henrik Nordstrom 2002-05-01 15:13:12 UTC
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
applications.

Dynamically linked applications work just fine

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


How reproducible:
Always

Steps to Reproduce:
---- test program ----
#include <stdlib.h>
#include <stdio.h>
#include <errno.h>
#include <string.h>
main()
{
    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
./a.out

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
./a.out

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
2.2.5-34.

Comment 1 Henrik Nordstrom 2002-05-01 16:36:31 UTC
Seems to be a compiler or linker problem. The glibc code is correct.

The failing line is

sysdeps/posix/tempname.c:252
	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>

[strcmp(...)]
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-2.11.90.0.8-12 (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.