- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - HP-UX
- >
- pstack causes a coredump in getexecpath ().
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-18-2013 05:21 AM - edited 07-18-2013 05:24 AM
07-18-2013 05:21 AM - edited 07-18-2013 05:24 AM
A coredump of pstack is being analyzed by our team:
#7 0x4000000000023da0:0 in getexecpath () at getexecpath.c:211 #8 0x4000000000022230:0 in pstack () at pstack.c:952 #9 0x40000000000216d0:0 in main () at pstack.c:1401
There is a call to free() at getexecpath.c:211 and it results in a coredump. Is it possible that some kind of buffer overflow happens in this line: getexecpath.c:211 inside pstack?
Solved! Go to Solution.
- Tags:
- pstack
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-18-2013 08:59 PM - edited 07-18-2013 11:29 PM
07-18-2013 08:59 PM - edited 07-18-2013 11:29 PM
Re: pstack causes a coredump in getexecpath (on a bogus free)
>There is a call to free at getexecpath.c:211 and it results in a coredump.
You should have left the free line in the stacktrace.
>Is it possible that some kind of buffer overflow happens in this line: getexecpath.c:211 inside pstack?
No, it's worst that that. :-(
Please contact Support and file a bug report. You can have them contact me for details.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-19-2013 05:11 AM - edited 07-19-2013 05:14 AM
07-19-2013 05:11 AM - edited 07-19-2013 05:14 AM
Re: pstack causes a coredump in getexecpath (on a bogus free)
It seems that I managed to find a problem in HP pstack with HP gdb.
So I run "gdb pstack" and then set "set heap-check on". Then I do "run <PID>". And after that I get sometimes RTC_BAD_FREE. It means that pstack calls free and passes it an unallocated or already freed object!
As one can see from "info shared" below I use only HP libraries and HP utilities:
(gdb) show heap-check Thread debugging commands is "on". Current heap check settings are : Check leaks : on Check bounds : on Check free() : on Check string : off Scrambling : off Frame count : 12 Min-leak-size : 0 Min-heap-size : 0 Block-size : 0 Header-size : 16 Footer-size : 1 Seed-value : 5 Random-range : 100 Null-check : -1 Null-check-size : -1 Heap-size : 0 Heap Interval : 0 Repeat Count : 100 High-mem Count : 0 Watch Address : 0x00000000 retain-freed-blocks : off (gdb) r 1772 Starting program: /usr/ccs/bin/pstack 1772 warning: Attempt to free unallocated or already freed object at 0x9fffffffffffda20 __rtc_event (ecode=RTC_BAD_FREE, pointer=0x9fffffffffffda20, pclist=0x0, size=0) at ../../../Src/gnu/gdb/infrtc.c:2145 2145 ../../../Src/gnu/gdb/infrtc.c: No such file or directory. in ../../../Src/gnu/gdb/infrtc.c (gdb) bt #0 __rtc_event (ecode=RTC_BAD_FREE, pointer=0x9fffffffffffda20, pclist=0x0, size=0) at ../../../Src/gnu/gdb/infrtc.c:2145 #1 0x9fffffffff6022b0:0 in rtc_record_free (pointer=<not available>, free_the_block=<not available>, is_realloc=<not available>) at ../../../Src/gnu/gdb/infrtc.c:3968 #2 0x9fffffffff604d20:0 in free (p=0x9fffffffffffda20) at ../../../Src/gnu/gdb/infrtc.c:4484 #3 0x4000000000023da0:0 in getexecpath () at getexecpath.c:211 #4 0x4000000000022230:0 in pstack () at pstack.c:952 #5 0x40000000000216d0:0 in main () at pstack.c:1401 (gdb) info sharedlibrary Shared Object Libraries tstart tend dstart dend gp /usr/lib/hpux64/dld.so 0x9fffffffff640000 0x9fffffffff6f95f0 0x9fffffffff63a000 0x9fffffffff63fa38 0x9fffffffff63cf30 /opt/langtools/lib/hpux64/librtc.so 0x9fffffffff5c8000 0x9fffffffff632690 0x9fffffffff4e2000 0x9fffffffff5c7958 0x9fffffffff554968 /usr/lib/hpux64/libunwind.so.1 0x9fffffffff478000 0x9fffffffff4df410 0x9fffffffff6fe000 0x9fffffffff6fed68 0x9fffffffff6fe9e0 /usr/lib/hpux64/libuca.so.1 0x9fffffffff46c000 0x9fffffffff474020 0x9fffffffff633000 0x9fffffffff633150 0x9fffffffff633128 /usr/lib/hpux64/libc.so.1 0x9fffffffff100000 0x9fffffffff3b9ba0 0x9fffffffff453000 0x9fffffffff4692b8 0x9fffffffff45ce98 /usr/lib/hpux64/libcl.so.1 0x9fffffffff4e1000 0x9fffffffff4e150c 0x9fffffffff4e0000 0x9fffffffff4e0018 0x9fffffffff4e0010 /usr/lib/hpux64/libCsup.so.1 0x9fffffffff3ec000 0x9fffffffff44af80 0x9fffffffff3e4000 0x9fffffffff3ea3d8 0x9fffffffff3e96a8 /usr/lib/hpux64/libdl.so.1 0x9fffffffff3dc000 0x9fffffffff3e03b0 0x9fffffffff477000 0x9fffffffff4774f0 0x9fffffffff4770e8 /usr/lib/hpux64/libIO77.so.1 0x9ffffffffef24000 0x9fffffffff0ff2f0 0x9fffffffff3c2000 0x9fffffffff3db978 0x9fffffffff3ce738 Total of 9 shared libraries.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-19-2013 05:18 AM - edited 07-21-2013 11:19 PM
07-19-2013 05:18 AM - edited 07-21-2013 11:19 PM
Re: pstack causes a coredump in getexecpath (on a bogus free)
Just to clarify. At first I ran pstack with TCMalloc. TCMalloc::free() coredumps in case it gets a pointer that has not been allocated before. HP libc allocator and HP MallocNG allocator do not cause a coredump with pstack. Nevertheless when I run HP pstack under HP gdb with "set heap-check on " I get RTC_BAD_FREE. So there is undefined behavior in HP pstack.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-20-2013 01:02 AM - edited 07-25-2013 07:44 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-25-2013 09:29 AM
07-25-2013 09:29 AM
Re: pstack causes a coredump in getexecpath (on a bogus free)
Reproduced this issue in pstack. As Dennis sugested Please contact Support and file a bug report.