[valgrind] [Bug 458212] Bad XML produced when a fatal_signal is encountered

[Paul Floyd]

https://bugs.kde.org/show_bug.cgi?id=458212

--- Comment #6 from Paul Floyd  ---
%p has been there for a long time.

I've used it for nightly / weekend tests with post-process scripts to parse all
logs.

-- 
You are receiving this mail because:
You are watching all bug changes.

[valgrind] [Bug 458212] Bad XML produced when a fatal_signal is encountered

[Jim Kuhn]

https://bugs.kde.org/show_bug.cgi?id=458212

--- Comment #5 from Jim Kuhn  ---
> Is using %p in the filename a satisfactory workaround?

That's probably fine for cases where the multiple xml files can be easily
post-processed, but I suspect there are a lot of consumers of this data that
expect it to be in one file (Jenkins plugins, for one).

Perhaps both options could be provided (legacy [single-file] and new
[multi-file]) with a push to getting downstream consumers to use the new
multi-file output.

-- 
You are receiving this mail because:
You are watching all bug changes.

[valgrind] [Bug 458212] Bad XML produced when a fatal_signal is encountered

[Paul Floyd]

https://bugs.kde.org/show_bug.cgi?id=458212

--- Comment #4 from Paul Floyd  ---
Is using %p in the filename a satisfactory workaround?

-- 
You are receiving this mail because:
You are watching all bug changes.

[valgrind] [Bug 458212] Bad XML produced when a fatal_signal is encountered

[Paul Floyd]

https://bugs.kde.org/show_bug.cgi?id=458212

--- Comment #3 from Paul Floyd  ---
Hmm. For this example, the /valgrindout in both cases comes from
shutdown_actions_NORETURN in m_main.c

The problem is that both processes write their summaries and  to
the same file. So in addition to the ill-formed xml end tags there is also one
 RUNNING and 2  FINISHED, only 1  and 

The best thing to do is to use %p to have a per-process xml file.

It's going to be tricky for the forked Valgrind processes to know which is the
last standing and for only that process to write the end tag

-- 
You are receiving this mail because:
You are watching all bug changes.

[valgrind] [Bug 458212] Bad XML produced when a fatal_signal is encountered

[Jim Kuhn]

https://bugs.kde.org/show_bug.cgi?id=458212

--- Comment #2 from Jim Kuhn  ---

(In reply to Paul Floyd from comment #1)
[...]
> Can you provide a small testcase to reproduce?

#include 
#include 

int main(int argc, char** argv) {
  if (!fork()) {
abort();
  }
  malloc(10); // something for memcheck
}

$ valgrind --trace-children=yes --xml=yes --xml-file=test.memcheck ./a.out
$ grep valgrindoutput test.memcheck



```

-- 
You are receiving this mail because:
You are watching all bug changes.

[valgrind] [Bug 458212] Bad XML produced when a fatal_signal is encountered

[Paul Floyd]

https://bugs.kde.org/show_bug.cgi?id=458212

Paul Floyd  changed:

   What|Removed |Added

 CC||pjfl...@wanadoo.fr

--- Comment #1 from Paul Floyd  ---
Loooking at the source there are several calls to 
  VG_(printf_xml)("\n");

1. m_main.c shutdown_actions_NORETURN. This should exit or panic.
2. m_libcassert.c VG_(assert_fail) and panic and VG_(unimplemented). panic
doesn't exit immediately (the others should)
3. m_errormgr.c do_actions_on_error and load_one_suppressions_file (x3).
do_actions_on_error doesn't exit immediately.

That shouldn't be too hard to debug.

Can you provide a small testcase to reproduce?

-- 
You are receiving this mail because:
You are watching all bug changes.

[valgrind] [Bug 458212] Bad XML produced when a fatal_signal is encountered

[Jim Kuhn]

https://bugs.kde.org/show_bug.cgi?id=458212

Jim Kuhn  changed:

   What|Removed |Added

 OS|Other   |Linux
   Platform|Other   |Compiled Sources

-- 
You are receiving this mail because:
You are watching all bug changes.