Bug 862795

Summary:	script debugging via valgrind gdb server behaves strange, throwing error where it shouldn't
Product:	Red Hat Enterprise Linux 6	Reporter:	Miroslav Franc <mfranc>
Component:	valgrind	Assignee:	Mark Wielaard <mjw>
Status:	CLOSED ERRATA	QA Contact:	qe-baseos-tools-bugs
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	6.4	CC:	fche, jakub, mcermak, mfranc, ohudlick, pmuller
Target Milestone:	rc
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
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".	Story Points:	---
Clone Of:
Clones:	863028 863029 (view as bug list)		Environment:
Last Closed:	2013-02-21 08:51:08 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	863028, 863029

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);

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

  f(a);

  return 0;
}

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


--- script.gdb ---
target remote | vgdb
b 10
c
set (a=5)
c
q
--- 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
(gdb)


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
valgrind-3.8.1-2.1.el6.x86_64
gdb-7.2-59.el6.x86_64

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.

http://rhn.redhat.com/errata/RHBA-2013-0347.html