On Tuesday 12 August 2008 16:39:45 Daniel Jacobowitz wrote:
> On Tue, Aug 12, 2008 at 04:36:40PM +0200, André Pönitz wrote:
> > (gdb) p _Z3fooIiET_v
> > $1 = {int (void)} 0x400544 <int foo<int>()>
> >
> > (gdb) call _Z3fooIiET_v()
> > /build/buildd/gdb-6.8/gdb/valops.c:2069: internal-error: find_oload_champ_namespace_loop:
> > Assertion `new_oload_champ != -1' failed.
> > A problem internal to GDB has been detected,
>
> I've seen this error recently, with pointers to members. I don't
> think my patches will fix this particular case (the OP_VAR_VALUE
> rather than STRUCTOP_MPTR case).
>
> > I already use the mangled name of the symbol as I did not find a way to
> > quote 'call foo<int>()' in a way that looks acceptable to gdb.
>
> It's because of the templated return type. The quoting that works
> today is (gross, I know):
>
> p 'int foo<int>'()
>
> But it doesn't help, there's the same error.
I noticed in the mean time that
set demangle-style none
helps to prevent the crash. Together with your hint this might
already be 'some kind of "solution"' ;-)
> > Is there a way to make the gdb core accept the mangled name without
> > attempting to demangling it (to avoid the crash)?
>
> The crash has nothing to do with demangling, but you can disable
> overload resolution and that should help. "set overload-resolution
> off".
Is there somewhere a description in what code paths setting variables
like overload-resolution or demangle-style has an effect?
> Or just fix the bug :-)
;-} That's certainly the best solution for the long run. In the short term
I have to live with debuggers that are already released....
André