This is the mail archive of the cygwin@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Mysterious gdb behavior


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

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

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

> 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
  on that.
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*
> document.

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

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

Reasons:
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 
time.

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

> 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
> "hinting".

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 
that's different...

> > (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
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]