+++ This bug was initially created as a clone of Bug #243816 +++ Escalated to Bugzilla from IssueTracker -- Additional comment from tao on 2007-06-12 00:10 EST -- Hi Folks, Wehn doing analysis using the ESP and EIP values in ps under 64-bit RHEL 4.4. I seem top only see the low 32-bits of the addreses when using "ps -e -o eip,esp". Should this have been extended or are there plans to introduce new namely fields so as not to break perceived API's? Thanks for your help. Kind regards, Ken. This event sent from IssueTracker by csnook [SEG - Base OS] issue 115947 -- Additional comment from tao on 2007-06-12 00:10 EST -- Just to confirm, so far as I can tell it's indeed the case here and I don't see any obvious way to change the behavior nor alternate variables for it. Passing up for review. <snip> [root@dl585 ~]# ps -e -o pid,eip,esp PID EIP ESP 1 7cbbf8f5 ffffffff 2 00000000 00000000 3 00000000 00000000 <snip> 4307 7cbb9272 ffffffff 6839 7cbb9272 ffffffff 8419 7cb8f7a2 ffffffff 8509 ffffe405 ffffffff 8761 7cbb9272 ffffffff </snip> Nor is it any different on RHEL5: <snip> [root@localhost ~]# uname -a Linux localhost.localdomain 2.6.18-8.el5xen #1 SMP Fri Jan 26 14:29:35 EST 2007 x86_64 x86_64 x86_64 GNU/Linux [root@localhost ~]# ps -e -o pid,eip,esp PID EIP ESP 1 a62c6b93 ffffffff 2 00000000 00000000 3 00000000 00000000 <snip> 28385 00000000 00000000 28386 00000000 00000000 28389 aafa3b93 ffffffff 29357 a62bfc80 ffffffff 30741 00000000 00000000 </snip> Issue escalated to Support Engineering Group by: fhirtz. Internal Status set to 'Waiting on SEG' This event sent from IssueTracker by csnook [SEG - Base OS] issue 115947 -- Additional comment from tao on 2007-06-12 00:10 EST -- The kernel puts the 64-bit value in /proc/<pid>/stat. Issue moved from 'SEG - Kernel' to 'SEG - Base OS' by: streeter This event sent from IssueTracker by csnook [SEG - Base OS] issue 115947 -- Additional comment from tao on 2007-06-12 00:10 EST -- ps deliberately casts those values to unsigned int and formats them to 8 digits. I'm not sure if that's a bug or that's deliberate to avoid breaking scripts. I'll check with our maintainers. Category set to: Applications::Functions Ticket type set to: 'Problem' This event sent from IssueTracker by csnook [SEG - Base OS] issue 115947 -- Additional comment from tao on 2007-06-12 00:19 EST -- Excerpts from output.c in the procps source package: return snprintf(outbuf, COLWID, "%08x", (unsigned)(pp->kstk_eip)); return snprintf(outbuf, COLWID, "%08x", (unsigned)(pp->kstk_esp)); Clearly this is an intentional cast to a 32-bit integer. Either we need to change this to an unsigned long, or we need to introduce eip64 and esp64 fields so users can get this info conveniently in ps. Issue escalated to RHEL 4 Base OS by: csnook. Internal Status set to 'Waiting on Engineering' This event sent from IssueTracker by csnook issue 115947 -- Additional comment from tsmetana on 2007-06-13 07:44 EST -- I have prepared a patch that adds eip64 and esp64 specifiers that output 16 characters wide columns with 64bit pointers. -- Additional comment from pm-rhel on 2007-06-13 08:04 EST -- This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release.
Created attachment 156969 [details] Proposed patch
procps-3.2.7-14.fc7 has been pushed to the Fedora 7 testing repository. If problems still persist, please make note of it in this bug report.
procps-3.2.7-14.fc7 has been pushed to the Fedora 7 stable repository. If problems still persist, please make note of it in this bug report.