[Bug gdb/26828] New: SIGSEGV in follow_die_offset dwarf2/read.c:22950

[Bug gdb/26828] New: SIGSEGV in follow_die_offset dwarf2/read.c:22950

[nilsgladitz at gmail dot com]

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

            Bug ID: 26828
           Summary: SIGSEGV in follow_die_offset dwarf2/read.c:22950
           Product: gdb
           Version: 10.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: gdb
          Assignee: unassigned at sourceware dot org
          Reporter: nilsgladitz at gmail dot com
  Target Milestone: ---

I am running GDB 10.1 on x86_64 GNU/Linux targeting ARM.

While debugging a core file with "-i=mi" and repeatedly running e.g.
"-stack-list-variables --thread 1 --frame 0 --simple-values" results in a
segmentation fault.

The first call returns "frame" and "variables" information.
The second call returns just the "variables".
The third call segfaults in "follow_die_offset" (dwarf2/read.c:22950).

The segfaulting line reads:
   target_cu->ancestor = cu;

target_cu is apparently 0.

I can reproduce the issue with current master
(e1f57067b162cba9f39e087726c7a2f2cfaae96f) too.

With GDB 9.1 the third (and subsequent) calls don't seem to segfault.

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

[Bug gdb/26828] SIGSEGV in follow_die_offset dwarf2/read.c:22950

[simark at simark dot ca]

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

Simon Marchi <simark at simark dot ca> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |simark at simark dot ca

--- Comment #1 from Simon Marchi <simark at simark dot ca> ---
Hi Nils,

Can you provide some files to reproduce the issue?  Otherwise it's not really
possible to look into it.

Simon

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

[Bug gdb/26828] SIGSEGV in follow_die_offset dwarf2/read.c:22950

[nilsgladitz at gmail dot com]

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

--- Comment #2 from Nils Gladitz <nilsgladitz at gmail dot com> ---
Hello Simon,

thank you for looking into this.

"git bisect" tells me the issue might exist since:
  17ee85fc2af74471e8c57502714a32bbeac5f1ae
  "Share DWARF partial symtabs"

I don't have any reasonably shareable files yet.

I'll try to construct / reduce a test case somehow but I don't know how long
that'll take or how succesfull I'll be; not even entirely sure how I'll go
about constructing one yet.

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

[Bug gdb/26828] SIGSEGV in follow_die_offset dwarf2/read.c:22950

[simark at simark dot ca]

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

--- Comment #3 from Simon Marchi <simark at simark dot ca> ---
Ok, thanks.  The problematic commit is one I worked on, so I'll take a look
once you upload a reproducer.

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

[Bug gdb/26828] SIGSEGV in follow_die_offset dwarf2/read.c:22950

[nilsgladitz at gmail dot com]

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

--- Comment #4 from Nils Gladitz <nilsgladitz at gmail dot com> ---
Created attachment 12941
  --> https://sourceware.org/bugzilla/attachment.cgi?id=12941&action=edit
reproducer

I've attached an archive with a test case that reproduces the issue for me.

It contains an executable (Foo), core-file (Foo-core), libpthread.so.0 from the
arm target system and a shell script (repo.sh) that runs arm-linux-gnueabi-gdb
with a sequence of commands that reproduces the crash on my system(s).

I had to increase the number of queries to trigger the segmentation fault but
am hoping the test case is still deterministic and does not depend on anything
else specific to my system.

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

[Bug gdb/26828] SIGSEGV in follow_die_offset dwarf2/read.c:22950

[simark at simark dot ca]

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

--- Comment #5 from Simon Marchi <simark at simark dot ca> ---
Whatever I do, I can't get a backtrace using your core.  I always get a
variation of:

(gdb) bt
#0  0xb6c3809c in pthread_mutex_trylock () from /lib/libpthread.so.0
Backtrace stopped: Cannot access memory at address 0x120


I'm guessing that in your development sysroot, you have debug info for
/lib/libpthread.so.0, and that makes GDB able to unwind the frames in that
library.  It's probably a separate debug file.  Can you check, and if so,
provide it?

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

[Bug gdb/26828] SIGSEGV in follow_die_offset dwarf2/read.c:22950

[simark at simark dot ca]

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

--- Comment #6 from Simon Marchi <simark at simark dot ca> ---
Actually, I made some progress.  The solib-search-path isn't sufficient, I
think GDB opens /lib/libpthread.so.0 on my system.  It would be more
appropriate to use "set sysroot" in this situation.  When setting the sysroot,
to the base of what you provided, then the correct /lib/libpthread.so.0 is
loaded by GDB.

Another note for those trying to reproduce: if you have a --enable-targets=all
GDB, it will (erroneously) detect the core as having the Symbian osabi and then
tell you that it doesn't know how to handle cores.  Use "set osabi GNU/Linux"
to force it to use that osabi.

So now the status is that I do get a crash, but I think it's not the same as
you, I think it's earlier.  I build with --enable-ubsan, and that looks like an
undefined behabior sanitizer message

$ ../gdb -nx --data-directory=../data-directory                                 
(gdb) set osabi GNU/Linux 
(gdb) set sysroot /home/simark/build/binutils-gdb/gdb/repo
(gdb) file Foo
Reading symbols from Foo...
(gdb) core-file Foo-core 
warning: Can't open file /media/mmcblk0p1/install/usr/bin/Foo during
file-backed mapping note processing
warning: Can't open file /lib/libm-2.21.so during file-backed mapping note
processing
warning: Can't open file /lib/libpthread-2.21.so during file-backed mapping
note processing
warning: Can't open file /lib/libgcc_s.so.1 during file-backed mapping note
processing
warning: Can't open file /media/mmcblk0p1/install/usr/lib/libstdc++.so.6 during
file-backed mapping note processing
warning: Can't open file /lib/libc-2.21.so during file-backed mapping note
processing
warning: Can't open file /lib/ld-2.21.so during file-backed mapping note
processing
[New LWP 29367]
[New LWP 29368]
warning: Could not load shared library symbols for 5 libraries, e.g.
/lib/libc.so.6.
Use the "info sharedlibrary" command to see the complete listing.
Do you need "set solib-search-path" or "set sysroot"?
warning: Unable to find libthread_db matching inferior's thread library, thread
debugging will not be available.
warning: Unable to find libthread_db matching inferior's thread library, thread
debugging will not be available.
Core was generated by `./Foo'.
Program terminated with signal SIGABRT, Aborted.
#0  0xb6c3809c in pthread_cond_wait () from
/home/simark/build/binutils-gdb/gdb/repo/lib/libpthread.so.0
[Current thread is 1 (LWP 29367)]
(gdb) bt
/home/simark/src/binutils-gdb/gdb/arm-tdep.c:1551:30: runtime error: shift
exponent 32 is too large for 32-bit type 'unsigned int'

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

[Bug gdb/26828] SIGSEGV in follow_die_offset dwarf2/read.c:22950

[simark at simark dot ca]

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

Simon Marchi <simark at simark dot ca> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2020-11-03
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW

--- Comment #7 from Simon Marchi <simark at simark dot ca> ---
I fixed the undefined shift behavior problem, and was able to reproduce your
problem.  This is the command line you provided that I adapted:

../gdb -nx --data-directory=../data-directory -i mi Foo <<EOF
set sysroot /home/simark/build/binutils-gdb/gdb/repo
set osabi GNU/Linux
core-file Foo-core
-stack-list-variables --thread 2 --frame 2 --simple-values
-stack-list-variables --thread 2 --frame 2 --simple-values
-stack-list-variables --thread 2 --frame 2 --simple-values
-stack-list-variables --thread 2 --frame 2 --simple-values
-stack-list-variables --thread 2 --frame 2 --simple-values
-stack-list-variables --thread 2 --frame 2 --simple-values
EOF


This is what I get:

$ ./repo.sh
warning: Found custom handler for signal 7 (Bus error) preinstalled.
warning: Found custom handler for signal 8 (Floating point exception)
preinstalled.
warning: Found custom handler for signal 11 (Segmentation fault) preinstalled.
Some signal dispositions inherited from the environment (SIG_DFL/SIG_IGN)
won't be propagated to spawned programs.
=thread-group-added,id="i1"
~"GNU gdb (GDB) 11.0.50.20201103-git\n"
~"Copyright (C) 2020 Free Software Foundation, Inc.\n"
~"License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>\nThis is free software: you are free to
change and redistribute it.\nThere is NO WARRANTY, to the extent permitted by
law."
~"\nType \"show copying\" and \"show warranty\" for details.\n"
~"This GDB was configured as \"x86_64-pc-linux-gnu\".\n"
~"Type \"show configuration\" for configuration details.\n"
~"For bug reporting instructions, please see:\n"
~"<https://www.gnu.org/software/gdb/bugs/>.\n"
~"Find the GDB manual and other documentation resources online at:\n   
<http://www.gnu.org/software/gdb/documentation/>."
~"\n\n"
~"For help, type \"help\".\n"
~"Type \"apropos word\" to search for commands related to \"word\"...\n"
~"Reading symbols from Foo...\n"
(gdb) 
&"set sysroot /home/simark/build/binutils-gdb/gdb/repo\n"
=cmd-param-changed,param="sysroot",value="/home/simark/build/binutils-gdb/gdb/repo"
^done
(gdb) 
&"set osabi GNU/Linux\n"
=cmd-param-changed,param="osabi",value="GNU/Linux"
^done
(gdb) 
&"core-file Foo-core\n"
&"warning: Can't open file /media/mmcblk0p1/install/usr/bin/Foo during
file-backed mapping note processing\n"
&"warning: Can't open file /lib/libm-2.21.so during file-backed mapping note
processing\n"
&"warning: Can't open file /lib/libpthread-2.21.so during file-backed mapping
note processing\n"
&"warning: Can't open file /lib/libgcc_s.so.1 during file-backed mapping note
processing\n"
&"warning: Can't open file /media/mmcblk0p1/install/usr/lib/libstdc++.so.6
during file-backed mapping note processing\n"
&"warning: Can't open file /lib/libc-2.21.so during file-backed mapping note
processing\n"
&"warning: Can't open file /lib/ld-2.21.so during file-backed mapping note
processing\n"
=thread-group-started,id="i1",pid="29367"
=thread-created,id="1",group-id="i1"
~"[New LWP 29367]\n"
=thread-created,id="2",group-id="i1"
~"[New LWP 29368]\n"
=library-loaded,id="/lib/libc.so.6",target-name="/lib/libc.so.6",host-name="/lib/libc.so.6",symbols-loaded="0",thread-group="i1",ranges=[{}]
=library-loaded,id="/media/mmcblk0p1/install/usr/bin/../lib/libstdc++.so.6",target-name="/media/mmcblk0p1/install/usr/bin/../lib/libstdc++.so.6",host-name="/media/mmcblk0p1/install/usr/bin/../lib/libstdc++.so.6",symbols-loaded="0",thread-group="i1",ranges=[{}]
=library-loaded,id="/lib/libgcc_s.so.1",target-name="/lib/libgcc_s.so.1",host-name="/lib/libgcc_s.so.1",symbols-loaded="0",thread-group="i1",ranges=[{}]
=library-loaded,id="/lib/libpthread.so.0",target-name="/lib/libpthread.so.0",host-name="/home/simark/build/binutils-gdb/gdb/repo/lib/libpthread.so.0",symbols-loaded="0",thread-group="i1",ranges=[{from="0xb6c30160",to="0xb6c3ec88"}]
=library-loaded,id="/lib/ld-linux.so.3",target-name="/lib/ld-linux.so.3",host-name="/lib/ld-linux.so.3",symbols-loaded="0",thread-group="i1",ranges=[{}]
=library-loaded,id="/lib/libm.so.6",target-name="/lib/libm.so.6",host-name="/lib/libm.so.6",symbols-loaded="0",thread-group="i1",ranges=[{}]
&"warning: Could not load shared library symbols for 5 libraries, e.g.
/lib/libc.so.6.\nUse the \"info sharedlibrary\" command to see the complete
listing.\nDo you need \"set solib-search-path\" or \"set sysroot\"?"
&"\n"
&"warning: Unable to find libthread_db matching inferior's thread library,
thread debugging will not be available.\n"
&"warning: Unable to find libthread_db matching inferior's thread library,
thread debugging will not be available.\n"
~"Core was generated by `./Foo'.\n"
~"Program terminated with signal SIGABRT, Aborted.\n"
~"#0  0xb6c3809c in pthread_cond_wait () from
/home/simark/build/binutils-gdb/gdb/repo/lib/libpthread.so.0\n"
~"[Current thread is 1 (LWP 29367)]\n"
^done
(gdb) 
^done,variables=[{name="lock",arg="1",type="boost::asio::detail::conditionally_enabled_mutex::scoped_lock
&",value="<synthetic pointer>: {<boost::asio::detail::noncopyable> = {<No data
fields>}, mutex_ = @0x2cf50, locked_ =
true}"},{name="this",arg="1",type="boost::asio::detail::conditionally_enabled_event
* const",value="0x2cf70"}]
(gdb) 
^done,variables=[{name="lock",arg="1",type="boost::asio::detail::conditionally_enabled_mutex::scoped_lock
&",value="<synthetic pointer>: {<boost::asio::detail::noncopyable> = {<No data
fields>}, mutex_ = @0x2cf50, locked_ =
true}"},{name="this",arg="1",type="boost::asio::detail::conditionally_enabled_event
* const",value="0x2cf70"}]
(gdb) 
^done,variables=[{name="lock",arg="1",type="boost::asio::detail::conditionally_enabled_mutex::scoped_lock
&",value="<synthetic pointer>: {<boost::asio::detail::noncopyable> = {<No data
fields>}, mutex_ = @0x2cf50, locked_ =
true}"},{name="this",arg="1",type="boost::asio::detail::conditionally_enabled_event
* const",value="0x2cf70"}]
(gdb) 
^done,variables=[{name="lock",arg="1",type="boost::asio::detail::conditionally_enabled_mutex::scoped_lock
&",value="<synthetic pointer>: {<boost::asio::detail::noncopyable> = {<No data
fields>}, mutex_ = @0x2cf50, locked_ =
true}"},{name="this",arg="1",type="boost::asio::detail::conditionally_enabled_event
* const",value="0x2cf70"}]
(gdb) 
^done,variables=[{name="lock",arg="1",type="boost::asio::detail::conditionally_enabled_mutex::scoped_lock
&",value="<synthetic pointer>: {<boost::asio::detail::noncopyable> = {<No data
fields>}, mutex_ = @0x2cf50, locked_ =
true}"},{name="this",arg="1",type="boost::asio::detail::conditionally_enabled_event
* const",value="0x2cf70"}]
(gdb) 
/home/simark/src/binutils-gdb/gdb/dwarf2/read.c:22959:25: runtime error: member
access within null pointer of type 'struct dwarf2_cu'

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

[Bug gdb/26828] SIGSEGV in follow_die_offset dwarf2/read.c:22950

[nilsgladitz at gmail dot com]

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

--- Comment #8 from Nils Gladitz <nilsgladitz at gmail dot com> ---
Thank you for putting in the extra work in getting this to reproduce.
Quite relieved that it isn't only reproducible on my system.

libpthread.so.0 is located elsewhere on my system which is why I presumably
didn't trip there.

Also didn't know about "--enable-targets=all" yet!

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

[Bug gdb/26828] SIGSEGV in follow_die_offset dwarf2/read.c:22950

[simark at simark dot ca]

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

--- Comment #9 from Simon Marchi <simark at simark dot ca> ---
Nils, could you try the following patch?

The issue lies with the fact that we have a DIE in a CU A referring to a DIE in
a CU B (using DW_AT_abstract_origin).  The DIEs for CU B are not loaded yet (or
rather, have been unloaded due to DWARF CU aging stuff), and we try to load
them using:

      /* If necessary, add it to the queue and load its DIEs.  */
      if (maybe_queue_comp_unit (cu, per_cu, per_objfile, cu->language))
        load_full_comp_unit (per_cu, per_objfile, per_objfile->get_cu (per_cu),
                             false, cu->language);

Since the CU is already queued for expansion, maybe_queue_comp_unit returns
false and we don't call load_full_comp_unit.  I think maybe_queue_comp_unit is
the wrong thing to call here, because "queuing for symtab expansion" is
unrelated to "loading the DIEs in memory".  We should rather check: "are the
DIEs for per_cu loaded into memory yet?  if not do it now", which is what the
patch below implements.


@@ -22937,12 +22939,15 @@ follow_die_offset (sect_offset sect_off, int
offset_in_dwz,
       per_cu = dwarf2_find_containing_comp_unit (sect_off, offset_in_dwz,
                                                 per_objfile);

-      /* If necessary, add it to the queue and load its DIEs.  */
-      if (maybe_queue_comp_unit (cu, per_cu, per_objfile, cu->language))
-       load_full_comp_unit (per_cu, per_objfile, per_objfile->get_cu (per_cu),
-                            false, cu->language);
-
       target_cu = per_objfile->get_cu (per_cu);
+      if (target_cu == nullptr)
+       {
+         load_full_comp_unit (per_cu, per_objfile, per_objfile->get_cu
(per_cu),
+                              false, cu->language);
+         target_cu = per_objfile->get_cu (per_cu);
+       }
+
+      gdb_assert (target_cu != nullptr);
     }
   else if (cu->dies == NULL)
     {

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

[Bug gdb/26828] SIGSEGV in follow_die_offset dwarf2/read.c:22950

[nilsgladitz at gmail dot com]

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

--- Comment #10 from Nils Gladitz <nilsgladitz at gmail dot com> ---
While the attached test case now seems to pass my original case now fails with:

../../../../binutils-gdb/gdb/dwarf2/read.c:9251: internal-error: void
load_full_comp_unit(dwarf2_per_cu_data*, dwarf2_per_objfile*, dwarf2_cu*, bool,
language): Assertion `cu->die_hash == NULL' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.

Not sure if that means this is a related or an independent issue.

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

[Bug gdb/26828] SIGSEGV in follow_die_offset dwarf2/read.c:22950

[simark at simark dot ca]

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

--- Comment #11 from Simon Marchi <simark at simark dot ca> ---
(In reply to Nils Gladitz from comment #10)
> While the attached test case now seems to pass my original case now fails
> with:
> 
> ../../../../binutils-gdb/gdb/dwarf2/read.c:9251: internal-error: void
> load_full_comp_unit(dwarf2_per_cu_data*, dwarf2_per_objfile*, dwarf2_cu*,
> bool, language): Assertion `cu->die_hash == NULL' failed.
> A problem internal to GDB has been detected,
> further debugging may prove unreliable.
> 
> Not sure if that means this is a related or an independent issue.

It's possibly related.  Is that load_full_comp_unit call the one I touched in
the patch, or is it a later one?  Could you provide the backtrace of this new
assertion failure?

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

[Bug gdb/26828] SIGSEGV in follow_die_offset dwarf2/read.c:22950

[nilsgladitz at gmail dot com]

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

--- Comment #12 from Nils Gladitz <nilsgladitz at gmail dot com> ---
Looks like it comes from a different call:

#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x00007fc878bb0859 in __GI_abort () at abort.c:79
#2  0x000056229e1f0e76 in dump_core () at
../../../../binutils-gdb/gdb/utils.c:204
#3  0x000056229e1f1799 in internal_vproblem(internal_problem *, const char *,
int, const char *, typedef __va_list_tag __va_list_tag *)
(problem=0x56229f7c09e0 <internal_error_problem>, 
    file=0x56229e7cb208 "../../../../binutils-gdb/gdb/dwarf2/read.c",
line=9251, 
    fmt=0x56229e7ca848 "%s: Assertion `%s' failed.", ap=0x7ffc18d82410)
    at ../../../../binutils-gdb/gdb/utils.c:414
#4  0x000056229e1f1890 in internal_verror (
    file=0x56229e7cb208 "../../../../binutils-gdb/gdb/dwarf2/read.c",
line=9251, 
    fmt=0x56229e7ca848 "%s: Assertion `%s' failed.", ap=0x7ffc18d82410)
    at ../../../../binutils-gdb/gdb/utils.c:439
#5  0x000056229e685fda in internal_error (
    file=0x56229e7cb208 "../../../../binutils-gdb/gdb/dwarf2/read.c",
line=9251, 
    fmt=0x56229e7ca848 "%s: Assertion `%s' failed.") at
../../../../binutils-gdb/gdbsupport/errors.cc:55
#6  0x000056229d7c1103 in load_full_comp_unit (this_cu=0x5622a1d2f220,
per_objfile=0x5622a1351a10, 
    existing_cu=0x5622b648d2f0, skip_partial=false,
pretend_language=language_minimal)
    at ../../../../binutils-gdb/gdb/dwarf2/read.c:9251
#7  0x000056229d783f35 in load_cu (per_cu=0x5622a1d2f220,
per_objfile=0x5622a1351a10, 
    skip_partial=false) at ../../../../binutils-gdb/gdb/dwarf2/read.c:2389
#8  0x000056229d7840ad in dw2_do_instantiate_symtab (per_cu=0x5622a1d2f220,
per_objfile=0x5622a1351a10, 
    skip_partial=false) at ../../../../binutils-gdb/gdb/dwarf2/read.c:2420
#9  0x000056229d7c0926 in dwarf2_psymtab::expand_psymtab (this=0x5622a293efa0,
objfile=0x5622a1d5f4b0)
    at ../../../../binutils-gdb/gdb/dwarf2/read.c:9183
#10 0x000056229d7bf853 in dwarf2_psymtab::read_symtab (this=0x5622a293efa0,
objfile=0x5622a1d5f4b0)
    at ../../../../binutils-gdb/gdb/dwarf2/read.c:9031


in load_cu:
 else
    load_full_comp_unit (per_cu, per_objfile, per_objfile->get_cu (per_cu),
             skip_partial, language_minimal);

  dwarf2_cu *cu = per_objfile->get_cu (per_cu);
  if (cu == nullptr)
    return nullptr;  /* Dummy CU.  */

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

[Bug gdb/26828] SIGSEGV in follow_die_offset dwarf2/read.c:22950

[simark at simark dot ca]

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

--- Comment #13 from Simon Marchi <simark at simark dot ca> ---
Yeah it looks like this is a consequence of my change.  load_cu doesn't like
that the CU was already loaded in memory.  The obvious fix would be to make it
skip the load if it already is loaded, see patch below.

Although to be sure of what happens, I would need to be able to debug it
myself, if you have a change to make a reproducer for this.


diff --git a/gdb/dwarf2/read.c b/gdb/dwarf2/read.c
index 7d258f30eba7..150f54335433 100644
--- a/gdb/dwarf2/read.c
+++ b/gdb/dwarf2/read.c
@@ -2383,13 +2383,19 @@ static dwarf2_cu *
 load_cu (dwarf2_per_cu_data *per_cu, dwarf2_per_objfile *per_objfile,
         bool skip_partial)
 {
-  if (per_cu->is_debug_types)
-    load_full_type_unit (per_cu, per_objfile);
-  else
-    load_full_comp_unit (per_cu, per_objfile, per_objfile->get_cu (per_cu),
-                        skip_partial, language_minimal);
-
   dwarf2_cu *cu = per_objfile->get_cu (per_cu);
+
+  if (cu == nullptr)
+    {
+      if (per_cu->is_debug_types)
+       load_full_type_unit (per_cu, per_objfile);
+      else
+       load_full_comp_unit (per_cu, per_objfile, per_objfile->get_cu (per_cu),
+                            skip_partial, language_minimal);
+
+      cu = per_objfile->get_cu (per_cu);
+    }
+
   if (cu == nullptr)
     return nullptr;  /* Dummy CU.  */

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

[Bug gdb/26828] SIGSEGV in follow_die_offset dwarf2/read.c:22950

[nilsgladitz at gmail dot com]

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

--- Comment #14 from Nils Gladitz <nilsgladitz at gmail dot com> ---
Thanks, this does seem to fix the issue for me now!

Is this sufficient feedback or do you still want a new reproducer for this?

Creating the first one was quite time consuming (chiseling down a somewhat
large project and continuously deploying to ARM) and I think I might have
gotten somewhat lucky too. Unsure how much it'll take to create a new
reproducer given that I don't understand how my core dumps are specifically
triggering the first or the second issue or why this doesn't come up as an
issue elsewhere (none of this CU loading / unloading stuff sounds like it would
be ARM specific or in any sense rare?).

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

[Bug gdb/26828] SIGSEGV in follow_die_offset dwarf2/read.c:22950

[simark at simark dot ca]

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

--- Comment #15 from Simon Marchi <simark at simark dot ca> ---
A reproducer is always preferable, because I wouldn't be comfortable committing
a fix that I don't understand precisely and can't explain, but I understand if
you don't have time.

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

[Bug gdb/26828] SIGSEGV in follow_die_offset dwarf2/read.c:22950

[nilsgladitz at gmail dot com]

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

--- Comment #16 from Nils Gladitz <nilsgladitz at gmail dot com> ---
Created attachment 12947
  --> https://sourceware.org/bugzilla/attachment.cgi?id=12947&action=edit
second reproducer

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

[Bug gdb/26828] SIGSEGV in follow_die_offset dwarf2/read.c:22950

[nilsgladitz at gmail dot com]

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

--- Comment #17 from Nils Gladitz <nilsgladitz at gmail dot com> ---
I've attached a second test case that reproduces both issues for me (i.e. does
not pass with just the first patch applied).

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

[Bug gdb/26828] SIGSEGV in follow_die_offset dwarf2/read.c:22950

[simark at simark dot ca]

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

--- Comment #18 from Simon Marchi <simark at simark dot ca> ---
Awesome, thanks.  I'll take a look when I have a bit of free time.

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

[Bug gdb/26828] SIGSEGV in follow_die_offset dwarf2/read.c:22950

[simark at simark dot ca]

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

--- Comment #19 from Simon Marchi <simark at simark dot ca> ---
Ok, I think I was able to reproduce:

~"/home/simark/src/binutils-gdb/gdb/dwarf2/read.c:9255: internal-error: void
load_full_comp_unit(dwarf2_per_cu_data*, dwarf2_per_objfile*, dwarf2_cu*, bool,
language): Assertion `cu->die_hash == 
NULL' failed.\nA problem internal to GDB has been detected,\nfurther debugging
may prove unreliable."
~"\nQuit this debugging session? "
~"(y or n) [answered Y; input not from terminal]\n"
&"\nThis is a bug, please report it."
&"  For instructions, see:\n"
&"<https://www.gnu.org/software/gdb/bugs/>.\n\n" 
~"/home/simark/src/binutils-gdb/gdb/dwarf2/read.c:9255: internal-error: void
load_full_comp_unit(dwarf2_per_cu_data*, dwarf2_per_objfile*, dwarf2_cu*, bool,
language): Assertion `cu->die_hash == 
NULL' failed.\nA problem internal to GDB has been detected,\nfurther debugging
may prove unreliable."
~"\nCreate a core file of GDB? "
~"(y or n) [answered Y; input not from terminal]\n"

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

[Bug gdb/26828] SIGSEGV in follow_die_offset dwarf2/read.c:22950

[cvs-commit at gcc dot gnu.org]

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

--- Comment #20 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Simon Marchi <simark@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=9ecab40c77fd414fe408967d0f92f00494aa11b9

commit 9ecab40c77fd414fe408967d0f92f00494aa11b9
Author: Simon Marchi <simon.marchi@polymtl.ca>
Date:   Fri Nov 13 11:58:37 2020 -0500

    gdb/arm: avoid undefined behavior shift when decoding immediate value

    When loading the code file provided in PR 26828 and GDB is build with
    UBSan, we get:

        Core was generated by `./Foo'.
        Program terminated with signal SIGABRT, Aborted.
        #0  0xb6c3809c in pthread_cond_wait () from
/home/simark/build/binutils-gdb/gdb/repo/lib/libpthread.so.0
        [Current thread is 1 (LWP 29367)]
        (gdb) bt
        /home/simark/src/binutils-gdb/gdb/arm-tdep.c:1551:30: runtime error:
shift exponent 32 is too large for 32-bit type 'unsigned int'

    The sequence of instructions at pthread_cond_wait, in the
    libpthread.so.0 library, contains this instruction with an immediate
    constant with a "rotate amount" of 0:

        e24dd044        sub     sp, sp, #68     ; 0x44

    Since arm_analyze_prologue shifts by "32 - rotate amount", it does a 32
    bit shift of a 32 bit type, which is caught by UBSan.

    Fix it by factoring out the decoding of immediates in a new function,
    arm_expand_immediate.

    I added a selftest for arm_analyze_prologue that replicates the
    instruction sequence.  Without the fix, it crashes GDB if it is build
    with --enable-ubsan.

    I initially wanted to re-use the abstract_memory_reader class already in
    arm-tdep.c, used to make arm_process_record testable.  However,
    arm_process_record and arm_analyze_prologue don't use the same kind of
    memory reading functions.  arm_process_record uses a function that
    returns an error status on failure while arm_analyze_prologue uses one
    that throws an exception.  Since i didn't want to introduce any other
    behavior change, I decided to just introduce a separate interface
    (arm_instruction_reader).  It is derived from
    abstract_instruction_reader in aarch64-tdep.c.

    gdb/ChangeLog:

            PR gdb/26835
            * arm-tdep.c (class arm_instruction_reader): New.
            (target_arm_instruction_reader): New.
            (arm_analyze_prologue): Add instruction reader parameter and use
            it.  Use arm_expand_immediate.
            (class target_arm_instruction_reader): Adjust.
            (arm_skip_prologue): Adjust.
            (arm_expand_immediate): New.
            (arm_scan_prologue): Adjust.
            (arm_analyze_prologue_test): New.
            (class test_arm_instruction_reader): New.

    Change-Id: Ieb1c1799bd66f8c7421384f44f5c2777b578ff8d

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

[Bug gdb/26828] SIGSEGV in follow_die_offset dwarf2/read.c:22950

[simark at simark dot ca]

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

--- Comment #21 from Simon Marchi <simark at simark dot ca> ---
Created attachment 12955
  --> https://sourceware.org/bugzilla/attachment.cgi?id=12955&action=edit
Proposed patch series

Hi Nils,

Can you try this patch series see if it's good on your side?  On my side, the
second reproducer you sent works correctly, and I see no regression in GDB's
testsuite.  The previous patchlets that I asked you to try were not correct, as
they broke other things.

I am based on commit 9ecab40c77fd414fe408967d0f92f00494aa11b9.  The
series.patch file contains all 4 patches, you can apply them with

  $ git am series.patch

The series breaks some things in the middle only to fix them in the last patch,
so in the end I will probably re-order them, but the end result will be the
same.

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

[Bug gdb/26828] SIGSEGV in follow_die_offset dwarf2/read.c:22950

[nilsgladitz at gmail dot com]

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

--- Comment #22 from Nils Gladitz <nilsgladitz at gmail dot com> ---
Works for me, thanks!

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

[Bug gdb/26828] SIGSEGV in follow_die_offset dwarf2/read.c:22950

[simark at simark dot ca]

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

Simon Marchi <simark at simark dot ca> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |10.2

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

[Bug gdb/26828] SIGSEGV in follow_die_offset dwarf2/read.c:22950

[simark at simark dot ca]

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

--- Comment #23 from Simon Marchi <simark at simark dot ca> ---
Series posted here:
https://sourceware.org/pipermail/gdb-patches/2020-November/173372.html

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

[Bug gdb/26828] SIGSEGV in follow_die_offset dwarf2/read.c:22950

[cvs-commit at gcc dot gnu.org]

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

--- Comment #24 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Simon Marchi <simark@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=de53369b2efcae78adf431437cb096c5a0728f96

commit de53369b2efcae78adf431437cb096c5a0728f96
Author: Simon Marchi <simon.marchi@polymtl.ca>
Date:   Wed Jan 20 21:04:43 2021 -0500

    gdb/dwarf: add assertion in maybe_queue_comp_unit

    The symptom that leads to this is the crash described in PR 26828:

    /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:23478:25: runtime error:
member access within null pointer of type 'struct dwarf2_cu'

    The line of the crash is the following, in follow_die_offset:

      if (target_cu != cu)
        target_cu->ancestor = cu;  <--- HERE

    The line that assign nullptr to `target_cu` is the `per_objfile->get_cu`
    call after having called maybe_queue_comp_unit:

          /* If necessary, add it to the queue and load its DIEs.  */
          if (maybe_queue_comp_unit (cu, per_cu, per_objfile, cu->language))
            load_full_comp_unit (per_cu, per_objfile, per_objfile->get_cu
(per_cu),
                                 false, cu->language);

          target_cu = per_objfile->get_cu (per_cu);  <--- HERE

    Some background: there is an invariant, documented in
    maybe_queue_comp_unit's doc, that if a CU is queued for expansion
    (present in dwarf2_per_bfd::queue), then its DIEs are loaded in memory.
    "its DIEs are loaded in memory" is a synonym for saying that a dwarf2_cu
    object exists for this CU.  Yet another way to say it is that
    `per_objfile->get_cu (per_cu)` returns something not nullptr for that
    CU.

    The crash documented in PR 26828 triggers some hard-to-reproduce
    sequence that ends up violating the invariant:

    - dwarf2_fetch_die_type_sect_off gets called for a DIE in CU A
    - The DIE in CU A requires some DIE in CU B
    - follow_die_offset calls maybe_queue_comp_unit.  maybe_queue_comp_unit
      sees CU B is not queued and its DIEs are not loaded, so it enqueues it
      and returns 1 to its caller - meaning "the DIEs are not loaded, you
      should load them" - prompting follow_die_offset to load the DIEs by
      calling load_full_comp_unit
    - Note that CU B is enqueued by maybe_queue_comp_unit even if it has
      already been expanded.  It's a bit useless (and causes trouble, see
      next patch), but that's how it works right now.
    - Since we entered the dwarf2/read code through
      dwarf2_fetch_die_type_sect_off, nothing processes the queue, so we
      exit the dwarf2/read code with CU B still lingering in the queue.

    - dwarf2_fetch_die_type_sect_off gets called for a DIE in CU A, again
    - The DIE in CU A requires some DIE in CU B, again
    - This time, maybe_queue_comp_unit sees that CU B is in the queue.
      Because of the invariant that if a CU is in the queue, its DIEs are
      loaded in the memory, it returns 0 to its caller, meaning "you don't
      need to load the DIEs!".
    - That happens to be true, so everything is fine for now.

    - Time passes, some things call dwarf2_per_objfile::age_comp_units
      enough so that CU B's age becomes past the dwarf_max_cache_age
      threshold.  age_comp_units proceeds to free CU B's DIEs.  Remember
      that CU B is still lingering in the queue (oops, the invariant just
      got violated).

    - dwarf2_fetch_die_type_sect_off gets called for a DIE in CU A, again
    - The DIE in CU A requires some DIE in CU B, again
    - maybe_queue_comp_unit sees that CU B is in the queue, so returns to
      its caller "you don't need to load the DIEs!".  However, we know at
      this point this is false.
    - follow_die_offset doesn't load the DIEs and tries to obtain the DIEs for
      CU B:

        target_cu = per_objfile->get_cu (per_cu);

      But since they are not loaded, target_cu is nullptr, and we get the
      crash mentioned above a few lines after that.

    This patch adds an assertions in maybe_queue_comp_unit to verify the
    invariant, to make sure it doesn't return a falsehood to its caller.

    The current patch doesn't fix the issue (the next patch does), but it
    makes it so we catch the problem earlier and get this assertion failure
    instead of a segmentation fault:

        /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:9100: internal-error:
            int maybe_queue_comp_unit(dwarf2_cu*, dwarf2_per_cu_data*,
dwarf2_per_objfile*, language):
            Assertion `per_objfile->get_cu (per_cu) != nullptr' failed.

    gdb/ChangeLog:

            PR gdb/26828
            * dwarf2/read.c (maybe_queue_comp_unit): Add assertion.

    Change-Id: I4e51bd7bd58773f9fadf480179cbc4bae61508fe

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

[Bug gdb/26828] SIGSEGV in follow_die_offset dwarf2/read.c:22950

[ReD at idp dot it]

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

Davide Repetto <ReD at idp dot it> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ReD at idp dot it

--- Comment #25 from Davide Repetto <ReD at idp dot it> ---
I have a pair of new core dumps, should they be useful:

gdb coredump:
https://www.dropbox.com/s/95p12ot0c0ya0l2/core.gdb.1000.32f860ba566941c786efd4ac4c070fb2.4549.1613756314000000.zst?dl=0

gnote coredump:
https://www.dropbox.com/s/7a9v9x2x4bl3ksm/core.gnote.1000.0148951bf12149deab85f35229f2233e.108686.1613752706000000.zst?dl=0

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

[Bug gdb/26828] SIGSEGV in follow_die_offset dwarf2/read.c:22950

[simark at simark dot ca]

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

--- Comment #26 from Simon Marchi <simark at simark dot ca> ---
(In reply to Davide Repetto from comment #25)
> I have a pair of new core dumps, should they be useful:
> 
> gdb coredump:
> https://www.dropbox.com/s/95p12ot0c0ya0l2/core.gdb.1000.
> 32f860ba566941c786efd4ac4c070fb2.4549.1613756314000000.zst?dl=0
> 
> gnote coredump:
> https://www.dropbox.com/s/7a9v9x2x4bl3ksm/core.gnote.1000.
> 0148951bf12149deab85f35229f2233e.108686.1613752706000000.zst?dl=0

Thanks.  I think the bug will be fixed with the series I posted here (which is
pending review):

https://sourceware.org/pipermail/gdb-patches/2020-November/173372.html

Is there a chance you can test it against your use case?  If you have trouble
applying patches, I can provide a git branch containing the change.

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

[Bug gdb/26828] SIGSEGV in follow_die_offset dwarf2/read.c:22950

[cvs-commit at gcc dot gnu.org]

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

--- Comment #27 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Simon Marchi <simark@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=616c069a3f1a841e5bc63d20aec8e5b71b499f6c

commit 616c069a3f1a841e5bc63d20aec8e5b71b499f6c
Author: Simon Marchi <simon.marchi@polymtl.ca>
Date:   Tue Feb 23 12:07:10 2021 -0500

    gdb/dwarf: don't enqueue CU in maybe_queue_comp_unit if already expanded

    The previous commit log described how items could be left lingering in
    the dwarf2_per_bfd::queue and how that could cause trouble.

    This patch fixes the issue by changing maybe_queue_comp_unit so that it
    doesn't put a CU in the to-expand queue if that CU is already expanded.
    This will make it so that when dwarf2_fetch_die_type_sect_off calls
    follow_die_offset and maybe_queue_comp_unit, it won't enqueue the target
    CU, because it will see the CU is already expanded.

    This assumes that if a CU is dwarf2_fetch_die_type_sect_off's target CU,
    it will have previously been expanded.  I think it is the case, but I
    can't be 100% sure.  If that's not true, the assertions added in the
    following patch will catch it, and it means we'll have to re-think a bit
    more how things work (it wouldn't be well handled at all today anyway).

    This fixes something else in maybe_queue_comp_unit that looks wrong.
    Imagine the DIEs of a CU are loaded in memory, but that CU is not
    expanded.  In that case, maybe_queue_comp_unit will use this early
    return:

      /* If the compilation unit is already loaded, just mark it as
         used.  */
      dwarf2_cu *cu = per_objfile->get_cu (per_cu);
      if (cu != nullptr)
        {
          cu->last_used = 0;
          return 0;
        }

    ... so the CU won't be queued for expansion.  Whether the DIEs of a CU
    are loaded in memory and whether that CU is expanded are two orthogonal
    things, but that function appears to mix them.  So, move the queuing
    above that check / early return, so that if the CU's DIEs are loaded in
    memory but the CU is not expanded yet, it gets enqueued.

    I tried to improve maybe_queue_comp_unit's documentation to clarify what
    the return value means.  By clarifying this, I noticed that two callers
    (follow_die_offset and follow_die_sig_1) access the CU's DIEs after
    calling maybe_queue_comp_unit, only relying on maybe_queue_comp_unit's
    return value to tell whether DIEs need to be loaded first or not.  As
    explained in the new comment, this is problematic:
    maybe_queue_comp_unit's return value doesn't tell whether DIEs are
    currently loaded, it means whether maybe_queue_comp_unit requires the
    caller to load them.  If the CU is already expanded but the DIEs to have
    been freed, maybe_queue_comp_unit returns 0, meaning "I don't need you
    to load the DIEs".  So if these two functions (follow_die_offset and
    follow_die_sig_1) need to access the DIEs in any case, for their own
    usage, they should make sure to load them if they are not loaded
    already.  I therefore added an extra check to the condition they use,
    making it so they will always load the DIEs if they aren't already.

    From what I found, other callers don't care for the CU's DIEs, they call
    maybe_queue_comp_unit to ensure the CU gets expanded eventually, but
    don't care for it after that.

    gdb/ChangeLog:

            PR gdb/26828
            * dwarf2/read.c (maybe_queue_comp_unit): Check if CU is expanded
            to decide whether or not to enqueue it for expansion.
            (follow_die_offset, follow_die_sig_1): Ensure we load the DIEs
            after calling maybe_queue_comp_unit.

    Change-Id: Id98c6b60669f4b4b21b9be16d0518fc62bdf686a

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

[Bug gdb/26828] SIGSEGV in follow_die_offset dwarf2/read.c:22950

[cvs-commit at gcc dot gnu.org]

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

--- Comment #28 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Simon Marchi <simark@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=08ac57714cd20e528efe9b4e169f3a2778cf6e30

commit 08ac57714cd20e528efe9b4e169f3a2778cf6e30
Author: Simon Marchi <simon.marchi@polymtl.ca>
Date:   Tue Feb 23 13:37:44 2021 -0500

    gdb/dwarf: create and destroy dwarf2_per_bfd's CUs-to-expand queue

    As described in the log of patch "gdb/dwarf: add assertion in
    maybe_queue_comp_unit", it would happen that a call to
    maybe_queue_comp_unit would enqueue a CU in the to-expand queue while
    nothing up the stack was processing the queue.  This is not desirable,
    as items are then left lingering in the queue when we exit the
    dwarf2/read code.  This is an inconsistent state.

    The normal case of using the queue is when we go through
    dw2_do_instantiate_symtab and process_queue.  As depended-on CUs are
    found, they get added to the queue.  process_queue expands CUs until the
    queue is empty.

    To catch these cases where things are enqueued while nothing up the
    stack is processing the queue, change dwarf2_per_bfd::queue to be an
    optional.  The optional is instantiated in dwarf2_queue_guard, just
    before where we call process_queue.  In the dwarf2_queue_guard
    destructor, the optional gets reset.  Therefore, the queue object is
    instantiated only when something up the stack is handling it.  If
    another entry point tries to enqueue a CU for expansion, an assertion
    will fail and we know we have something to fix.

    dwarf2_queue_guard sounds like the good place for this, as it's
    currently responsible for making sure the queue gets cleared if we exit
    due to an error.

    This also allows asserting that when age_comp_units or remove_all_cus
    run, the queue is not instantiated, and gives us one more level of
    assurance that we won't free the DIEs of a CU that is in the
    CUs-to-expand queue.

    gdb/ChangeLog:

            PR gdb/26828
            * dwarf2/read.c (dwarf2_queue_guard) <dwarf2_queue_guard>:
            Instantiate queue.
            (~dwarf2_queue_guard): Clear queue.
            (queue_comp_unit): Assert that queue is
            instantiated.
            (process_queue): Adjust.
            * dwarf2/read.h (struct dwarf2_per_bfd) <queue>: Make optional.

    Change-Id: I8fe3d77845bb4ad3d309eac906acebe79d9f0a9d

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

[Bug gdb/26828] SIGSEGV in follow_die_offset dwarf2/read.c:22950

[cvs-commit at gcc dot gnu.org]

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

--- Comment #29 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
The gdb-10-branch branch has been updated by Simon Marchi
<simark@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=1c8a25b683c7ea9621b7fccf6c07630bd67f071f

commit 1c8a25b683c7ea9621b7fccf6c07630bd67f071f
Author: Simon Marchi <simon.marchi@polymtl.ca>
Date:   Tue Feb 23 12:07:10 2021 -0500

    gdb/dwarf: don't enqueue CU in maybe_queue_comp_unit if already expanded

    The previous commit log described how items could be left lingering in
    the dwarf2_per_bfd::queue and how that could cause trouble.

    This patch fixes the issue by changing maybe_queue_comp_unit so that it
    doesn't put a CU in the to-expand queue if that CU is already expanded.
    This will make it so that when dwarf2_fetch_die_type_sect_off calls
    follow_die_offset and maybe_queue_comp_unit, it won't enqueue the target
    CU, because it will see the CU is already expanded.

    This assumes that if a CU is dwarf2_fetch_die_type_sect_off's target CU,
    it will have previously been expanded.  I think it is the case, but I
    can't be 100% sure.  If that's not true, the assertions added in the
    following patch will catch it, and it means we'll have to re-think a bit
    more how things work (it wouldn't be well handled at all today anyway).

    This fixes something else in maybe_queue_comp_unit that looks wrong.
    Imagine the DIEs of a CU are loaded in memory, but that CU is not
    expanded.  In that case, maybe_queue_comp_unit will use this early
    return:

      /* If the compilation unit is already loaded, just mark it as
         used.  */
      dwarf2_cu *cu = per_objfile->get_cu (per_cu);
      if (cu != nullptr)
        {
          cu->last_used = 0;
          return 0;
        }

    ... so the CU won't be queued for expansion.  Whether the DIEs of a CU
    are loaded in memory and whether that CU is expanded are two orthogonal
    things, but that function appears to mix them.  So, move the queuing
    above that check / early return, so that if the CU's DIEs are loaded in
    memory but the CU is not expanded yet, it gets enqueued.

    I tried to improve maybe_queue_comp_unit's documentation to clarify what
    the return value means.  By clarifying this, I noticed that two callers
    (follow_die_offset and follow_die_sig_1) access the CU's DIEs after
    calling maybe_queue_comp_unit, only relying on maybe_queue_comp_unit's
    return value to tell whether DIEs need to be loaded first or not.  As
    explained in the new comment, this is problematic:
    maybe_queue_comp_unit's return value doesn't tell whether DIEs are
    currently loaded, it means whether maybe_queue_comp_unit requires the
    caller to load them.  If the CU is already expanded but the DIEs to have
    been freed, maybe_queue_comp_unit returns 0, meaning "I don't need you
    to load the DIEs".  So if these two functions (follow_die_offset and
    follow_die_sig_1) need to access the DIEs in any case, for their own
    usage, they should make sure to load them if they are not loaded
    already.  I therefore added an extra check to the condition they use,
    making it so they will always load the DIEs if they aren't already.

    From what I found, other callers don't care for the CU's DIEs, they call
    maybe_queue_comp_unit to ensure the CU gets expanded eventually, but
    don't care for it after that.

    gdb/ChangeLog:

            PR gdb/26828
            * dwarf2/read.c (maybe_queue_comp_unit): Check if CU is expanded
            to decide whether or not to enqueue it for expansion.
            (follow_die_offset, follow_die_sig_1): Ensure we load the DIEs
            after calling maybe_queue_comp_unit.

    Change-Id: Id98c6b60669f4b4b21b9be16d0518fc62bdf686a

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

[Bug gdb/26828] SIGSEGV in follow_die_offset dwarf2/read.c:22950

[cvs-commit at gcc dot gnu.org]

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

--- Comment #30 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
The gdb-10-branch branch has been updated by Simon Marchi
<simark@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=ad4eb5acbab1b420b346236f2c8c272230477ab7

commit ad4eb5acbab1b420b346236f2c8c272230477ab7
Author: Simon Marchi <simon.marchi@polymtl.ca>
Date:   Tue Feb 23 13:37:44 2021 -0500

    gdb/dwarf: create and destroy dwarf2_per_bfd's CUs-to-expand queue

    As described in the log of patch "gdb/dwarf: add assertion in
    maybe_queue_comp_unit", it would happen that a call to
    maybe_queue_comp_unit would enqueue a CU in the to-expand queue while
    nothing up the stack was processing the queue.  This is not desirable,
    as items are then left lingering in the queue when we exit the
    dwarf2/read code.  This is an inconsistent state.

    The normal case of using the queue is when we go through
    dw2_do_instantiate_symtab and process_queue.  As depended-on CUs are
    found, they get added to the queue.  process_queue expands CUs until the
    queue is empty.

    To catch these cases where things are enqueued while nothing up the
    stack is processing the queue, change dwarf2_per_bfd::queue to be an
    optional.  The optional is instantiated in dwarf2_queue_guard, just
    before where we call process_queue.  In the dwarf2_queue_guard
    destructor, the optional gets reset.  Therefore, the queue object is
    instantiated only when something up the stack is handling it.  If
    another entry point tries to enqueue a CU for expansion, an assertion
    will fail and we know we have something to fix.

    dwarf2_queue_guard sounds like the good place for this, as it's
    currently responsible for making sure the queue gets cleared if we exit
    due to an error.

    This also allows asserting that when age_comp_units or remove_all_cus
    run, the queue is not instantiated, and gives us one more level of
    assurance that we won't free the DIEs of a CU that is in the
    CUs-to-expand queue.

    gdb/ChangeLog:

            PR gdb/26828
            * dwarf2/read.c (dwarf2_queue_guard) <dwarf2_queue_guard>:
            Instantiate queue.
            (~dwarf2_queue_guard): Clear queue.
            (queue_comp_unit): Assert that queue is
            instantiated.
            (process_queue): Adjust.
            * dwarf2/read.h (struct dwarf2_per_bfd) <queue>: Make optional.

    Change-Id: I8fe3d77845bb4ad3d309eac906acebe79d9f0a9d

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

[Bug gdb/26828] SIGSEGV in follow_die_offset dwarf2/read.c:22950

[simark at simark dot ca]

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

Simon Marchi <simark at simark dot ca> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #31 from Simon Marchi <simark at simark dot ca> ---
This is hopefully fixed now.

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

[Bug gdb/26828] SIGSEGV in follow_die_offset dwarf2/read.c:22950

[ahmedsayeed1982 at yahoo dot com]

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

Ahmed Sayeed <ahmedsayeed1982 at yahoo dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ahmedsayeed1982 at yahoo dot com

--- Comment #32 from Ahmed Sayeed <ahmedsayeed1982 at yahoo dot com> ---
The first call returns "frame" and "variables" information.
The second call returns just the "variables".
The third call segfaults in "follow_die_offset" (dwarf2/read.c:22950).

The segfaulting line reads:
   target_cu->ancestor = cu;

target_cu is apparently 0.

I can reproduce the issue with current master
(e1f57067b162cba9f39e087726c7a2f2cfaae96f) too.
http://pitesti.online/
With GDB 9.1 the third (and subsequent) calls don't seem to segfault.

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

[Bug gdb/26828] SIGSEGV in follow_die_offset dwarf2/read.c:22950

[ucelsanicin at yahoo dot com]

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

Ucel Sani <ucelsanicin at yahoo dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ucelsanicin at yahoo dot com

--- Comment #33 from Ucel Sani <ucelsanicin at yahoo dot com> ---
https://www.cherada.net/opus/verified-gmail-accounts
https://www.cherada.net/opus/10000-visitas-a-tu-video-en-youtube
https://www.cherada.net/opus/100-backlinks-en-comentarios-de-blog-a-la-medida
https://redwinecasino.com/
https://sharkcasinogames.com/
https://redbettips.com/
https://windows11iso.com/
https://www.bilanmagazine.com/
https://www.web-mediaplacing.com/
https://www.espresso-international.eu/
https://www.espresso-international.be
https://www.espresso-international.gr
https://komiya-dental.com/
http://steemfilter.space/
http://michielleunens.tech/
http://sleepypoetstuff.website/
http://biciclubvalencia.website/
http://reputation-management.site/
http://pitesti.online/
http://tobuweb.space/
http://ancientmariners.online/
http://betwsycoednet.online
http://kuzin.website
http://kundaliniyoga.tech
http://localpay.tech
http://my-iframe.online
http://getimov.xyz/
http://ooviv.xyz/
http://mirei.xyz
http://toblek.xyz/
http://sevenwonders.store
http://peralga.xyz/
https://texastourgear.live
http://freixenet.site/influencerprogramme/
http://timvanorden.store/
http://rhee.tech/
http://f3group.online/
https://www.hlungomare.store/
https://www.lungomarebikehotel.store
http://www.lvmaimai.xyz/
https://sozdanie.site/
http://agens128.site/
http://ruirui.store/
http://www.foamhands.store/
http://www.i-obchody.info/
http://naughtyrobot.digital/
https://www.webb-dev.co.uk/
https://waytowhatsnext.com/

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

[Bug gdb/26828] SIGSEGV in follow_die_offset dwarf2/read.c:22950

[donipah907 at mtlcz dot com]

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

james rohan <donipah907 at mtlcz dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |donipah907 at mtlcz dot com

--- Comment #34 from james rohan <donipah907 at mtlcz dot com> ---
http://bulletsbaseball.com/
http://healthandfitnessblog.org/
http://ififaworldcup.com/
http://b4blogs.com/
http://targetedtrafficcrew.com/
http://advertising-markets.com/
http://americandogtreats.com/
http://thefoodbuster.com/
http://freshtop10.com/
http://techreformation.com/
http://marketingtailor.com/
http://crystalspins.com/
http://drivingbus.com/
http://twistedpaths.org/
http://autosalbum.com/
http://litespot.net/
http://thebloghopspot.com/
http://orphicmarketing.com/
http://compactinterview.com/
http://techgola.com/
http://tackleacne.com/
http://vibrancemagazine.com/
http://kickintheblog.com/
http://incrediblebirds.com/
http://blog-republic.com/
http://achievelinks.com/
https://verygooddesigns.com/
http://baldmanblogging.com/
http://blogtrader.org/
http://beautyandtheboysblog.com/
http://megafishes.org/
http://creativepartyblog.com/
http://bloglifetime.com/
http://milescollection.com/
http://websitetoad.com/
http://blogtariff.com/
http://ezeesocial.com/
http://protechgeek.com/
http://teethmagic.com/
http://techstake.org/
http://signaturestyleblog.com/
http://weightlosspoints.com/
http://orlando-blogger.com/
http://topinteresting.com/
http://koolwebsolution.com/
http://webpressive.com/
http://bossbloggers.com/
http://torontoboost.com/
http://tigerfreedom.com/
http://orbostwebservices.com/
http://alphasofttech.com/
http://kickandgoal.com/
http://thefashionjungle.com/
http://bloggersworld.org/
http://poempro.com/
http://androidcut.com/
http://exampleofablog.com/
http://austinseoacademy.com/
http://business-technology.net/
http://oceancentre.org/
http://absolutelycooking.com/
https://frizzworld.com/
http://exploreblogs.com/
http://joomlaco.com/
http://appzzone.com/
http://cashcab.org/
http://srinfotech.org/
http://doctornutritionist.com/
http://ultrasound-scanner.com/
http://trafficregenerator.com/
http://solitairelodge.com/
http://poplease.com/
http://authorswebdesign.com/
http://primeroofingsolutions.com/
http://dottblog.com/
http://seekwebsite.com/
http://travelerspage.com/
http://squadfish.com/
http://twoblindmarketers.com/
http://billboardhosting.com/
http://boutiquebeauties.com/
http://interpathtech.com/
http://bsenior.org/
http://positivespinblog.com/
http://bangarts.com/
http://themeslib.com/
http://scriptmanual.com/
http://bestseooptimization.com/
http://wizseoservices.com/
http://assassinmarketing.com/
http://weightoloss.com/
http://dartblogs.com/
http://hairlossremedy.org/
http://softwaretestingpoint.com/
http://beautifulmomentsblog.com/
http://weblandsolutions.com/
http://uniquekidsworld.com/
http://bloggingbusinesstips.com/
http://linkdataservices.com/
http://nandangreens.com/
http://techstake.org/
http://bloglifetime.com/

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

[Bug gdb/26828] SIGSEGV in follow_die_offset dwarf2/read.c:22950

[mark at klomp dot org]

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

Mark Wielaard <mark at klomp dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mark at klomp dot org

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

[Bug gdb/26828] SIGSEGV in follow_die_offset dwarf2/read.c:22950

[focixujo at livinginsurance dot co.uk]

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

james robin <focixujo at livinginsurance dot co.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |focixujo at livinginsurance dot co
                   |                            |.uk

--- Comment #35 from james robin <focixujo at livinginsurance dot co.uk> ---
https://www.montgomeryasphalt.com/
https://www.orangeasphaltrepair.com/
https://www.stpaulasphalt.com/
https://www.miamiflcarpentry.com/
https://www.carpentryatl.com/
https://www.sanbernardinocarpetcleaning.com/
https://www.carpetcleaningfontanaca.com/
https://www.cincinnaticarpetcleaner.net/
https://www.stocktoncarpetcleaning.net/
https://www.carpetsbakersfield.com/
https://www.carpetswestminster.com/
https://www.grandrapidscarpets.com/
https://www.alexandriavacarpet.com/
https://www.colacarpetcleaning.com/
https://www.carpetcleaningvabeach.com/
https://www.newportnewscarpetcleaning.com/
https://www.chimneycleanrepair.com/
https://www.fremontconcrete.net/
https://www.visaliaconcrete.net/
https://www.murrietacaconcrete.com/
https://www.jolietconcrete.net/
https://www.friscoconcrete.net/
https://www.wichitadatacabling.com/
https://www.atldatacabling.com/
https://www.datacablingmiami.com/
https://www.columbiascdeckbuilder.com/
https://www.tallahasseedeckbuilder.com/
https://www.clarksvilledeckbuilder.net/
https://www.alexandriadeckbuilder.com/
https://www.norfolkdeckbuilder.com/
https://www.athensdeckbuilder.com/
https://www.napervilledeckbuilder.com/
https://www.slcdeckbuilder.com/
https://www.centennialdeckbuilder.com/
https://www.kansascitydeck.builder/
https://www.springfielddeckbuilder.com/
https://augustadeckbuilder.com/
https://www.brownsvilledeckbuilder.com/
https://www.dentondeckbuilder.com/
https://www.worcesterdeckbuilder.com/
https://www.mckinneydeck.builder/
https://www.lowelldeckbuilder.com/
https://www.vancouverdeckbuilder.net/
https://www.cambridgedeckbuilder.com/
https://www.columbiamodeckbuilder.com/
https://www.pearlanddeckbuilder.com/
https://www.lakelanddeckbuilder.com/
https://www.westjordandeck.builder/
https://www.bellevuedeckbuilder.com/
https://www.pembrokepinesdeck.builder/
https://www.scottsdaledisabilitylawyer.com/
https://www.divorcescottsdaleaz.com/
https://www.epoxyflooringspokane.com/
https://www.norfolkepoxyflooring.com/
https://www.morenovalleyepoxy.com/
https://www.palmdalecapainters.com/
https://www.paintersgrandprairie.com/
https://www.modestofencebuilder.com/
https://www.glendalefencebuilder.com/
https://www.gilbertfencebuilder.com/
https://www.fontanafencebuilder.com/
https://www.irvingfencebuilder.com/
https://www.morenovalleyfence.net/
https://www.boisefencebuilder.com/
https://www.mesafence.net/
https://www.glendalefence.net/
https://www.honolulufence.net/
https://www.columbiamocontractor.net/
https://www.newhavencontractor.net/
https://www.miamiflcontractor.com/
https://www.ranchocucamongacontractor.net/
https://www.richmondgutter.net/
https://www.desmoinesgutter.com/
https://www.garlandtxpainters.com/
https://www.norfolkinteriorpainters.com/
https://www.atllocksmithga.com/
https://www.locksmithsscottsdale.com/
https://www.tampamasonry.net/
https://www.ontariomasonry.net/
https://www.stamfordmasonry.net/
https://www.gardengrovemasonry.net/
https://www.sterlingheightsmasonry.net/
https://www.newhavenmasonry.net/
https://www.scottsdaleprivateeye.com/
https://www.miamiflprivateinvestigator.com/
https://www.privateeyecincinnati.com/
https://www.kentremodeling.net/
https://www.kckremodeling.com/
https://www.allenremodeling.net/
https://www.orlandoremodeling.net/
https://www.sealcoatingkansascity.com/
https://www.sealcoatcoloradosprings.com/
https://www.elginilsealcoating.com/
https://www.providencesealcoating.com/
https://www.stpaulsealcoating.com/
https://www.tampaflsealcoating.com/
https://www.atlsealcoating.com/
https://www.sanbernardinosealcoating.com/
https://www.elginsepticservices.com/
https://www.aurorasepticservices.com/
https://www.fontanasepticservices.com/
https://www.sanbernardinosepticservices.com/
https://www.minneapolisstuccorepair.com/
https://www.stuccorepairorlandofl.com/
https://www.stuccorepaircapecoral.com/
https://www.orlandofltowing.com/
https://www.ftlauderdaletreeremoval.net/
https://www.treeservicefremont.net/
https://www.treeserviceanaheim.net/
https://www.treeservicestockton.net/
https://www.cincinnatitreecare.net/
https://www.tempetreeservice.net/
https://www.treeserviceaurora.net/
https://www.treeservicebrownsville.com/
https://www.lakewoodtreeservice.net/
https://www.newhaventreeservice.net/
https://www.montgomerytreeservice.net/
https://www.lansingtreecare.net/
https://www.tuscaloosatreeservice.net/
https://www.shreveportreeservice.com/
https://www.batonrougetreeservice.net/
https://www.davenporttreeservice.net/
https://www.greeleytreeservice.net/
https://www.stocktonweddingplanner.com/
https://www.pasadenatxsealcoating.com/

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

[Bug gdb/26828] SIGSEGV in follow_die_offset dwarf2/read.c:22950

[mehmetgelisin at aol dot com]

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

Mehmet gelisin <mehmetgelisin at aol dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mehmetgelisin at aol dot com

--- Comment #36 from Mehmet gelisin <mehmetgelisin at aol dot com> ---
ssibly similar to 23220 however on 64-bit recent Debian sid with
trivial code I see :  http://www-look-4.com/

mimas$ 
mimas$ uname -a  http://www.compilatori.com/
Linux mimas 5.10.0-6-sparc64 #1 Debian 5.10.28-1 (2021-04-09) sparc64 GNU/Linux
mimas$ 
 http://www.wearelondonmade.com/
mimas$ 
mimas$ /usr/bin/gcc --version 
gcc (Debian 10.2.1-6) 10.2.1 20210110 http://www.jopspeech.com/
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
http://joerg.li/ 

mimas$ 

mimas$ http://connstr.net/ 
mimas$ cat -n foo.c 
     1
     2  #include <stdio.h>
     3  #include <stdlib.h>
     4 http://embermanchester.uk/ 
     5  int main(int argc, char **argv)
     6  {
     7      int a = 1;
     8 http://www.slipstone.co.uk/ 
     9      printf("a = %i\n", a);
    10
    11      printf("&a = %p\n", &a);
    12
    13      return EXIT_SUCCESS;
    14 http://www.logoarts.co.uk/ 
    15  }
    16
mimas$ 

mimas$  http://www.acpirateradio.co.uk/ 
mimas$ /usr/bin/gcc -std=iso9899:1999 -pedantic -pedantic-errors -fno-builtin
-g -m64 -O0 -mno-app-regs -mcpu=ultrasparc -mmemory-model=tso -o foo foo.c 
https://waytowhatsnext.com/ 
mimas$  debugging a core file with "-i=mi" and repeatedly running e.g.
"-stack-list-variables --thread 1 --frame 0 --simple-values" results in a
segmentation fault. https://www.webb-dev.co.uk/ 

The first call returns "frame" and "variables" information.
The second call returns just the "variables".
The third call segfaults in "follow_die_offset" (dwarf
http://www.iu-bloomington.com/

The first call returns "frame" and "variables" information.
The second call returns just the "variables".
The third call segfaults in "follow_die_offset" (dwarf2/read.c:22950).

The segfaulting line reads:
   target_cu->ancestor = cu; https://komiya-dental.com/

target_cu is apparent

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

[Bug gdb/26828] SIGSEGV in follow_die_offset dwarf2/read.c:22950

[diheto5497 at secbuf dot com]

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

diheto <diheto5497 at secbuf dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |diheto5497 at secbuf dot com

--- Comment #37 from diheto <diheto5497 at secbuf dot com> ---
Superbly written article, if only all bloggers offered the same content as you,
the internet would be a far better place..
https://abbicare.com.au/
https://www.miningbusiness.net/
https://getweightfast.com
https://www.aloeveraproductsshop.eu/

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

[Bug gdb/26828] SIGSEGV in follow_die_offset dwarf2/read.c:22950

[ReD at idp dot it]

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

--- Comment #38 from Davide Repetto <ReD at idp dot it> ---
May I suggest removing the spam instead of hiding it?
Hidden messages still give incentive. At a minimum, from the SEO perspective.

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

[Bug gdb/26828] SIGSEGV in follow_die_offset dwarf2/read.c:22950

[crownfamilydentistry at hotmail dot com]

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

LV <crownfamilydentistry at hotmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |crownfamilydentistry@hotmai
                   |                            |l.com

--- Comment #39 from LV <crownfamilydentistry at hotmail dot com> ---
 /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:9100: internal-error:
            int maybe_queue_comp_unit(dwarf2_cu*, dwarf2_per_cu_data*,
dwarf2_per_objfile*, language):
            Assertion `per_objfile->get_cu (per_cu) != nullptr' failed.

https://www.crownfamilydentistry.com/

    gdb/ChangeLog:

            PR gdb/26828
            * dwarf2/read.c (maybe_queue_comp_unit): Add assertion.

    Change-Id: I4e51bd7bd58773f9fadf480179cbc4bae61508fe

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

[Bug gdb/26828] SIGSEGV in follow_die_offset dwarf2/read.c:22950

[gulsenenginar at aol dot com]

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

Gulsen Engin <gulsenenginar at aol dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |gulsenenginar at aol dot com

--- Comment #40 from Gulsen Engin <gulsenenginar at aol dot com> ---
$ ../gdb -nx --data-directory=../data-directory                                 
(gdb) set osabi GNU/Linux  http://www.compilatori.com/category/technology/
(gdb) set sysroot /home/simark/build/binutils-gdb/gdb/repo
(gdb) file Foo http://www.acpirateradio.co.uk/category/technology/
Reading symbols from Foo...
(gdb) core-file Foo-core 
warning: Can't open file /media/mmcblk0p1/install/usr/bin/Foo during
file-backed mapping note processing
http://www.logoarts.co.uk/category/technology/
warning: Can't open file /lib/libm-2.21.so during file-backed mapping note
processing
warning: Can't open file /lib/libpthread-2.21.so during file-backed mapping
note processing http://www.slipstone.co.uk/category/technology/ 
warning: Can't open file /lib/libgcc_s.so.1 during file-backed mapping note
processing
warning: Can't open file /media/mmcblk0p1/install/usr/lib/libstdc++.so.6 during
file-backed mapping note processing
http://embermanchester.uk/category/technology/
warning: Can't open file /lib/libc-2.21.so during file-backed mapping note
processing
warning: Can't open file /lib/ld-2.21.so during file-backed mapping note
processing http://connstr.net/category/technology/ 
[New LWP 29367]
[New LWP 29368] http://joerg.li/category/technology/
warning: Could not load shared library symbols for 5 libraries, e.g.
/lib/libc.so.6.
Use the "info sharedlibrary" command to see the complete listing.
http://www.jopspeech.com/category/technology/
Do you need "set solib-search-path" or "set sysroot"?
warning: Unable to find libthread_db matching inferior's thread library, thread
debugging will not be available.
http://www.wearelondonmade.com/category/technology/
warning: Unable to find libthread_db matching inferior's thread library, thread
debugging will not be available. https://waytowhatsnext.com/category/shopping/
Core was generated by `./Foo'.
Program terminated with signal SIGABRT, Aborted.
http://www.iu-bloomington.com/category/shopping/
#0  0xb6c3809c in pthread_cond_wait () from
/home/simark/build/binutils-gdb/gdb/repo/lib/libpthread.so.0
https://komiya-dental.com/category/shopping/
[Current thread is 1 (LWP 29367)]
(gdb) bt http://www-look-4.com/category/technology/
/home/simark/src/binutils-gdb/gdb/arm-tdep.c:1551:30: runtime error: shift
exponent 32 is too large for 32-bit type 'unsigned int'
https://www.webb-dev.co.uk/category/shopping/

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

[Bug gdb/26828] SIGSEGV in follow_die_offset dwarf2/read.c:22950

[vmireskazki at gmail dot com]

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

vmireskazki at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |vmireskazki at gmail dot com

--- Comment #41 from vmireskazki at gmail dot com ---
https://www.secretovnet.org/archives/18806
https://www.secretovnet.org/archives/17685
https://www.secretovnet.org/archives/17683
https://www.secretovnet.org/archives/17681
https://www.secretovnet.org/archives/13740
https://www.secretovnet.org/archives/13737
https://www.secretovnet.org/archives/13734
https://www.secretovnet.org/archives/13732
https://www.secretovnet.org/archives/13729
https://www.secretovnet.org/archives/17679
https://www.secretovnet.org/archives/17677
https://www.secretovnet.org/archives/17675
https://www.secretovnet.org/archives/17670
https://www.secretovnet.org/archives/17667
https://www.secretovnet.org/archives/18686
https://www.secretovnet.org/archives/18684
https://www.secretovnet.org/archives/18682
https://www.secretovnet.org/archives/17665
https://www.secretovnet.org/archives/17663
https://www.secretovnet.org/archives/17661
https://www.secretovnet.org/archives/17659
https://www.secretovnet.org/archives/17657
https://www.secretovnet.org/archives/13723
https://www.secretovnet.org/archives/13717
https://www.secretovnet.org/archives/13714
https://www.secretovnet.org/archives/13711
https://www.secretovnet.org/archives/13708
https://www.secretovnet.org/archives/17655
https://www.secretovnet.org/archives/13702
https://www.secretovnet.org/archives/17647
https://www.secretovnet.org/archives/17645

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

[Bug gdb/26828] SIGSEGV in follow_die_offset dwarf2/read.c:22950

[progonsaytu at gmail dot com]

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

progonsaytu <progonsaytu at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |progonsaytu at gmail dot com

--- Comment #42 from progonsaytu <progonsaytu at gmail dot com> ---
https://www.ремонты-квартир.com/
https://www.дизайн-квартиры.com/
https://www.о-ремонте.com/
https://www.о-заборах.com/
https://www.bsegypt.com/
https://www.buyingrealty.net/
https://www.khersonnews.com/
https://www.kontrolstroy.info/
https://www.sama-mama.com/
https://www.secretovnet.org/
https://www.teleriko.com/
https://www.us-best-store.com/
https://www.віктор.com/
https://www.accord-hotel.ru/
https://releazer.ru/
https://www.a-n-e-k-d-o-t.ru/
https://www.adhan.ru/
http://www.al-aures.ru/
https://www.apriori-design.ru/
http://artdoski.ru/
https://www.bombusmod.net.ru/
https://www.canadianahealthandcaremallreviews.ru/
https://www.celestiaproject.ru/
https://www.cryptogu.ru/
https://www.downloadskypefree.ru/
https://www.encyclopedia-flowers.ru/
https://www.factura.net.ru/
http://freewizards.ru/
http://futurefactory.ru/
https://glina-med.ru/
http://google-dmoz.ru/
http://iix.su/
https://www.imperia51.ru/
https://www.info-tehnologii.ru/
https://www.kvartira-v-bolgarii.ru/
https://ljubi-i-pozdravljaj.ru/
https://www.majesticarticles.ru/
https://www.onlinecredit247.ru/
https://www.orfey.net.ru/
https://www.pgpk.net.ru/
https://www.rainbow.net.ru/
http://www.rainbowbaby.ru/
http://www.respublika-okon.ru/
https://ribku-lovim.ru/
http://rusorchestra.ru/
http://shmoscow.ru/
https://www.skifspb.ru/
https://www.spare.net.ru/
https://www.stranainform.ru/
https://www.taxi-smile.ru/
https://www.tkanishik.ru/
http://www.tremulous.net.ru/
https://trust-women.ru/
http://uralbel.ru/
https://www.yar-art-union.ru/
https://www.xn----7sbcngq4awkg0k.xn--p1ai/
https://www.xn----7sbbmgbytlh3a0ll.xn--p1ai/
https://www.xn--35-mlcuxidl.xn--p1ai/
https://www.xn--f1addf1alkk1d.xn--p1ai/
https://www.history-of-great-discoveries.com/
https://www.it-business-trends.com
https://www.interesting-history-of-art.com
https://www.interesting-news-about-cars.com
https://www.architecture-and-design-news.com
https://history-of-great-discoveries.blogspot.com/
https://it-business-trends.blogspot.com/
https://interesting-history-of-art.blogspot.com/
https://interesting-news-about-cars.blogspot.com/
https://architecture-and-design-news.blogspot.com/

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

[Bug gdb/26828] SIGSEGV in follow_die_offset dwarf2/read.c:22950

[glassmtech at ukr dot net]

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

glassmtech <glassmtech at ukr dot net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |glassmtech at ukr dot net

--- Comment #43 from glassmtech <glassmtech at ukr dot net> ---
http://www.ремонты-квартир.com/
http://www.дизайн-квартиры.com/
http://www.о-ремонте.com/
http://www.о-заборах.com/
http://www.bsegypt.com/
http://www.buyingrealty.net/
http://www.khersonnews.com/
http://www.kontrolstroy.info/
http://www.sama-mama.com/
http://www.secretovnet.org/
http://www.teleriko.com/
http://www.us-best-store.com/
http://www.віктор.com/
http://www.accord-hotel.ru/
http://releazer.ru/
http://www.a-n-e-k-d-o-t.ru/
http://www.adhan.ru/
https://www.al-aures.ru/
http://www.apriori-design.ru/
https://artdoski.ru/
http://www.bombusmod.net.ru/
http://www.canadianahealthandcaremallreviews.ru/
http://www.celestiaproject.ru/
http://www.cryptogu.ru/
http://www.downloadskypefree.ru/
http://www.encyclopedia-flowers.ru/
http://www.factura.net.ru/
https://freewizards.ru/
https://futurefactory.ru/
http://glina-med.ru/
https://google-dmoz.ru/
https://iix.su/
http://www.imperia51.ru/
http://www.info-tehnologii.ru/
http://www.kvartira-v-bolgarii.ru/
http://ljubi-i-pozdravljaj.ru/
http://www.majesticarticles.ru/
http://www.onlinecredit247.ru/
http://www.orfey.net.ru/
http://www.pgpk.net.ru/
http://www.rainbow.net.ru/
https://www.rainbowbaby.ru/
https://www.respublika-okon.ru/
http://ribku-lovim.ru/
https://rusorchestra.ru/
https://shmoscow.ru/
http://www.skifspb.ru/
http://www.spare.net.ru/
http://www.stranainform.ru/
http://www.taxi-smile.ru/
http://www.tkanishik.ru/
https://www.tremulous.net.ru/
http://trust-women.ru/
https://uralbel.ru/
http://www.yar-art-union.ru/
http://www.xn----7sbcngq4awkg0k.xn--p1ai/
http://www.xn----7sbbmgbytlh3a0ll.xn--p1ai/
http://www.xn--35-mlcuxidl.xn--p1ai/
http://www.xn--f1addf1alkk1d.xn--p1ai/
http://www.history-of-great-discoveries.com/
http://www.it-business-trends.com
http://www.interesting-history-of-art.com
http://www.interesting-news-about-cars.com
http://www.architecture-and-design-news.com
https://ремонты-квартир.com/
https://дизайн-квартиры.com/
https://о-ремонте.com/
https://о-заборах.com/
https://bsegypt.com/
https://buyingrealty.net/
https://khersonnews.com/
https://kontrolstroy.info/
https://sama-mama.com/
https://secretovnet.org/
https://teleriko.com/
https://us-best-store.com/
https://віктор.com/
https://accord-hotel.ru/
https://www.releazer.ru/
https://a-n-e-k-d-o-t.ru/
https://adhan.ru/
http://al-aures.ru/
https://apriori-design.ru/
http://www.artdoski.ru/
https://bombusmod.net.ru/
https://canadianahealthandcaremallreviews.ru/
https://celestiaproject.ru/
https://cryptogu.ru/
https://downloadskypefree.ru/
https://encyclopedia-flowers.ru/
https://factura.net.ru/
http://www.freewizards.ru/
http://www.futurefactory.ru/
https://www.glina-med.ru/
http://www.google-dmoz.ru/
http://www.iix.su/
https://imperia51.ru/
https://info-tehnologii.ru/
https://kvartira-v-bolgarii.ru/
https://www.ljubi-i-pozdravljaj.ru/
https://majesticarticles.ru/
https://onlinecredit247.ru/
https://orfey.net.ru/
https://pgpk.net.ru/
https://rainbow.net.ru/
http://rainbowbaby.ru/
http://respublika-okon.ru/
https://www.ribku-lovim.ru/
http://www.rusorchestra.ru/
http://www.shmoscow.ru/
https://skifspb.ru/
https://spare.net.ru/
https://stranainform.ru/
https://taxi-smile.ru/
https://tkanishik.ru/
http://tremulous.net.ru/
https://www.trust-women.ru/
http://www.uralbel.ru/
https://yar-art-union.ru/
https://xn----7sbcngq4awkg0k.xn--p1ai/
https://xn----7sbbmgbytlh3a0ll.xn--p1ai/
https://xn--35-mlcuxidl.xn--p1ai/
https://xn--f1addf1alkk1d.xn--p1ai/
https://history-of-great-discoveries.com/
https://it-business-trends.com
https://interesting-history-of-art.com
https://interesting-news-about-cars.com
https://architecture-and-design-news.com

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

[Bug gdb/26828] SIGSEGV in follow_die_offset dwarf2/read.c:22950

[allen at rockvalleymarketing dot com]

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

LeoRVM <allen at rockvalleymarketing dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |allen at rockvalleymarketing dot c
                   |                            |om

--- Comment #44 from LeoRVM <allen at rockvalleymarketing dot com> ---
I think it be better to remove it. That's just my opinion tho. Anyways, thank
you for this. https://www.tvinstallerthousandoaksca.com/

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