[Lldb-commits] [PATCH] D89600: [lldb] Move copying of reproducer out of process

[Pavel Labath via Phabricator via lldb-commits]

labath added a comment.

Hm... Are you sure that this will help with anything? IIUC, the serialization of the VFS file map still happens in the context of the crashing process. This requires walking a bunch of data structures with liberally-asserting code, which will abort on any inconsistency it runs into. If *that* succeeds, I'd expect that the copying of the files will succeed too.

I think it would be better if we moved the vfs map construction into the other process too. Maybe via something like this:

- The first process opens a "log" file, which will contain the list of files to be copied. For added safety the file should be opened append-only.
- As it works, it writes file names to this file.
- Upon a crash, the re-execed process reads this file, constructs the vfs map, and copies all necessary files. It should be prepared to handle/ignore any garbled entries, and the format of the file should make this easy. (Since the log file must by definition contain enough information to recreate the vfs map, it might be simpler to not write out the map, but just always recreate it in memory when replaying.)



================
Comment at: lldb/tools/driver/Driver.cpp:857
+        str->append(" --reproducer-finalize ");
+        str->append(reproducer_path);
+        llvm::sys::AddSignalHandler(reproducer_handler,
----------------
I guess this won't work if there are spaces anywhere in the path..


================
Comment at: lldb/tools/driver/Options.td:235
   HelpText<"Tells the debugger to replay a reproducer from <filename>.">;
+def reproducer_finalize: Separate<["--", "-"], "reproducer-finalize">,
+  MetaVarName<"<filename>">,
----------------
Should this be a hidden argument?


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D89600/new/

https://reviews.llvm.org/D89600