[Bug backtrace/31122] gdb crashed when drkonqi ran it on plasmashell crashes

[tromey at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=31122

Tom Tromey <tromey at sourceware dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tromey at sourceware dot org

--- Comment #1 from Tom Tromey <tromey at sourceware dot org> ---
Thanks for the report.

In the first trace:

#5  0x000055dc80ae97e7 in iter_match_first_hashed (dict=0x55dca15bb2a0,
name=..., 
    iterator=0x7ffe3d29d858) at ../../gdb/dictionary.c:586

This line is:

  symbol_name_matcher_ftype *matches_name
    = lang->get_symbol_name_matcher (name);

... so maybe lang==null?  This really shouldn't happen.

I see in your post you tried to examine this -- thank you:

(gdb) p lang
$1 = <optimized out>

I guess you'd need to build a gdb without optimization.

> There were errors in reading the name variable at that line like m_demangled_name = <error: Cannot access memory at address 0xf435c9f3d929f800>

This is the payload of an un-instantiated optional<>, so it's fine that
it is an invalid pointer -- I don't think this can be the bug.

It might be good to see which block this comes from.  From the blocks
it is possible to find the function symbol (you may have to walk up
the block hierarchy a bit).  From there we could try to dig up the DWARF
and see if something weird is going on.

Speaking of weird:

#4  <signal handler called>
#5  0x0000559d5be3c93a in skip_ws (
    string1=@0x7ffed94630f8: 0x559d65f1c4f0 "ConversionCheck::supported", 
    string2=@0x7ffed94630f0: 0x7ffed94632e8 "QThread",
end_str2=end_str2@entry=0x7ffed94632ef "")
    at ../../gdb/utils.c:2049

This crash is extremely suspicious to me.  You can see from the trace
that the arguments are just ordinary, valid strings.  This function is
very simple:

  while (ISSPACE (*string1))
    string1++;
  while (string2 < end_str2 && ISSPACE (*string2))
    string2++;

... so how could this possibly be crashing?  ISSPACE is a macro that
references a global static table, and that's never caused a problem...

I don't have a theory for what could be happening here.

-- 
You are receiving this mail because:
You are on the CC list for the bug.