[PATCH] trace-cmd: make sure we have a pending pid in trace-hist

[Josef Bacik <jbacik@fb.com>]

I have a trace.dat file where we lost some events and so we didn't have the
corresponding event to go with the stack trace.  This made trace-cmd hist
segfault because it unconditionally pushes the pending_pid's function onto the
stack trace.  In this case pending_pid < 0, which means we didn't have a pending
stack trace, so we got garbage in the call chain and hilarity ensued.  Fix this
by only pushing the pending call chain if there actually is one, and also don't
reset the current call chain if there isn't actually one there either.  This
fixed my segfault.  Thanks,

Signed-off-by: Josef Bacik <jbacik@fb.com>
---
 trace-hist.c | 14 +++++++++-----
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/trace-hist.c b/trace-hist.c
index 73820de..574549e 100644
--- a/trace-hist.c
+++ b/trace-hist.c
@@ -453,9 +453,11 @@ process_kernel_stack(struct pevent *pevent, struct pevent_record *record)
 		}
 	} else {
 		/* function stack trace? */
-		copy_stack_to_pending(current_pid);
-		free(ips);
-		reset_stack();
+		if (current_pid >= 0) {
+			copy_stack_to_pending(current_pid);
+			free(ips);
+			reset_stack();
+		}
 	}
 
 	current_pid = pid;
@@ -482,8 +484,10 @@ process_kernel_stack(struct pevent *pevent, struct pevent_record *record)
 			push_stack_func(func);
 	}
 
-	push_stack_func(pending_ips[pending_ips_idx - 1]);
-	reset_pending_stack();
+	if (pending_pid >= 0) {
+		push_stack_func(pending_ips[pending_ips_idx - 1]);
+		reset_pending_stack();
+	}
 	save_call_chain(current_pid, ips, ips_idx, 1);
 	if (do_restore)
 		restore_stack(current_pid);
-- 
2.0.0