Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , 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" To: cygwin AT cygwin DOT com Date: Wed, 31 Jul 2002 14:52:26 -0400 MIME-Version: 1.0 Subject: Re: Mysterious gdb behavior. Reply-to: derbyshire AT globalserve DOT net Message-ID: <3D47F9AA.10912.64BD0B1E@localhost> In-reply-to: <20020730041408.GA25902@redhat.com> References: <3D45BB09 DOT 16152 DOT 5BF8657A AT localhost> Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body On 30 Jul 2002 at 0:14, Christopher Faylor wrote: > We're sorry! We're sorry, ok? Sob. Why oh why did anyone ever > suggest reading documentation? It's just wrong! Wrong! Straw man? I'm not quite sure what fallacy this is, but it's some sort of equivocation. I am not irritated at being asked to use the documentation. I'm irritated that I'm apparently expected to read *all* of it cover to cover and memorize it, and moreover to do so before posting to the list, *each* post to the list, even replies. That's too much to expect of anyone. > >In this case, I just got a cryptic "unable to spawn process, error > >193" or such. This didn't prove to be a fruitful search, in the FAQ > >(the copy I downloaded when I got cygwin, months ago) or elsewhere. > > Yep, that old from months ago copy of the FAQ. No reason to consult > anything but that... Indeed. If it's on topic but not fair game on the list it belongs in the FAQ. > >If you won't meet a user who has a problem halfway, and instead expect > >the users to solve problems entirely by themselves, then why are you > >participating in this mailing list responding to questions? I question > >your motives. > > I think we all expect that we offer a suggestion and the user actually > tries it. In this case, the suggestion was made that the problem might > have something to do with directories with spaces in them. So I should have tried something to do with directories with spaces in them. But what, exactly? This is what I mean. "How do I fix problem A?" "It's caused by problem B." "How do I fix problem B? And you didn't actually answer the original question which was HOW DO I FIX not WHAT CAUSES problem A." -- unproductive iterations and a waste of bandwidth. Why not just answer the explicit question someone asks? It would save a lot of headaches all around, not to mention bandwidth. > I posted what the error message resolved to. Did you go the extra step > of trying to do a specific google search on ERROR_BAD_EXE_FORMAT? No, why the hell would I? It's obvious what it means: that the Windows API thinks it was told to execute a file that isn't executable, or is corrupt in some way. I imagine you'd get that if you tried to execute a Word file with that API, for example. In any case it says "something's wrong with the executable file", and in this case, nothing's wrong with the executable file since it runs and works perfectly at the command prompt. (This being my test case for the gdb problem, not the original thing I wanted to debug.) So the error is itself in error, and researching what it normally means doesn't accomplish much. Plus, the procedure is this: Check docs, FAQ, and maybe mailing list archives for key phrases (such as "error 193"). If not found, give up on reference material. Ask the mailing list and wait for an answer. Problem is, instead of an answer it's suggested that I go right back to square one, to the reference material... > Or did you get sidetracked in your nonstop responses to people who > suggested the "directories with spaces" argument? Most of those people have kept posting things that require I respond to defend myself. This is rather unfortunate as it wastes everyone's time and clutters the list. I don't see, though, how that's relevant here. > I'll answer for you. You chose the latter. You don't trust google but > you do trust any random person who responds on a mailing list. No, I trust google in a limited way, and I expect that lists like this will have experienced and helpful people who will be wise enough not to respond if they don't know the answer and not to respond uselessly. (Notice that I don't expect the list *not* to have people that are *not* like that -- condescending sorts seem to be everywhere on Usenet and mailing lists, and there'll obviously be people asking questions as well as people answering them.) The "limited way" I trust Google is that I trust it to find Web pages mentioning keywords, and that's it. It can't be expected to do more. It doesn't generally occur to me to spend half an hour trying random phrases in Google on the off chance of a lucky strike when I can simply ask someone instead -- people are far more reliable, in general, at determining relevancy than search engine robots. Besides, if it's a frequently asked question it belongs in the FAQ and if not it doesn't fail to belong on the list (assuming all the while that it's on topic). > You apparently trust them so blindly that you do not even do > empirical experiments to see if their assertions are correct even > though providing clear explanations about what you tried would > actually be helpful to the whole process. Does someone with a diagnosis from a doctor second-guess the doctor? Often. Do they put themselves through medical school for eight years to come up with their own diagnosis? No, they ask for a second opinion. Here I've asked for a diagnosis on a list full of doctors and got two conflicting opinions. Now what do I do? One thing I won't do is spend eight years in medical school just to fix gdb. I *do* have one bit of evidence favoring the directory names with spaces side. I've gdb'd a bunch of things with cygwin, but all of it has been in one of just two directories. One has no space anywhere in the path and the other does. gdb failed for every executable in the latter and worked for every executable in the former. If it's not the space it's still almost gotta be something about the path, rather than about the executables themselves. > Btw, here's a URL for you: http://cygwin.com/bugs.html . Should have > suggested this when you first posted. I suspect a cygcheck -r -s -v > would be useful in debugging your problem (see below). Not knowing whether it was a cygwin-specific problem or not I was leery of going to a bug submission page to report what might be a general gdb problem. Plus, I suspected a misconfiguration of some kind, or perhaps a Winblows hiccup that might go away with a reboot or an update patch. > Now that you provided more details in another thread. I wonder if it is > possible that you're somehow not using the cygwin gcc compiler but are, > instead, using the djgpp compiler. No, that's affected cron but not the command line. gcc at the command line definitely uses cygwin's gcc. Indeed, gcc --version at the bash prompt says 2.95.3-5 and gcc --version at a Winblows prompt says 3.04. (Hmm, seems djgpp has a more up to date port than cygwin does...) > If so, that could explain your > problem. I don't have a djgpp compiler to confirm but I suspect that > cygwin/windows gdb probably can't debug executables built with the djgpp > gcc, i.e., as far as gdb is concerned the EXE FORMAT is BAD and that's > considered an ERROR. Nice theory, but it just doesn't fit the facts. Also, how long have you suspected it might be using the wrong gcc? It seems in hindsight you've been hinting at that for ages. If you'd just said it straight out the first time you thought it we could have laid the theory to rest that much faster and saved both of us some time, and the list some bandwidth. -- 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/