Re: [boost] [Stacktrace] review, please stop discussing non-Stacktrace issues

Subject: Re: [boost] [Stacktrace] review, please stop discussing non-Stacktrace issues
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2016-12-19 17:11:25

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/