[uml-devel] [[email protected]: Bug#271069: gdb startup fails in tracefork check]
----- Forwarded message from Stephen McCamant <[email protected]> -----
Date: Fri, 10 Sep 2004 18:09:07 -0400
From: Stephen McCamant <[email protected]>
Resent-From: Stephen McCamant <[email protected]>
To: [email protected]
Subject: Bug#271069: gdb startup fails in tracefork check
Package: user-mode-linux
Version: 2.4.26-2um-1
With the current versions of UML and GDB in sarge, with a 2.4.x host kernel (no SKAS support, so this is in tt mode), gdb runs into an error when UML tries to start it as requested by a "debug" option. For instance, given the invocation
% linux debug
the contents of the "UML kernel debugger" window are:
GNU gdb 6.1-debian
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-linux"...(no debugging symbols found)...Using host libthread_db library "/lib/libthread_db.so.1".
/tmp/gdb_init-lnsVCy:1: Error in sourced command file:linux_test_for_tracefork: waitpid: Interrupted system call. (gdb)
and then GDB doesn't function correctly (for instance, it refuses to set breakpoints).
The generated gdb_init file looks like:
att 1
b panic
b stop
handle SIGWINCH nostop noprint pass
b start_kernel
c
where the line 1 the error refers to is "att 1". Despite the message, though, I don't think the error comes from the init file, but rather from part of GDB's startup process: linux_test_for_tracefork(), from the file linux-nat.c in the GDB source, is used to check whether the kernel supports various options to ptrace which, if present, allow GDB to follow children that fork. To do this, GDB forks a child process, waits for the child to stop itself, then sets some ptrace options and has the child fork. When run on its own, the test executes without problems, but when gdb is started by UML, the waitpid call that gdb uses to wait for the first child to call PTRACE_TRACEME is unexpectedly interrupted; the EINTR return value is what makes gdb error out.
If I edit the source to gdb so that the function immediately returns a "not-available" result without actually doing the test, and use that modified gdb instead of the regular one, debugging the UML kernel works as I would expect.
I'm seeing this with the 6.1-3 package of gdb, a Debian-standard 2.4.26-1-k7-smp (2.4.26-4) kernel, and libc 2.3.2.ds1-13.
Let me know if I can provide any more information to help track this down.
-- Stephen
Signature · 18 lines
To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] ----- End forwarded message ----- -- - mdz ------------------------------------------------------- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php _______________________________________________ User-mode-linux-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
Quoted 16 lines · Matt Zimmerman
----- Forwarded message from Stephen McCamant <[email protected]> -----
Date: Fri, 10 Sep 2004 18:09:07 -0400
From: Stephen McCamant <[email protected]>
Resent-From: Stephen McCamant <[email protected]>
To: [email protected]
Subject: Bug#271069: gdb startup fails in tracefork checkPackage: user-mode-linux
Version: 2.4.26-2um-1With the current versions of UML and GDB in sarge, with a 2.4.x host kernel (no SKAS support, so this is in tt mode), gdb runs into an error when UML tries to start it as requested by a "debug" option. For instance, given the invocation
Quoted 12 lines
where the line 1 the error refers to is "att 1". Despite the message, though, I don't think the error comes from the init file, but rather from part of GDB's startup process:
linux_test_for_tracefork(), from the filelinux-nat.cin the GDB source, is used to check whether the kernel supports various options to ptrace which, if present, allow GDB to follow children that fork. To do this, GDB forks a child process, waits for the child to stop itself, then sets some ptrace options and has the child fork. When run on its own, the test executes without problems, but when gdb is started by UML, the waitpid call that gdb uses to wait for the first child to callPTRACE_TRACEMEis unexpectedly interrupted; the EINTR return value is what makes gdb error out.
Well, when gdb receives EINTR, it should just retry the failed call. It's a general rule. In fact, in these days we are applying a lot of such patches to fix such bugs for UML.
So, file a bug-report to gdb developers.
UML may have his part in triggering this bug, so we may fix it, too.
Quoted 4 lines
If I edit the source to gdb so that the function immediately returns a "not-available" result without actually doing the test, and use that modified gdb instead of the regular one, debugging the UML kernel works as I would expect.
Try fixing it as I suggest above. I.e., when call fails and errno == EINTR, retry the same identical call (without changing *anything*).
Bye
Signature · 13 lines
Paolo Giarrusso, aka Blaisorblade Linux registered user n. 292729 ------------------------------------------------------- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php _______________________________________________ User-mode-linux-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel