[Bug gdb/19389] New: GDB sometimes mistakenly allows accessing registers of running threads

["palves at redhat dot com" <sourceware-bugzilla at sourceware dot org>]

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

            Bug ID: 19389
           Summary: GDB sometimes mistakenly allows accessing registers of
                    running threads
           Product: gdb
           Version: HEAD
            Status: NEW
          Severity: normal
          Priority: P2
         Component: gdb
          Assignee: unassigned at sourceware dot org
          Reporter: palves at redhat dot com
  Target Milestone: ---

Take the testsuite/gdb.threads/schedlock.c test, and set a breakpoint with a
condition that evaluates false in the loop where threads are spinning.  Here in
line 81:

73      void *thread_function(void *arg) {
74          int my_number =  (long) arg;
75          int *myp = (int *) &args[my_number];
76
77          /* Don't run forever.  Run just short of it :)  */
78          while (*myp > 0)
79            {
80              /* schedlock.exp: main loop.  */
81              MAYBE_CALL_SOME_FUNCTION(); (*myp) ++;
82            }
83
84          pthread_exit(NULL);
85      }
86

Then let the inferior run in the background.  Even though internally, threads
are constantly tripping on the breakpoint and being stepped past it, from the
user's perspective, all threads are always running.  So if the user tries to
print a registers, e.g., "print $pc", GDB should always give back an error.  
However, sometimes, "print $pc" "succeeds" and shows a register value.

Vis:

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
(gdb) start
Temporary breakpoint 1 at 0x4006f8: file
/home/pedro/gdb/mygit/src/gdb/testsuite/gdb.threads/schedlock.c, line 35.
Starting program:
/home/pedro/gdb/mygit/build/gdb/testsuite/gdb.threads/schedlock 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".

Temporary breakpoint 1, main () at
/home/pedro/gdb/mygit/src/gdb/testsuite/gdb.threads/schedlock.c:35
35          for (i = 1; i <= NUM; i++)
(gdb) c&
Continuing.
(gdb) [New Thread 0x7ffff7fc0700 (LWP 19582)]
info threads
  Id   Target Id         Frame 
* 1    Thread 0x7ffff7fc1740 (LWP 19578) "schedlock" (running)
  2    Thread 0x7ffff7fc0700 (LWP 19582) "schedlock" (running)
(gdb) p $pc
$1 = (void (*)()) 0x4007a0 <thread_function+40>
(gdb) 
Target is executing.
(gdb) 
Target is executing.
(gdb) 
Target is executing.
(gdb) 
Target is executing.
(gdb) 
Target is executing.
(gdb) 
Target is executing.
(gdb) 
Target is executing.
(gdb) 
Target is executing.
(gdb) 
Target is executing.
(gdb) 
Target is executing.
(gdb) 
Target is executing.
(gdb) 
Target is executing.
(gdb) 
Target is executing.
(gdb) 
Target is executing.
(gdb) 
Target is executing.
(gdb) 
Target is executing.
(gdb) 
$2 = (void (*)()) 0x4007a0 <thread_function+40>
(gdb) 
Target is executing.
(gdb) 
Target is executing.
(gdb) 
Target is executing.
(gdb) 
Target is executing.
(gdb) 
Target is executing.
(gdb) 
Target is executing.
(gdb) 
$3 = (void (*)()) 0x4007a0 <thread_function+40>
(gdb) 
$4 = (void (*)()) 0x4007a0 <thread_function+40>
(gdb) 
Target is executing.
(gdb) 
Target is executing.
(gdb)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Note the several occurrences of "= (void (*)()) 0x4007a0 <thread_function+40>".

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