NetBSD Problem Report #40647
From mouse@Sparkle.Rodents-Montreal.ORG Sun Feb 15 13:53:07 2009
Return-Path: <mouse@Sparkle.Rodents-Montreal.ORG>
Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11])
by narn.NetBSD.org (Postfix) with ESMTP id 6720F63C17C
for <gnats-bugs@gnats.NetBSD.org>; Sun, 15 Feb 2009 13:53:07 +0000 (UTC)
Message-Id: <200902151353.IAA16996@Sparkle.Rodents-Montreal.ORG>
Date: Sun, 15 Feb 2009 08:46:22 -0500 (EST)
From: der Mouse <mouse@Rodents-Montreal.ORG>
Reply-To: mouse@Rodents-Montreal.ORG
To: gnats-bugs@gnats.NetBSD.org
Subject: [dM] gdb breaks under non-readable dirs
X-Send-Pr-Version: 3.95
>Number: 40647
>Category: toolchain
>Synopsis: [dM] gdb breaks under a non-readable directory
>Confidential: no
>Severity: serious
>Priority: low
>Responsible: toolchain-manager
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Sun Feb 15 13:55:02 +0000 2009
>Originator: der Mouse
>Release: NetBSD 4.0 (also seen on 3.1)
>Organization:
Dis-
>Environment:
System: NetBSD NetBSD-4-0.Rodents.Montreal.QC.CA 4.0 NetBSD 4.0 (GEN40) #0: Mon Nov 24 05:05:05 EST 2008 mouse@NetBSD-4-0.Rodents.Montreal.QC.CA:/home/mouse/kbuild/GEN40 i386
Architecture: i386
Machine: i386
>Description:
gdb breaks badly under some circumstances which appear to
amount to "getwd fails", at least when the failure is due to a
non-readable ancestor to the current directory. See
how-to-repeat for the exact symptoms observed; they appear to
all be based on some kind of perceived need on the part of the
gdb author(s) to access the program being debugged by an
absolute pathname. Under 4.0, gdb --version reports version
6.5; under 3.1, 5.3nb1.
>How-To-Repeat:
As root:
# mkdir /root/z /root/z/y
# chmod 711 /root/z
# chown mouse /root/z/y
(presumably any other non-root user will do as well as mouse,
here and below)
As mouse:
% cd /root/z/y
% cp /bin/cat .
% gdb cat
...
(gdb) run
BFD: reopening /cat: No such file or directory
`/cat' has disappeared; keeping its symbols.
Starting program: /cat
csh: Permission denied
csh: Trying to start from "/home/mouse"
/cat: Command not found.
Program exited with code 01.
BFD: reopening /cat: No such file or directory
You can't do that without a process to debug.
(gdb)
Using "env SHELL=sh gdb cat" changes the symptoms slightly,
because sh is less obnoxious about its cwd on startup, but the
basic problem with gdb appears to be the same:
(gdb) run
BFD: reopening /cat: No such file or directory
`/cat' has disappeared; keeping its symbols.
Starting program: /cat
exec: /cat: not found
Program exited with code 0177.
BFD: reopening /cat: No such file or directory
BFD: reopening /cat: No such file or directory
BFD: reopening /cat: No such file or directory
BFD: reopening /cat: No such file or directory
warning: Unable to find dynamic linker breakpoint function.
GDB will be unable to debug shared library initializers
and track explicitly loaded dynamic code.
You can't do that without a process to debug.
(gdb)
>Fix:
Much as I hate "don't do that, then", the closest thing to a
workaround I know of is to just not do that; don't try to debug
in directories having ancestors unreadable by the user. A real
fix would have to be implemented in gdb, and my understanding
of gdb is far too weak to know how involved it would be to fix
this curious compulsion to refer to the program being debugged
by full pathname for no visible reason. (This same tendency
can be observed during normal debugging when gdb prints a full
pathname when starting to run the program.)
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML mouse@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
(Contact us)
$NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD: gnats_config.sh,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2007
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.