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

NetBSD Home
NetBSD PR Database Search

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