Bug 136138

Summary: bad parse in strace on FC2 with 64bit lseek
Product: [Fedora] Fedora Reporter: Maciej Żenczykowski <zenczykowski>
Component: straceAssignee: Roland McGrath <roland>
Status: CLOSED NOTABUG QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 2   
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: 2004-10-20 00:02:38 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 Maciej Żenczykowski 2004-10-18 08:52:45 UTC 
Version: strace-4.5.5-1
Reproducible: Always

On 32bit x86 the 64bit _llseek seems to be badly parsed by strace.

lseek64(fd,0x80000000ULL,SEEK_SET);

results in a strace:

_llseek(3, 18446744071562067968, [2147483648], SEEK_SET) = 0

instead of:

_llseek(3, 2147483648, [2147483648], SEEK_SET) = 0

note that 18446744071562067968 == 0xFFFFFFFF80000000,
so basically somehow 0x80000000 is turning into 0xFFFFFFFF80000000.

Can anyone confirm this - or am I totally lost here?

As far as I can tell the problem is definetely with strace, passing in
the correct parameters by hand via asm into the kernel still results
in a wrong strace, and the kernel accepts the values and allows the
seek, and returns the expected value as the result.
Comment 1 Roland McGrath 2004-10-19 22:55:37 UTC 
I cannot reproduce any such problem with 4.5.5-1 on x86.  My test program does
exactly the lseek64 call in your report.  Please provide a verified test case to
reproduce the problem.
Comment 2 Maciej Żenczykowski 2004-10-20 00:02:38 UTC 
Sorry for the mixup, I've just discovered a local different (unknown
version) copy of strace in /usr/local/bin.  The /usr/bin version which
is from FC2 does work correctly.  My Error, once again sorry.