Re: [patch] fix for infinite recursion in lookup_symbol

[Daniel Berlin <dberlin at redhat dot com>]

On Fri, 12 Jan 2001, Jim Ingham wrote:

> Daniel,
>
> I am not ragging on you specifically, but it is very very lame (almost
> warranting the epithet "egregiously heinous") that a crashing bug has
> sat around in the gdb sources for three months or so - with a KNOWN
> fix!

Yup.
I agree completely.
I take full responsibility for the bug itself, since it was my code that
did it, but it's not something that wasn't noticed, and didn't have a fix.


> Particularly one that is triggered by simple actions  like trying
> to print instance data in only moderately complicated C++ objects.
>

> I understand that there is some argument over whether the current
> implementation of C++ symbol lookup is the right one, but while it is in
> place, simple fixes to it need to get into the sources quickly.

I'd happily check them in under an obvious bugfix rule, but I don't want
to step on any toes.
I had enough fun doing that trying to figure out what exact areas of code
C++ maintainer covers, and I still couldn't tell you.
If someone with definite maintainership over the symbol tables says I can
check in the fixes, i'll do it. Otherwise, i won't.
Sorry.


> It is
> not sufficient to say that the crash was reported in this forum -
> Fernando didn't make the connection either, and he is no slouch to say
> the least...

Err, i'm curious, if you noticed a problem with crashes trying to print
C++ objects, why didn't you ask me or Jim, as i'm C++ maintainer, and he's
symbol table maintainer.

>  And most gdb users don't read gdb patches. Sure,
i'll give you that.

>
> Just like no user error, no matter how stupid, should ever result in a
> crash, no patch that keeps gdb from crashing should be refused unless
> the maintainer can come up with another solution quickly.  It is one
> thing if gdb doesn't find a symbol, or reports some data wrong.  That is
> bad, but there is leisure to argue over method, since users can
> generally work around it and still get their job done.  If gdb crashes -
> particularly on a common code path, then users are just stuck...
If they use CVS versions, yes.

>
> If it is really the case that this patch is waiting on Jim's approval,
> do we need to have a "fast track crash prevention approval mechanism" in
> the Maintainer system for gdb?
We do, it's the obvious bugfix rule, but it's hard to say what is
obvious to everyone.
I don't feel comfortable making that call right now, I'm pretty tired of
taking the backlash from the people who think it isn't obvious/needed
approval which invariably happens.

As I said, isn't the only patch i've got outstanding, and most of them are
trivial
fixes/improvements, because I've not yet submitted some large improvements
made to memory usage/demangling speed/symbol lookup speed for C++/every
language except C/infrastructure improvements for C++/dwarf2 improvements.
Among other improvements. Normally, I would just keep pinging Jim until I
get a response, but to be honest, all the politicking and crap that
has happened with regards to the steering committee, etc, has
kinda demotivated me, and it's hard to motivate myself to contribute to
gdb outside of work, either large or small improvements.
I'm sure it'll pass in a month or so.
 >
> This sort of thing makes gdb look really bad.
Yeah, but it's only in gdb CVS, don't forget.
I get the feeling you guys are shipping CVS gdb's to people.
Well, it's not just a feeling, I have a powerbook with OS X 4F8 (acquired
through a lot of pain and trouble) on it, and
I just looked, and it's  GDB 20000912, a CVS version.

Which explains why you keep mentioning users, when the bug only exists in
CVS.
This is a very bad idea to be doing.
However, if you like, I'll happily make sure C++ nicely, if I didn't have
to go through a ton of  pain to get new builds so I could check it out (IE
I was seeded the same as the other developers who got 4F8 and friends the
normal way)
I know it's in Darwin CVS, but I can't make that compile without the right
versions of OS X anyway.

--Dan