This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[patch] segmentation fault at gdbserver

The repro step is:
1. compile and link the test app (which contains an infinite loop)
2. run the app
3. start gdbserver in multiprocess mode (e.g. gdbserver --multi :5040)
3. attach the running process in gdb
4. detach
5. quit

Note: I did not setup any tracepoints during the experiment.
But at step 5, gdbserver will get segmentation fault. The
segmentation fault is caused by de-referencing a null pointer
variable: *current_inferior*. But this issue may be exposed as well
even you have tracepoints setup.

The two commands "detach" and "quit" at gdb side would issue
*remote_get_trace_status* function call respectively in the
form of "qTStatus". In the handle of gdbserver side for this
event gdbserver/tracepoint.c::cmd_qtstatus calls
upload_fast_traceframes() in case the is loaded.
Upload_fast_traceframes() eventually references the *current_inferior*
, which is null at the 2nd call of cmd_qtstatus.

Current_inferior is set to NULL at gdbserver after receiving *detach*.
(server.c:2751). So at the time of "quit", the pointer is already NULL.

OK to apply the patch below?


--- tracepoint.c.orig   2011-05-12 07:09:18.000000000 -0500
+++ tracepoint.c        2011-06-22 14:05:13.553993630 -0500
@@ -3159,7 +3159,7 @@
   trace_debug ("Returning trace status as %d, stop reason %s",
               tracing, tracing_stop_reason);

-  if (in_process_agent_loaded ())
+  if (in_process_agent_loaded () && current_inferior != NULL)
       pause_all (1);

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]