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?
-- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk