Bug 20020

We had some time for looking into this bug and found the reason for this error seems to be that v in cp-valprint.c:316 can be NULL when the TRY-CATCH is triggered and therefore v never gets assigned. The function cp_print_static_field doesn't check that the passed v is NULL.

  struct value *v = NULL;                                 
                                                          
  TRY                                                     
    {                                                     
      v = value_static_field (type, i);                   
    }                                                     
                                                          
  CATCH (ex, RETURN_MASK_ERROR)                           
    {                                                     
      fprintf_filtered (stream,                           
			_("<error reading variable: %s>"),            
			ex.message);                                  
    }                                                     
  END_CATCH                                               
                                 
	  cp_print_static_field (TYPE_FIELD_TYPE (type, i),   
			 v, stream, recurse + 1,                      
			 options);                                    

We looked into the commit history and there used to be a check that after the exception was thrown v is not NULL. Therefore I would propose the following patch.

  struct value *v = NULL;                               
                                                        
  TRY                                                   
    {                                                   
      v = value_static_field (type, i);                 
    }                                                   
                                                        
  CATCH (ex, RETURN_MASK_ERROR)                         
    {                                                   
      fprintf_filtered (stream,                         
			_("<error reading variable: %s>"),          
			ex.message);                                
      v = NULL; // In case v was already modified       
    }                                                   
  END_CATCH                                             
                                                        
  if (v !=NULL ) {                                      
                                                        
	  cp_print_static_field (TYPE_FIELD_TYPE (type, i), 
			 v, stream, recurse + 1,                    
			 options);                                  
  }                                                                                    

Any comment would be appreciated

Best Regards, 

Thilo

We have started experiencing a similar crash when we switched to g++ 7.1 with c++17 semantics.  When gdb tries to print a "static constexpr", it triggers a "error reading variable: Missing ELF symbol" exception and then crashes at the same place as the original reporter. This seems to happen with every release at least from gdb 7.11. I also built the git master and could reproduce the problem as well.

It's not entirely clear that this is the same exact bug but the crash backtrace is completely similar

I have a simple reproducer:

$ cat main.cpp 
struct A {
    static constexpr const char *a = "a";
    void foo() { }
};

int main(void) {
    A a;
    a.foo();
}

Compile with g++ 7.1 with C++17 semantics: g++-7 -std=c++17 -g -o main main.cpp

Now run it with gdb:

$ gdb main
GNU gdb (Debian 7.11.1-2~bpo8+1) 7.11.1
(...)
(gdb) b A::foo
Breakpoint 1 at 0x40055e: file main.cpp, line 6.
(gdb) r
Starting program: main 

Breakpoint 1, A::foo (this=0x7fffffffe09f) at main.cpp:6
6	    void foo() { }
(gdb) print *this
Segmentation fault (core dumped)

If I patch the source with the workaround mentioned by Thilo (i.e set the ptr to NULL in the catch block and call cp_print_static_field() only if v is not NULL), it does not crash:
(gdb) print *this
$1 = {static a = <error reading variable: Missing ELF symbol "A::a".>}

If I compile the program above with the default c++ semantics(c++ 14), I get 
(gdb) print *this
$1 = {static a = <optimized out>}

With the current git master (8.0.50.20170801-git), this is the backtrace I get for the gdb crash:

Program terminated with signal SIGSEGV, Segmentation fault.
#0  value_entirely_covered_by_range_vector (value=0x0, ranges=0x90) at value.c:401
401	  if (value->lazy)
(gdb) bt
#0  value_entirely_covered_by_range_vector (value=0x0, ranges=0x90) at value.c:401
#1  0x0000000000563282 in cp_print_static_field (options=<optimized out>, recurse=<optimized out>, stream=<optimized out>, val=<optimized out>, type=<optimized out>) at cp-valprint.c:640
#2  cp_print_value_fields (type=0x0, real_type=0x90, real_type@entry=0xf1cd00, offset=offset@entry=0, address=0, address@entry=140737488347295, stream=0xf194c0, recurse=16998736, recurse@entry=0, val=0xf8fc00, options=0x7fffffffda20, dont_print_vb=0x0, dont_print_statmem=0)
    at cp-valprint.c:335
