linux-um archives
 help / color / mirror / Atom feed
* [uml-devel] [smcc@CSAIL.MIT.EDU: Bug#271069: gdb startup fails in tracefork check]
@ 2004-09-10 22:26 Matt Zimmerman
  2004-09-11 15:37 ` BlaisorBlade
  0 siblings, 1 reply; 2+ messages in thread
From: Matt Zimmerman @ 2004-09-10 22:26 UTC (permalink / raw)
  To: user-mode-linux-devel; +Cc: Stephen McCamant, 271069-forwarded

----- Forwarded message from Stephen McCamant <smcc@CSAIL.MIT.EDU> -----

Date: Fri, 10 Sep 2004 18:09:07 -0400
From: Stephen McCamant <smcc@CSAIL.MIT.EDU>
Resent-From: Stephen McCamant <smcc@CSAIL.MIT.EDU>
To: submit@bugs.debian.org
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


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

----- 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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: [uml-devel] [smcc@CSAIL.MIT.EDU: Bug#271069: gdb startup fails in tracefork check]
  2004-09-10 22:26 [uml-devel] [smcc@CSAIL.MIT.EDU: Bug#271069: gdb startup fails in tracefork check] Matt Zimmerman
@ 2004-09-11 15:37 ` BlaisorBlade
  0 siblings, 0 replies; 2+ messages in thread
From: BlaisorBlade @ 2004-09-11 15:37 UTC (permalink / raw)
  To: user-mode-linux-devel; +Cc: Matt Zimmerman, Stephen McCamant, 271069-forwarded

On Saturday 11 September 2004 00:26, Matt Zimmerman wrote:
> ----- Forwarded message from Stephen McCamant <smcc@CSAIL.MIT.EDU> -----
>
> Date: Fri, 10 Sep 2004 18:09:07 -0400
> From: Stephen McCamant <smcc@CSAIL.MIT.EDU>
> Resent-From: Stephen McCamant <smcc@CSAIL.MIT.EDU>
> To: submit@bugs.debian.org
> 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

> 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.

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.

> 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
-- 
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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2004-09-11 15:40 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-09-10 22:26 [uml-devel] [smcc@CSAIL.MIT.EDU: Bug#271069: gdb startup fails in tracefork check] Matt Zimmerman
2004-09-11 15:37 ` BlaisorBlade

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox