[Crash-utility] [PATCH] Fix parse_line when expression is followed by a character that is not token-terminating

Commit e082c372c7f1a782b058ec359dfbbbee0f0b6aad reworked parse_line to make a single expression encompassed by a set of parenthesis into a single argument. In the process it changed parse_line to improperly handle lines like the following: p (struct task_struct *)0xffff881813c40aa0 It could still properly handle lines with a space after the expression: p (struct task_struct *) 0xffff881813c40aa0 The reason it failed with the former is that once exiting the expression loop when seeing the terminating ')' and expression == 0, it would then start the next token at the next character after the terminating ')' but there was no place for a terminating NULL char. As a result, the call to parse_line would return 3 instead of two, and an error would result: crash> p (struct task_struct *)0xffff881813c40aa0 A syntax error in expression, near `0xffff881813c40aa0'. p: gdb request failed: p (struct task_struct *)0xffff881813c40aa0 0xffff881813c40aa0 The fix is fairly straightforward. Just 'continue' the loop once we exit the expression code. That way we retain the same behavior as before when an address follows directly an expression without a space. Signed-off-by: Dave Wysochanski <dwysocha(a)redhat.com&gt; --- tools.c | 4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/tools.c b/tools.c index eceea90..2d95c3a 100644 --- a/tools.c +++ b/tools.c @@ -246,8 +246,10 @@ next: break; } } - if (expression == 0) + if (expression == 0) { i++; + continue; + } } if (str[i] != NULLCHAR && str[i] != '\n') { -- 1.7.1