#3  0x00000000005639ca in cp_print_value_fields_rtti (type=<optimized out>, type@entry=0xf1cd00, valaddr=0xf6a330 "", offset=offset@entry=0, address=140737488347295, stream=0xf194c0, recurse=0, val=0xf8fc00, options=0x7fffffffda20, dont_print_vb=0x0, dont_print_statmem=0)
    at cp-valprint.c:456
#4  0x000000000054bf52 in c_val_print_struct (type=0xf1cd00, valaddr=<optimized out>, embedded_offset=0, address=<optimized out>, stream=<optimized out>, recurse=<optimized out>, original_value=0xf8fc00, options=0x7fffffffda20) at c-valprint.c:412
#5  0x000000000054c46f in c_val_print (type=0xf1cd00, embedded_offset=0, address=0, stream=0xf194c0, recurse=0, original_value=0xf8fc00, options=0x7fffffffda20) at c-valprint.c:530
#6  0x0000000000699270 in val_print (type=0x0, type@entry=0xf1cd00, embedded_offset=0, address=15846656, address@entry=140737488347295, stream=stream@entry=0xf194c0, recurse=32767, recurse@entry=0, val=val@entry=0xf8fc00, options=0x7fffffffdae0, language=0x843b80 <cplus_language_defn>)
    at valprint.c:1109
#7  0x000000000054cc1f in c_value_print (val=0xf8fc00, stream=0xf194c0, options=<optimized out>) at c-valprint.c:702
#8  0x0000000000622218 in print_value (val=val@entry=0xf8fc00, fmtp=fmtp@entry=0x7fffffffdbf0) at ./printcmd.c:1179
#9  0x00000000006222ae in print_command_1 (exp=0xd3e366 "*this", voidprint=1) at ./printcmd.c:1207
#10 0x00000000004999e9 in cmd_func (cmd=<optimized out>, args=<optimized out>, from_tty=<optimized out>) at cli/cli-decode.c:1902
#11 0x0000000000684ce6 in execute_command (p=<optimized out>, p@entry=0xd3e360 "print *this", from_tty=1) at top.c:675
#12 0x00000000005ab7dc in command_handler (command=0xd3e360 "print *this") at event-top.c:590
#13 0x00000000005abad8 in command_line_handler (rl=<optimized out>) at event-top.c:780
#14 0x00000000005aae2c in gdb_rl_callback_handler (rl=0xf6a330 "") at event-top.c:213
#15 0x00000000006c6698 in rl_callback_read_char () at callback.c:220
#16 0x00000000005aad6e in gdb_rl_callback_read_char_wrapper_noexcept () at event-top.c:175
#17 0x00000000005aadd9 in gdb_rl_callback_read_char_wrapper (client_data=<optimized out>) at event-top.c:192
#18 0x00000000005ab300 in stdin_event_handler (error=<optimized out>, client_data=0xd3ebc0) at event-top.c:518
#19 0x00000000005aa215 in gdb_wait_for_event (block=block@entry=1) at event-loop.c:859
#20 0x00000000005aa3d3 in gdb_do_one_event () at event-loop.c:347
#21 0x00000000005aa485 in start_event_loop () at event-loop.c:371
#22 0x00000000005ff408 in captured_command_loop (data=data@entry=0x0) at main.c:325
#23 0x00000000005ac3c3 in catch_errors (func=func@entry=0x5ff3e0 <captured_command_loop(void*)>, func_args=func_args@entry=0x0, errstring=errstring@entry=0x7f0ede "", mask=mask@entry=RETURN_MASK_ALL) at exceptions.c:236
#24 0x0000000000600366 in captured_main (data=0x7fffffffdec0) at main.c:1150
#25 gdb_main (args=args@entry=0x7fffffffdff0) at main.c:1160
#26 0x0000000000411ae5 in main (argc=<optimized out>, argv=<optimized out>) at gdb.c:32

