2.1.111 fix for debugger ptrace(PTRACE_ATTACH, ...) side-effects

2.1.111 fix for debugger ptrace(PTRACE_ATTACH, ...) side-effects

[Eric PAIRE]

Hi Linus,

As part of my development of gdb for multithreaded applications, I have
found bugs in the way the Linux kernel manages processes dynamicly attached
by a debugger.

The summary of the bugs, the SMP-safe fix explanation and the patch file
are all available at http://www.gr.opengroup.org/java/jdk/linux/kernel1.htm

Best regards,
-Eric
P.S. The patch file contains the fix against a clean 2.1.111
P.S.2 I have just seen that the 2.1.112 is out (and that a cleaner 2.1.113
	is about to be available :-) If you want me to adapt the fix for
	2.1.113 and test it on my 4-way SMP, just let me know. Right now,
	it works correctly on 2.1.111.
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ Eric PAIRE
Email : e.paire@gr.opengroup.org  | THE Open GROUP - Grenoble Research 
Institute
Phone : +33 (0) 476 63 48 71 	  | 2, avenue de Vignate
Fax   : +33 (0) 476 51 05 32	  | F-38610 Gieres      FRANCE



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html

Re: 2.1.111 fix for debugger ptrace(PTRACE_ATTACH, ...) side-effects

[Benjamin Saller Bender]

On Wed, 29 Jul 1998, Eric PAIRE wrote:
> The summary of the bugs, the SMP-safe fix explanation and the patch file
> are all available at http://www.gr.opengroup.org/java/jdk/linux/kernel1.htm

	I have seen additional problems which may or may not be related. I
think that the debug registers are not being cleared during context
switching, or at all for that matter? (I haven't looked into the
kernel code yet)

	The following is a reproducable example of what I am talking
about. This is on  linux-2.1.111 SMP 

-----------------------------

[//loki/src/registry2] gdb test_parser                          
GNU gdb 4.17
This GDB was configured as "i386-redhat-linux"...

(gdb) b registry_parse_object 
Breakpoint 1 at 0x804a5a6: file registry_parser.c, line 118.
(gdb) r
Starting program: /loki/seg_components/src/registry2/test_parser 

Breakpoint 1, registry_parse_object (lex=0x804ea28, input=0x804ea60)
    at registry_parser.c:118
118       char *name = 0;
(gdb) rwatch lex->tok
Hardware read watchpoint 2: lex->tok
(gdb) c
Continuing.
warning: Hardware watchpoint 2: Could not insert watchpoint

Hardware read watchpoint 2: lex->tok

Value = 0
registry_lex_token (lex=0x804ea28, input=0x804ea60) at registry_lex.c:531
531               return NAME;
(gdb) c
Continuing.
warning: Hardware watchpoint 2: Could not insert watchpoint

Hardware read watchpoint 2: lex->tok

Value = 0
0x804a5c4 in registry_parse_object (lex=0x804ea28, input=0x804ea60)
    at registry_parser.c:121
121       if(lex->tok != NAME)
(gdb) q
The program is running.  Exit anyway? (y or n) y
[//loki/src/registry2] ./test_parser                            11:21AM Wed 29 
zsh: 5877 trace trap  ./test_parser
[//loki/src/registry2] ./test_parser                            11:21AM Wed 29 
test: line    2 pos   3: Unexpected 'semicolon', should be a basic type
zsh: 5882 trace trap  ./test_parser



Could this extend to other processes as well? I am not really all that
well aware of how hardware breakpoints work on x86 and in the kernel, but
it seems that if the address is marked with a breakpoint and another
process got that address on the next pass? *Shurg*


Benjamin Saller Bender 			<case@AppliedTheory.com>
AppliedTheory Communications		Software Engineering Group


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html