Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
From: "Paul Derbyshire" <derbyshire AT globalserve DOT net>
To: cygwin AT cygwin DOT com
Date: Mon, 29 Jul 2002 22:00:41 -0400
MIME-Version: 1.0
Subject: Re: Mysterious gdb behavior
Reply-to: derbyshire AT globalserve DOT net
Message-ID: <3D45BB09.29941.5BF8654B@localhost>
In-reply-to: <20020729153728.GC16707@redhat.com>
References: <30C9E24891FFD411B68A009027724CB702C04D0B AT eg-002-015 DOT eglin DOT af DOT mil>
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Content-description: Mail message body

On 29 Jul 2002 at 11:37, Christopher Faylor wrote:

> On Mon, Jul 29, 2002 at 08:09:39AM -0500, Keen Wayne A Contr AFRL/MNGG wrote:
> >To add a bit of related trivia to this wonderful thread, I find it
> >interesting that the current relase of Dev-C++ is suffering with a
> >similar problem.  If you set Dev up in the "Program Files" directory,
> >it has crash and burn type problems due to the spaces in the directory
> >name as well.

Starts to seem like pathnames with spaces are just something that 
*have* to be dealt with sensibly if a system is to work 
under/inside/on Win32...

> Hmm.  This is reaching urban myth proportions.
> 
> AFAIK, gdb works fine with a path with spaces in it.  There is no
> indication to the contrary, so far.

AFAIR, this started when I posted a case of gdb mysteriously failing 
to run a process and also failing to produce an error message 
(graphical version) unless you tried from the console. The error 
message in turn indicated (but in a cryptic way that pretty much 
forces someone to ask questions on a mailing list, by only giving a 
mysterious numeric code instead of an understandable error message) 
that a Windows process spawning API found the executable to be 
invalid. Whereupon I posted a screen dump showing that the error 
message was itself in error, because a test executable worked fine 
when launched from the shell and not when run in gdb.

Someone then pointed out a pathname with a space in it in the path to 
the executable and asserted that that was the cause of the problem.

If you are now suggesting that it is not, then I guess we're back to 
square one. Why is gdb choking on the executable, which runs fine 
directly from the command prompt?

I am inclined to think the path *does* have something to do with it, 
simply because gdb seems to try to launch using the full path while 
gdb doesn't, and the only common factor among the executables that 
don't work in gdb is that they are in the same directory tree and the 
others are not. That, and they were all made more recently, but I 
can't see time affecting anything, since gcc is (still!) the same 
version 2.95.something.

> This has been a very strange thread.

Indeed. It has been comforting to note from the Great Ctrl-V Debate 
postings that I'm not the only one to take issue with Randy's 
condescending attitude from time to time. If I'm partly responsible 
for this getting acrimonious at least I'm not wholly responsible. :) 
Chalk it up to a clash of personalities, maybe.

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/