Bug 862795 - script debugging via valgrind gdb server behaves strange, throwing error where it shouldn't
Summary: script debugging via valgrind gdb server behaves strange, throwing error wher...
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: valgrind
Version: 6.4
Hardware: All
OS: Linux
Target Milestone: rc
: ---
Assignee: Mark Wielaard
QA Contact: qe-baseos-tools
Depends On:
Blocks: 863028 863029
TreeView+ depends on / blocked
Reported: 2012-10-03 14:46 UTC by Miroslav Franc
Modified: 2016-02-01 02:27 UTC (History)
6 users (show)

Fixed In Version: 3.8.1-3.1.el6
Doc Type: Bug Fix
Doc Text:
Before the valgrind gdbserver would not properly report exit or fatal signal process end to gdb resulting in "Remote connection closed" errors. Now the process end is properly reported in gdb as "process exited normally".
Clone Of:
: 863028 863029 (view as bug list)
Last Closed: 2013-02-21 08:51:08 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2013:0347 normal SHIPPED_LIVE valgrind bug fix and enhancement update 2013-02-20 20:53:42 UTC
KDE Software Compilation 308341 None None None 2012-10-13 20:41:02 UTC

Description Miroslav Franc 2012-10-03 14:46:23 UTC
Not sure whether this is gdb or valgrind issue.  I wanted to write myself small automatic sanity test to make sure feature (bug 672959) is working (that's why the c code is a bit contrived).  And I hit the following problem.

--- something.c ---
#include <stdio.h>

void f (int x);

main (int argc, char *argv[])
  int a;


  return 0;

f (int x)
  static int var __attribute__ ((used)) = 42;
    puts("hello, world");
--- something.c ---

--- script.gdb ---
target remote | vgdb
b 10
set (a=5)
--- script.gdb ---

1. gcc -g something.c
2. valgrind --vgdb-error=0 ./a.out
3. gdb -x ./script.gdb ./a.out
relaying data between gdb and process 17458
[Switching to Thread 17458]
0x00000036d2400b00 in _start () from /lib64/ld-linux-x86-64.so.2
Breakpoint 1 at 0x4004d3: file something.c, line 10.

Breakpoint 1, main (argc=1, argv=0x7ff000348) at neco.c:10
10        f(a);
./script.gdb:5: Error in sourced command file:
Remote connection closed

Tha same thing happens when I let the valgrind hit the bug.  I was unable to reproduce something like that with gdb-gdbserver, that's why I'm filing this against valgrind, but I might be wrong, when copy pasted these commands work just fine.

# rpm -q valgrind gdb

Comment 1 Mark Wielaard 2012-10-11 19:59:54 UTC
The issue is that the valgrind gdbserver doesn't report final process exit. gdb is waiting for a reply after the continue but doesn't get anything, sees the remote connection gone and freaks out.

A not really correct patch (it reports exit was just fine no matter what) to get the sample script working would be:

Index: coregrind/m_gdbserver/server.c
--- coregrind/m_gdbserver/server.c	(revision 13022)
+++ coregrind/m_gdbserver/server.c	(working copy)
@@ -730,6 +730,12 @@
 void gdbserver_terminate (void)
+   if (resume_reply_packet_needed) {
+      resume_reply_packet_needed = False;
+      prepare_resume_reply (own_buf, 'W', 0);
+      putpkt (own_buf);
+   }
    /* last call to gdbserver is cleanup call */
    if (VG_MINIMAL_SETJMP(toplevel)) {
       dlog(0, "error caused VG_MINIMAL_LONGJMP to gdbserver_terminate\n");

$ gdb -x ./script.gdb ./a.out
Reading symbols from /usr/local/src/tests/vgdb/a.out...done.
relaying data between gdb and process 3729
[Switching to Thread 3729]
0x0000003e77a01530 in _start () from /lib64/ld-linux-x86-64.so.2
Breakpoint 1 at 0x4004eb: file something.c, line 10.

Breakpoint 1, main (argc=1, argv=0x7feffff68) at something.c:12
12	  f(a);
[Inferior 1 (Remote target) exited normally]

I'll report upstream and see if we can get the proper exit code of the process reported to gdb before final termination.

Comment 5 errata-xmlrpc 2013-02-21 08:51:08 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.


Note You need to log in before you can comment on or make changes to this bug.