On 19 Dec 2016 at 23:14, Andrey Semashev wrote:
I think, a process could also modify the system-wide PATH variable, at least on some Windows versions. IIRC, some installers (Visual Studio? Intel compiler? I can't remember) did that at some point. I don't know if that's the case now.
You need root for that.
But installers always execute as root on Windows, don't they? (I believe, the term is "with elevated privileges") The idea is that the user installed something that modified system PATH so that it can later be used to inject a malicious process into your application.
I think we're getting onto non-Stacktrace review topics once more. Again, I have no problem with discussion being moved to a thread not entitled "Stacktrace review".
In fact, if your process has just crashed, it's better to do the work from another process, because its memory would be intact.
That is true, but I reiterate that handling a crash (or a signal) is special enough to warrant a special solution. At this point performance doesn't really matter, and the host process is pretty much doomed anyway, so the issues affecting its survival are off the table.
There are long established, high quality open source crash reporter libraries and why anyone would roll their own solution instead of just using one of those would be beyond me. I've used CrashRpt in years gone by and it worked great. On Windows for years you've been able to manually generate a dump file by calling MinidumpWriteDump() but the big gotcha is you need to launch a separate process to call it on your crashed process. One evil way to achieve this is via Powershell bundled with Windows since Win7 which can dump your process for you. Back to Stacktrace. I think I am beginning to see a consensus emerge: that Stacktrace should be able to serialise the stacktrace of an about to be terminated process to disc in an async-safe way in a format which other tooling such as addr2line or llvm-symbolizer can consume in combination with the debug symbols to produce an accurate source and line number stacktrace. Stacktrace does not need to parse the stacktrace in an async-safe way. Is this consensus acceptable to the Boost community? If so, Stacktrace would need to figure out the load address of each DLL/SO/EXE after ASLR and convert the stacktrace pointers into offsets before writing them in text to a file without using any CRT functions nor malloc for llvm-symbolizer to consume. It's a big ask from Antony though doable, this is why I am asking if this is what the Boost community wants as a precondition, or is it too much of an ask, or not enough? Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/