This is the mail archive of the
mailing list for the Cygwin project.
Re: Mysterious gdb behavior
- From: "Paul Derbyshire" <derbyshire at globalserve dot net>
- To: cygwin at cygwin dot com
- Date: Fri, 2 Aug 2002 23:42:13 -0400
- Subject: Re: Mysterious gdb behavior
- References: <3D49FDDC.1758.6C9D6C99@localhost>
- Reply-to: derbyshire at globalserve dot net
On 2 Aug 2002 at 10:55, Igor Pechtchanski wrote:
> Secondly, the post started with "I hope you don't take it as an
> insult, as it wasn't intended to be", which you obviously
Perhaps it was insulting even though it wasn't intended to be? In any
case, if I responded as though to an insult, you can trust that there
was something in there that would, whether that was the intent or
not, leave a negative belief about me floating around if not
> Non-experts can and will answer posts. Anyone can offer a guess at what's
> happening if your symptoms sound similar to what they've experienced.
> This does not make them experts.
Nor does it offend me as long as they make clear that they are
> No, what I meant was that the question will be answered by experts and
> non-experts alike. Your expectation that any answer will be from an
> expert is erroneous, and has to be corrected.
Don't call me erroneous. This is what I mean about insults. Talking
to me as though I were a wayward child in need of correction is rude.
Doing so in public is also humiliating. That is both rude and utterly
inexcusable, and forces me to respond to correct the poor impression
of me that it attempts to propagate. That, in turn, wastes bandwidth.
If you feel the need to talk down to me DO IT IN PRIVATE EMAIL!
Anyway, I didn't expect that any answer would be from an expert. I
expected that any answer would contain at least some attempt at
actual help, and not just a uselessly vague remark and a batch of
unwelcome insults! In any other time and place than the apparently
peculiar political climate of this list, any answer *would* be an
honest attempt at help -- i.e. not insulting, not even worded in a
way prone to being interpreted as insulting, and not pointlessly
vague or content-free. IIRC, this branch has erupted from my
objecting to getting responses like "edit /etc/passwd, you idiot"
(paraphrasing -- the "you idiot" was actually a long diatribe that
implied rather than explicitly stated the insulting payload) that
offer no real information. (The tempting reply is "Of course you edit
/etc/passwd, you asshole, but *what change do you make, and what
other changes elsewhere, and what else should I look out for,
especially given that Cygwin usernames and Winblows usernames
interact, dammit???* -- my actual reply was far more civil if you
check the archives or were here to read it at the time.)
> I don't see how asking, for example, for the output of cygcheck is
> patronising or content-free.
That one was neither. What it was was still vague enough to require
me to come back to the list with yet another question. Telling me to
use foo program that a) isn't obviously already around, like regedit
or grep, and b) I don't recall seeing listed as a package in setup,
without providing a) a URL or b) its source code or telling me that
c) it was probably installed with this package or can be had by using
setup to install that package, leaves me with incomplete information.
Also, my response to that one was perfectly civil. Someone mentions
cygcheck. I don't know what this is or where to obtain it, if I don't
already have it. So I ask the obvious question. Unfortunately, nobody
here likes being asked questions -- rather peculiar for a list whose
expected use includes this sort of Q&A...
> While you can't be expected to *memorize* the
> documentation, you can be expected to search it for things that everyone
> using Cygwin (or at least reporting a bug) should know.
What is the boundary of what "everyone using Cygwin should know"? If
I don't search for something, rest assured that I have every reason
to believe it's not going to be found. I might not know that
"everyone using Cygwin should know" foo. I figure two things:
* The FAQ will contain information about Cygwin's operation in
general. It won't contain package-specific information. Not
everyone installs gdb -- therefore it's doubtful that the FAQ will
contain this specific gdb error, and so searching it is probably a
waste of time -- don't bother.
* The documentation for a specific package will contain information
You'll note that my original Mysterious gdb behavior posting notes
that I searched gdb's documentation for the error number that was
reported and found nothing.
> Since what you were doing was, in all appearance, reporting a bug,
> you should have followed the link at the bottom of every message
> (the one with "bug reporting" in front of it) and read the *whole*
I should have done nothing of the kind. At that point I had every
reason to suspect some goof or misconfiguration rather than a bug.
Therefore my post to the list was geared toward identifying the
misconfiguration. Of course I did regard the obscure error reporting
as tantamount to a bug, and the silent failure if the console wasn;t
displayed as a definite bug, but I figured to eventually track down a
bug reporting address for gdb and report those there. These were
clearly issues with gdb in general, not Cygwin-specific, and also
tangential to the primary problem which was to find out why it
encountered an error trying to debug that executable -- an error I
considered likely to result from a misconfiguration rather than a
> You would have seen the exact command line for cygcheck.
And information about where cygcheck can be found, or stating that it
should be already installed, or whatever?
Anyway, it's starting to sound like either:
* Everyone should read that file whether or not they believe what
they're reporting is a genuine bug, or
* Some of what's in that file belongs in the FAQ.
> If you've tried that, you would have found that cygcheck is
> included with your system.
I have found that out, recently. Funny this wasn't mentioned anywhere
obvious. (And no, the bugs page you've referenced isn't somewhere
obvious when one is not yet sure there's a genuine bug involved.)
> > Let's clarify a bit. Suggestions too vague to produce anything but a
> > reply asking the suggester to be more specific are *not* helpful.
> Questions saying "there's something wrong with my cygwin, fix it" are
> *not* helpful.
Straw man. Questions saying "gdb refuses to run <foo executable here>
and says <specific error message>; I searched the documentation for
this error message and found nothing" are perfectly fine. The only
thing I could see adding in this instance being the version number.
> When you've programmed a large set of big projects, you won't remember
> your own source code. Your reply most of the time would be "I don't
> remember, I have to look at the code". Since you're probably busy at the
> time with something else, and since someone has to look at the code
> anyway, why not the questioner? This is not a punishment, this is an
> attempt to have you recover as much info as possible.
1. The questioner doesn't have the familiarity with the source code
that the maintainer/some other expert does. The maintainer can
zero in on the relevant section in seconds; the questioner
probably would need hours just to isolate the correct source
*file* to investigate more closely. Thus, the questioner is being
asked to do a large amount of work to save someone else a small
amount of work. Hardly what I'd call efficient use of man/hours.
2. In connection with #1, a quick result might be crucial. The
problem, whatever it is, may be causing a work stoppage that is
costing someone money.
3. In the case of Cygwin, someone might not *have* the source, and
the download would take an obnoxious amount of time, and they may
also be pressed for disk space.
Undoubtedly I could add many more plausible reasons to the above; in
my case #1 definitely applies.
There's also this: If someone felt competent to, and felt they had
the time to, solve it themselves, they wouldn't post to the list. If
someone posts to the list it strongly implies that it's beyond their
expertise or time constraints to DIY. And that in turn means a
response telling them to DIY is a priori unlikely to be other than a
waste of bandwidth.
> Noone expects you to memorize the FAQ.
Someone implied I should have done so. Not you, presumably.
> Whenever you encounter an unfamiliar concept, though, the first
> thing you should do is search the FAQ *AGAIN*...
Which unfamiliar concepts? Surely not all of them? Unfamiliar stuff
is mentioned all the time in any technical forum. Nobody with merely
human attention span and stamina can follow the latest jargon and
lingo for every computer-related field simultaneously. I know C and
compilers and have dabbled in Java; data structures and algorithms
are second nature to me; but start talking to me about database query
languages or LAN administration and I'd be reaching for that FAQ
every third word. It could quickly grow to consume a huge amount of
Of course, because the FAQ is apparently updated frequently, forget
using a local copy. I'd have to go open a Web browser, wait the half
a minute or so for it to crank itself laboriously into a working
state, go to the FAQ URL (after first finding it again with a search -
- I don't recall it offhand), edit/find some text, ...
Doing this once might be a five minute job. Doing it before pretty
much every posting to the list would consume hours out of every day.
It wouldn't be a problem if I were posting only the odd question, but
because five or six people feel the need to harass me and attempt to
tar me with various unpleasant brushes in followups to each and every
post I make, and each of these in turn requires a rebuttal or other
defense, this would turn into a time-wasting nightmare even worse
than it already is.
> rather than complain to the list -- it'll save everyone (you
> included) a lot of time and bandwidth.
The only thing I've *complained* about has been uncivil treatment and
vague or incomplete information. If someone has the time and
knowledge to post something vague and incomplete they have the time
and knowledge to post something more specific and useful. Uncivil
treatment lacks any excuse I can conceive.
> > Searching (not memorizing!) the FAQ and documentation of course is to
> > be expected, but such a search has probably already been attempted
> > and given the user insufficient information by the time the thread
> > even starts, so suggesting they do it again, when it will just
> > produce the same results as the first time, is *not* helpful.
> See above. The point that you seem to miss is that you are expected to
> search the FAQ for *different* concepts every time.
Such as? The sequence is this.
1. Problem with gdb.
2. Search documentation. Fixed or:
3. Solve problem on list.
The problem solving steps are simple: try to solve it with the
documentation on hand. If this isn't enough, then switch strategies:
get the answer off the mailing list. I don't see why the
documentation should enter into it again.
Of course, we've had exchanges like:
1. Problem with gdb.
2. Search documentation. Not fixed:
3. Ask on list -- reply says we have:
4. Problem with spaces in path name.
I report problem A, someone says it's caused by problem B, and I
guess now you expect me to research problem B. Doesn't it save a lot
of time and effort all around if someone simply posts the *solution*
instead of this indirection that adds to my workload? It's no wonder
I don't want to "hit the books" a second time. Once should be enough.
If my problem isn't in the FAQ, it's time to ask the expert, and
being referred back to the FAQ feels like going in circles.
Besides, in this instance I didn't need the FAQ. I remembered what it
said about spaces in path names. It warned that they might cause
problems, which they apparently do only with gdb among the many
things I use, and said zip about what to do if they do cause problems
save the obvious quoting of arguments in scripts and the like, none
of which suggestions applied in the case of an internal communication
between one binary (gdb) and another (some Winblows DLL) via an API
> True, should've checked my wording. However, the facts that would
> contradict the theories have to come from experiments, done with the
> specific purpose of contradicting the theory.
I've followed most of the suggested experiments. (Messing with the
shell's environment, with the config files, and with changing
Winblows/cygwin user names has been considered a last resort given
the risk of breaking something.)
> Theory one is just as easy to verify or disprove - just move *the exact
> executable* that's giving you problems out of the directory with a space
> in its name, and try to debug it from there.
This was suggested a while ago, and the result suggests that the
spacey path names are indeed the problem.
Now can we cut out the verbiage and flames, which have today actually
gone from smoke to open fire, and actually think about solving it?
> Going back to the scientific method, experiments
> with too many things varied are worthless, as you don't really know which
> factor caused the change.
The executables weren't exactly the same, but they were all compiled
using the same copy of gcc, so I figured they were interchangeable.
> The theory was not at all obvious. It was a wild guess on his part, a
> chord struck by something you mentioned in a completely separate thread.
True. (Tries to recall disputing this...hmm, seems I never did.)
> However, to verify that the gcc and the gdb you're using are both part of
> cygwin would be common sense and should have been done by you with no
That the gcc and gdb I was using were the ones in /usr/bin and not
ones further down the search path was itself common sense.
> gdb has to read the information about the executable from its header. If
> the header is malformed, gdb will fail. Not as much information is needed
> to run the executable (e.g., just the starting address), so a malformed
> header may not affect the execution from the prompt as much as it would
> affect gdb.
Moot. The same executable has failed in one place and worked in
another. Anyway, someone had said it was a Windows "bad exe format"
error -- not a gdb-specific one. Thus an error associated with
running the binary rather than associated specifically with
debugging. Also, I'd imagine gdb tries to read the header at launch
rather than only when you go to "run" the image. It would probably
fail on startup with a genuinely malformed exectable.
> How many executables did you verify this on? Did you move an existing
> (working and debuggable) executable into a directory with a space in it
> and try to debug it from there? Did you move a problem executable out of
> the directory with the space in it and try to debug it from there? There
> are too many variables here...
Eventually, yes; see above.
> > And I don't hold it against anyone if they don't. I'm not mad at the
> > guy who suggested the wrong gcc was being invoked. At least, not for
> > turning out to be wrong. For beating around the bush for ages
> > perhaps.
> Oh, yes, the experts just have to be omniscient and see the correct answer
> right away...
No! But if you think something is the cause, say so instead of being
vague! Why is it that people keep misunderstanding what I'm saying?
The meaning of the English sentences I've used are not in the least
ambiguous. I keep saying that I am irritated by insults or by vague
answers, and that nowhere have I been irritated purely because
someone had no answer or took ages to come up with one. Irritated
once when someone had no answer but posted, uselessly and in fact
insultingly, anyway; irritated once when someone took
ages to post their answer after hinting at it for days; yes, but
> > (I haven't heard from them in a while, and I
> > suppose they did the wise thing and killfiled me.)
Would that this were true. Apparently they were just spending a day
planning a new onslaught with truly despicable slander tactics.
> Paul, don't forget the motto of cygwin developers: "We're just mean".
This justifies what, exactly?
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html