(In reply to Thilo Voertler from comment #1)
> Any comment would be appreciated

Thank you for chasing this down. I have investigated this a little, and I see this hunk from commit 492d29ea is probably the culprit:

@@ -313,18 +313,21 @@ cp_print_value_fields (struct type *type, struct type *rea
l_type,
                }
              else if (field_is_static (&TYPE_FIELD (type, i)))
                {
-                 volatile struct gdb_exception ex;
                  struct value *v = NULL;
 
-                 TRY_CATCH (ex, RETURN_MASK_ERROR)
+                 TRY
                    {
                      v = value_static_field (type, i);
                    }
 
-                 if (ex.reason < 0)
-                   fprintf_filtered (stream,
-                                     _("<error reading variable: %s>"),
-                                     ex.message);
+                 CATCH (ex, RETURN_MASK_ERROR)
+                   {
+                     fprintf_filtered (stream,
+                                       _("<error reading variable: %s>"),
+                                       ex.message);
+                   }
+                 END_CATCH
+
                  cp_print_static_field (TYPE_FIELD_TYPE (type, i),
                                         v, stream, recurse + 1,
                                         options);

Your patch should fix that. Would you care to submit your (properly formatted) patch (and ChangeLog) to gdb-patches@sourceware.org?

(In reply to Guillaume Morin from comment #2)
> We have started experiencing a similar crash when we switched to g++ 7.1
> with c++17 semantics.  When gdb tries to print a "static constexpr", it
> triggers a "error reading variable: Missing ELF symbol" exception and then
> crashes at the same place as the original reporter. This seems to happen
> with every release at least from gdb 7.11. I also built the git master and
> could reproduce the problem as well.

This appears consistent with this bug, thank you for reporting.

> I have a simple reproducer:
> 

Awesome! Thank you very much for this!

> Now run it with gdb:

I tried your test case (using gcc 7.0-20160916 (experimental) -- the gdb c++ compile branch) and did not reproduce the crash. I will try building something newer. Can you give me the exact compiler version you are using? [g++ -v]

> If I compile the program above with the default c++ semantics(c++ 14), I get 
> (gdb) print *this
> $1 = {static a = <optimized out>}
> 

That appears to be another issue (which I have also investigated). I'm going to open a new bug about this, c++/21892. Let's move the "optimized out" discussion there.

(In reply to Keith Seitz from comment #3)
> (In reply to Thilo Voertler from comment #1)
> > Any comment would be appreciated
> 
> Thank you for chasing this down. I have investigated this a little, and I
> see this hunk from commit 492d29ea is probably the culprit:

Actually to be pedantic, that's not the problem. The NULL check was already missing by the time that patch was applied. It *does* appear in commit ee86786c, so something between the two erased it.

(In reply to Keith Seitz from comment #3)
> I tried your test case (using gcc 7.0-20160916 (experimental) -- the gdb c++
> compile branch) and did not reproduce the crash. I will try building
> something newer. Can you give me the exact compiler version you are using?

This is Debian's gcc 7.1.0-10 (from testing)

Using built-in specs.
COLLECT_GCC=g++-7
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 7.1.0-10' --with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr --with-gcc-major-version-only --program-suffix=-7 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie --with-system-zlib --with-target-system-zlib --enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 7.1.0 (Debian 7.1.0-10)

I tested in a Debian testing chroot and reproduced it without any issues. So I believe it should be easy for you to reproduce with a similar version

Note: https://sourceware.org/bugzilla/show_bug.cgi?id=20607 is probably the same bug

This is very interesting; I thought it was only me that experienced this. I have been looking into this issue, off and on (tho' mostly off) for some months. I have found that it can be avoided in our situation, by running "set print static-members off" either by hand or in .gdbinit.

While I agree with Thilo's approach below of testing for a NULL-pointer before calling cp_print_static_field(), it seems to me that this may not actually fix the problem - and perhaps cause another.

I was concerned with the latter case because if gdb was unable to find a variable (in the call to value_static_field()), then perhaps it is better to crash (perhaps using gdb_assert())? This call to value_static_field() after all occurs in a for-loop and so perhaps the problem worsens ignoring by the NULL-pointer? Maybe? I defer to Thilo's experience in this regard; if the fix seems to work with no side effect, great.

I bring up the problem of something else being the real source of the problem because I found in my cases that GDB was trying to reference a variable that I couldn't even find (ie, the cause of the NULL-pointer). In my case there was a C++ template:

template<class BlockConfigurator>

class BlockHolder

{
    ...

    static const uns32 DEBUGLOG_ENUM_LOGALL = 0xFFFFFFFF;
}

During investigation, I discovered that the symbol is not even present in the output of "objdump -t <path>/binary_unstripped". I made the assumption that the symbol was a prime candidate to be optimized out since it is static, const, and with a predefined value. I also assumed that if I used a debug build, that the symbol was more likely to be found. Oddly, it wasn't.

In short, this looks like a situation in which the compiler/linker have conspired, so to speak, against gdb. I'm not really sure there is anything that can be done in this situation except add various conditionals like Thilo's to avoid the problem.

Regards,
Jim Muchow

I've started seeing this when printing C++ std::atomic<T*> values.

Here's the reproducer i came up with:

-- x.cc -----------------------------
template<typename _Tp>
struct foo
{
  static constexpr bool is_always_lock_free = true;
};


int main()
{
  foo<int> p;
  return 0;
}
---------------------------------------------------------

Then with 

gcc version 7.2.1 20170915 (Red Hat 7.2.1-2) (GCC) 

we get

$ /usr/bin/gcc -g -o x x.cc -std=c++17
$ ~/tmp/gdb/gdb-8.0.1/gdb/gdb ./x
...
GNU gdb (GDB) 8.0.1
...
Reading symbols from ./x...done.
(gdb) break main
Breakpoint 1 at 0x40048b: file x.cc, line 11.
(gdb) run
Starting program: /home/sss/atlas/dvtest/x 

Breakpoint 1, Python Exception <type 'exceptions.NameError'> Installation error: gdb.execute_unwinders function is missing: 
main () at x.cc:11
11	  return 0;
(gdb) p p
$1 = {
Segmentation fault (core dumped)


The crash is the same as reported earlier in this thread.

Can confirm this bug in GNU gdb (Debian 7.12-6+b1) 7.12.0.20161007-git
when printing std::atomic<> variables. gcc version 7.2.0
Doing "set print static-members off" really helps. Thanks.

This is a duplicate of 20607.

*** Bug 17685 has been marked as a duplicate of this bug. ***

I somewhat arbitrarily chose this one as the canonical bug report;
but note that bug 17685 has a test executable which can perhaps
be used to reproduce as well.

*** Bug 23953 has been marked as a duplicate of this bug. ***

*** Bug 19382 has been marked as a duplicate of this bug. ***

Another trivial reproducer from https://stackoverflow.com/questions/55314720/gdb-crashes-when-printing-value-of-atomic-enum

#include <atomic>

enum class foo {ONE, TWO, THREE, FOUR, FIVE, SIX};

int main(int argc, char **argv)
{
  std::atomic<foo> x = foo::FOUR;
  std::atomic<int> y = int(foo::FOUR);
  return 0;
}

g++ -g -std=c++17 t.cc

(gdb) print y -- works fine
(gdb_ print x -- crash in value_entirely_covered_by_range_vector(), using current trunk.

value_entirely_covered_by_range_vector (value=value@entry=0x0, ranges=...) at ../../gdb/value.c:416
416	  if (value->lazy)

This fixes the atomic crash but I haven't written a test yet.

diff --git a/gdb/cp-valprint.c b/gdb/cp-valprint.c
index 7124da42ec9..8feaae03aac 100644
--- a/gdb/cp-valprint.c
+++ b/gdb/cp-valprint.c
@@ -314,13 +314,14 @@ cp_print_value_fields (struct type *type, struct type *real_type,
 		}
 	      else if (field_is_static (&TYPE_FIELD (type, i)))
 		{
-		  struct value *v = NULL;
-
 		  TRY
 		    {
-		      v = value_static_field (type, i);
-		    }
+		      struct value *v = value_static_field (type, i);
 
+		      cp_print_static_field (TYPE_FIELD_TYPE (type, i),
+					     v, stream, recurse + 1,
+					     options);
+		    }
 		  CATCH (ex, RETURN_MASK_ERROR)
 		    {
 		      fprintf_filtered (stream,
@@ -328,10 +329,6 @@ cp_print_value_fields (struct type *type, struct type *real_type,
 					ex.message);
 		    }
 		  END_CATCH
-
-		  cp_print_static_field (TYPE_FIELD_TYPE (type, i),
-					 v, stream, recurse + 1,
-					 options);
 		}
 	      else if (i == vptr_fieldno && type == vptr_basetype)
 		{

Before applying Tom's patch:

(gdb) p m_buffer->recording_ringbuffer.m_tail
$3 = {_M_b = {Segmentation fault (core dumped)

After applying Tom's patch:

(gdb) p m_buffer->recording_ringbuffer.m_tail
$1 = {_M_b = {_M_p = 0x0}, static is_always_lock_free = <error reading variable: Missing ELF symbol "std::atomic<evio::RecordingData**>::is_always_lock_free".>}

FWIW there's also a gcc bug involved
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90526

The master branch has been updated by Tom Tromey <tromey@sourceware.org>:

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

commit 4330d61dfb05d77fd925efdca45091f12e3a6266
Author: Tom Tromey <tromey@adacore.com>
Date:   Wed May 29 09:34:50 2019 -0600

    Fix crash in cp_print_value_fields
    
    PR c++/20020 concerns a crash in cp_print_value_fields.  The immediate
    cause is that cp_print_value_fields does not handle the case where
    value_static_field fails.  This is fixed in this patch by calling
    cp_print_static_field from the "try" block.
    
    Digging a bit deeper, the error occurs because GCC does not emit a
    DW_AT_const_value for a static constexpr member appearing in a
    template class.  I've filed a GCC bug for this.
    
    Tested on x86-64 Fedora 29.
    
    gdb/ChangeLog
    2019-05-29  Tom Tromey  <tromey@adacore.com>
    
    	PR c++/20020:
    	* cp-valprint.c (cp_print_value_fields): Call
    	cp_print_static_field inside "try".
    
    gdb/testsuite/ChangeLog
    2019-05-29  Tom Tromey  <tromey@adacore.com>
    
    	PR c++/20020:
    	* gdb.cp/constexpr-field.exp: New file.
    	* gdb.cp/constexpr-field.cc: New file.

Fixed.

*** Bug 18929 has been marked as a duplicate of this bug. ***

The master branch has been updated by Tom Tromey <tromey@sourceware.org>:

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

commit 3d507ff23b724ecb2b9a5a61cebd0fba275cfbc3
Author: Tom Tromey <tromey@adacore.com>
Date:   Tue Jun 18 09:37:02 2019 -0600

    Fix two buglets in cp_print_value_fields patch
    
    Pedro and Tom both pointed out issues in the cp_print_value_fields
    patch, aka the fix for PR c++/20020.
    
    This patch addresses both issues.  Tested on x86-64 Fedora 29.
    
    gdb/ChangeLog
    2019-06-27  Tom Tromey  <tromey@adacore.com>
    
    	* cp-valprint.c (cp_print_value_fields): Pass opts, not options,
    	to cp_print_static_field.
    
    gdb/testsuite/ChangeLog
    2019-06-27  Tom Tromey  <tromey@adacore.com>
    
    	* gdb.cp/constexpr-field.exp: Use setup_xfail.

*** Bug 24745 has been marked as a duplicate of this bug. ***

*** Bug 24864 has been marked as a duplicate of this bug. ***

The gdb-8.3-branch branch has been updated by Tom de Vries <vries@sourceware.org>:

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

commit 98c90f80283bbdf7df140041e3b784bfcb3b1d39
Author: Tom Tromey <tromey@adacore.com>
Date:   Sat Aug 3 09:42:28 2019 +0200

    Fix crash in cp_print_value_fields
    
    [ Backport of master commit 4330d61dfb. ]
    
    PR c++/20020 concerns a crash in cp_print_value_fields.  The immediate
    cause is that cp_print_value_fields does not handle the case where
    value_static_field fails.  This is fixed in this patch by calling
    cp_print_static_field from the "try" block.
    
    Digging a bit deeper, the error occurs because GCC does not emit a
    DW_AT_const_value for a static constexpr member appearing in a
    template class.  I've filed a GCC bug for this.
    
    Tested on x86-64 Fedora 29.
    
    gdb/ChangeLog
    2019-05-29  Tom Tromey  <tromey@adacore.com>
    
    	PR c++/20020:
    	* cp-valprint.c (cp_print_value_fields): Call
    	cp_print_static_field inside "try".
    
    gdb/testsuite/ChangeLog
    2019-05-29  Tom Tromey  <tromey@adacore.com>
    
    	PR c++/20020:
    	* gdb.cp/constexpr-field.exp: New file.
    	* gdb.cp/constexpr-field.cc: New file.

The gdb-8.3-branch branch has been updated by Tom de Vries <vries@sourceware.org>:

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

commit 15522b80c90063b01a16de98e460dfa52054fba6
Author: Tom Tromey <tromey@adacore.com>
Date:   Sat Aug 3 09:42:28 2019 +0200

    Fix buglet in cp_print_value_fields patch
    
    [ Backport of master commit 3d507ff23b. ]
    
    Pedro pointed out an issue in the cp_print_value_fields
    patch, aka the fix for PR c++/20020.
    
    This patch addresses the issue.  Tested on x86-64 Fedora 29.
    
    gdb/testsuite/ChangeLog
    2019-06-27  Tom Tromey  <tromey@adacore.com>
    
    	* gdb.cp/constexpr-field.exp: Use setup_xfail.

switching the milestone to 8.3.1 since the patch was backported.

The gdb-8.3-branch branch has been updated by Tom de Vries <vries@sourceware.org>:

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

commit 59047affb0a95c7b76528b91bb378c7117c580ac
Author: Tom de Vries <tdevries@suse.de>
Date:   Wed Sep 18 22:53:21 2019 +0200

    Update ChangeLog entry of commit 98c90f8028 and mention PR c++/20020

The master branch has been updated by Tom de Vries <vries@sourceware.org>:

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

commit d039f01465b37026e538b06ff792aadc4b19bf24
Author: Tom de Vries <tdevries@suse.de>
Date:   Sun Oct 13 15:09:09 2019 +0200

    Mention PR c++/20020 in ChangeLog entry
    
    [ Port of gdb-8.3-branch commit 59047affb0a "Update ChangeLog entry of commit
    98c90f8028 and mention PR c++/20020". ]

*** Bug 24379 has been marked as a duplicate of this bug. ***

*** Bug 24865 has been marked as a duplicate of this bug. ***

*** Bug 17076 has been marked as a duplicate of this bug. ***