Mysterious gdb behavior

[Igor Pechtchanski]

On Fri, 2 Aug 2002, Paul Derbyshire wrote:

> On 31 Jul 2002 at 17:11, Christopher Faylor wrote:

Paul,
First off, you're responding to a post from me, which Chris Faylor quoted.
You seem to think this came from him.  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.

> > >You contradict yourself.  On one hand, you seem to think that everyone who
> > >answers a post on the list is an expert.  On the other, you acknowledge
> > >that some people are here to ask questions, rather than answer them.
>
> Where's the contradiction? People who know the answer to a question
> will frequently respond. People who don't know shouldn't, and usually
> won't, bother to demonstrate their ignorance.

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.

> > >What you don't seem to realize is that there is no clear division between
> > >the two categories.
>
> True. Obviously who the "experts" are is on a question-by-question
> basis. If I ask about cron I figure the responses will come from
> people who know something about cron. If I ask about gdb I figure the
> responses will come from people who know something about gdb. The
> latter set of responders needn't be the same as the former set.

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.

> What I find irritating is getting a response that is patronizing and
> also virtually content-free when it comes to actually answering the
> question. I don't see how such a response can possibly be anything
> other than a waste of bandwitdth, no matter who its from and no
> matter who it replies to and no matter what the actual question was.
> Answers that amount to "I have no idea what's wrong, why don't you
> just go and fix it youself" and so forth. Of course, someone might
> not know what the problem is but feel they might given more
> information -- they should, if interested, respond asking (nicely)
> for that information. Say, the output of such and such a command with
> these options, or whatever.

I don't see how asking, for example, for the output of cygcheck is
patronising or content-free.  In fact, it was one of the most intelligent
requests on the matter.  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.  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.  You would have
seen the exact command line for cygcheck.  If you've tried that, you would
have found that cygcheck is included with your system.  It's also
mentioned multiple times in the FAQ.

> > >People answering a question may be (and probably are)
> > >other users who are not experts, but vaguely remember hearing something
> > >about a similar problem, and are genuinely trying to offer helpful
> > >suggestions.
>
> 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.

> Suggestions to research the source code and fix it yourself instead
> of "whining" on the list are also *not* helpful.

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.

> Suggestions to memorize the FAQ, search the web, and so forth are *not*
> helpful.

Noone expects you to memorize the FAQ.  Whenever you encounter an
unfamiliar concept, though, the first thing you should do is search the
FAQ *AGAIN* rather than complain to the list -- it'll save everyone (you
included) a lot of time and bandwidth.

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

> > >The difference in opinion about the cause of your problem is just that -
> > >different people offering their theories on what caused your problem.
>
> I never interpreted it any other way. I did, however, post some
> information indicating that one of the theories is wrong. Narrowing
> it down, of course, being an essential part of any problem solving
> process.
>
> > >This is not easy, as the symptoms you describe don't seem to be
> > >reproducible, even by the experts (and Chris Faylor is one).  It's your
> > >right to prefer one theory to another, but the scientific method also
> > >requires trashing theories that are not substantiated by facts, and
> > >experimenting to determine the validity of any particular theory.
>
> Trashing theories that are contradicted by facts. Not merely not
> substantiated. Absence of evidence is not evidence of absence.

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.

> So far two theories were proposed -- one, that the space is a
> problem, two, that the problem executables got built with the wrong
> gcc. I've verified that gcc from the bash prompt calls the correct
> gcc, and the problem executables were built by calling gcc from the
> bash prompt, which seems to torpedo theory two. Theory one is all
> that's left unless anyone has a theory three to offer.

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.  If the debug still fails,
theory one is also torpedoed.  If the debug succeeds, we look into theory
one further.  The fact that other executables did not present debugging
problems does not in itself prove or disprove anything - it's *that
particular executable* that has to be held "constant" while other
parameters are varied.  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.  That's why most of the experiments are so hard
to perform -- eliminating variables is a problem.

> One thing that struck me as weird was the way the proponent of theory
> two hinted obliquely at it for three days before bothering to
> explicitly state what he suspected. Once he did so it was a simple
> and obvious test at a bash prompt to dispatch it and move on. Three
> days of time wasted by people not being straightforwardly
> communicative...

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

> > >Experiments, I may add, that other people have suggested, and that you
> > >don't seem to have performed (e.g., trying the same sequence of actions
> > >from a directory with no spaces in the name, or varying other parameters).
>
> Don't seem to have performed? I posted a while back when the two
> theories were that spaces caused the problem or that the EXE was
> actually malformed to state that the executable works from the
> prompt, suggesting it's not malformed, just not from gdb.

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.

> and that gdb has consistently worked for executables in a directory
> without a space in the path and consistently failed for executables in a
> directory with a space in the path.  Thus your suggested experiment
> above has effectively been performed and I did say as much on the list a
> while ago!

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

> > >Please remember that there rarely are ready answers to complex problems.
> > >People on this list try to help, but they (even the experts) are not
> > >omniscient.  Neither are they infallible.  It's possible that some
> > >suggestions for possible causes and solutions don't pan out.
>
> 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...

> [Snippage]
>
> It looks like you have the impression that I've begrudged people for
> suggesting things that didn't work. That's not true. The only things
> that have irritated me here have been suggestions too vague or
> ridiculous (memorize this, don't use the list for what it was created
> for) to be useful and a certain patronizing attitude two or three
> responders exhibited. (I haven't heard from them in a while, and I
> suppose they did the wise thing and killfiled me.)

Paul, don't forget the motto of cygwin developers: "We're just mean".
	Igor
-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_		pechtcha@cs.nyu.edu
ZZZzz /,`.-'`'    -.  ;-;;,_		igor@watson.ibm.com
     |,4-  ) )-,_. ,\ (  `'-'		Igor Pechtchanski
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

It took the computational power of three Commodore 64s to fly to the moon.
It takes a 486 to run Windows 95.  Something is wrong here. -- SC sig file


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