Bug 171323 - insufficent ptrace status when a thread calls exec
insufficent ptrace status when a thread calls exec
Status: CLOSED UPSTREAM
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
4
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Dave Jones
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-10-20 15:18 EDT by Tom Horsley
Modified: 2015-01-04 17:22 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-12-10 02:58:32 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
test program to show the status debuggers get in this case (11.96 KB, text/plain)
2005-10-20 15:20 EDT, Tom Horsley
no flags Details

  None (edit)
Description Tom Horsley 2005-10-20 15:18:49 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050922 Fedora/1.0.7-1.1.fc4 Firefox/1.0.7

Description of problem:
In the somewhat bizarre case of a thread in a multi-threaded program
doing an exec() call, the status information a debugger this is debugging
this strange program gets back is, to say the least, confusing. The thread
that did the exec() call just sort of disappears and the main thread first
says it is about to exit, then says it exec()ed.

It would be much simpler on the poor old debugger if instead of getting
an about to exit extended status (PTRACE_EVENT_EXIT) we could invent a
new extended status just for this strange case (maybe PTRACE_THREAD_EXEC).

I'll attach my test program that demos the confusion.

Version-Release number of selected component (if applicable):
kernel-2.6.13-1.1526_FC4

How reproducible:
Always

Steps to Reproduce:
1. gcc -o thread-exec-bug -g thread-exec-bug.c -lpthread
2. ./thread-exec-bug

  

Actual Results:  The main thread first gets an "about to exit" status, then later instead
of exiting, gets an exec()ed status.

The thread that actually does the exec() call just disappears. No additional
status ever shows up for it (as far as the debugger knows, it is still running).


Expected Results:  Good question, but the simplest thing for the debugger would probably be
a new extended status code to explicitly tell me a thread did an exec
and therefore all the other threads will disappear and I should expect
to see the actual exec show up in the main thread real soon now.

Additional info:
Comment 1 Tom Horsley 2005-10-20 15:20:35 EDT
Created attachment 120204 [details]
test program to show the status debuggers get in this case
Comment 2 Dave Jones 2005-11-10 14:13:25 EST
2.6.14-1.1637_FC4 has been released as an update for FC4.
Please retest with this update, as a large amount of code has been changed in
this release, which may have fixed your problem.

Thank you.
Comment 3 Tom Horsley 2005-11-11 07:45:34 EST
Tried test prog on new 1637 kernel - still behaves the same way. The thread
that calls exec() just completely disappears with no status reported to debugger
and the main thread still gets an "about to exit" status, then doesn't exit,
but instead exec()s.
Comment 4 Dave Jones 2005-12-10 02:58:32 EST
I recommend bringing this up upstream at linux-kernel@vger.kernel.org as any
behavioural change needed here is going to have to be something that is
universally acceptable (or we get "this only works on Red Hat kernels", which is
never a good thing).

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