On 11/6/14 10:22 PM, ketmar via Digitalmars-d-learn wrote:
> On Thu, 06 Nov 2014 20:13:02 +0000
> "Nordlöw" via Digitalmars-d-learn <digitalmars-d-learn@puremagic.com>
> wrote:
>
>> On Wednesday, 5 November 2014 at 11:39:21 UTC, Marc Schütz wrote:
>>> If you're on Linux, you can turn SEGVs into Errors:
>>>
>>>      import etc.linux.memoryerror;
>>>      registerMemoryErrorHandler();
>>
>> Why isn't such a useful feature activated by default? Performance
>> reasons?
> 'cause it's not really that useful. uncaught (by the proper checks)
> segmentation fault is the serious bug, program must crach and spit out
> postmortem dump

In an environment that you don't control, the default behavior is likely to print "Segmentation Fault" and exit. No core dump, no nothing.

This leads to unhelpful bug reports, and seeing if you can get your client to "try to make it happen again with this debug build, or with the shell set up to make a core dump".

I think it would be nice to be able to check if a core dump is enabled, and if not, register the handler by default.

-Steve

On Thu, 06 Nov 2014 22:45:23 -0500
Steven Schveighoffer via Digitalmars-d-learn
<digitalmars-d-learn@puremagic.com> wrote:

> In an environment that you don't control, the default behavior is likely to print "Segmentation Fault" and exit. No core dump, no nothing.
> 
> This leads to unhelpful bug reports, and seeing if you can get your client to "try to make it happen again with this debug build, or with the shell set up to make a core dump".

README file, prerequisites: "please, turn on coredump feature if you plan to send bug reports. thank you."

btw, that's why i'm against so-called "release builds" with debug features not only turned off, but not compiled at all. every build must be "release build", and no debug features should be ommited. when i stopped to making "debug builds" and started to pass my clients the same builds i'm using as developer, things becomes much easier.

On 11/6/14 11:43 PM, ketmar via Digitalmars-d-learn wrote:
> On Thu, 06 Nov 2014 22:45:23 -0500
> Steven Schveighoffer via Digitalmars-d-learn
> <digitalmars-d-learn@puremagic.com> wrote:
>
>> In an environment that you don't control, the default behavior is likely
>> to print "Segmentation Fault" and exit. No core dump, no nothing.
>>
>> This leads to unhelpful bug reports, and seeing if you can get your
>> client to "try to make it happen again with this debug build, or with
>> the shell set up to make a core dump".
>
> README file, prerequisites: "please, turn on coredump feature if you
> plan to send bug reports. thank you."

This doesn't help. We must live in the real world with real customers :)

-Steve

On Friday, 7 November 2014 at 03:22:59 UTC, ketmar via Digitalmars-d-learn wrote:
> crash+coredump is alot more useful than intercepting error and...
> trying to recover from undefined state? or just exit to OS, losing
> valuable information about a crash?

Together with the DUB package backtrace this gives really nice default behaviour printing stacktrace where memory fault occurred.

For details see my show case at:
https://github.com/nordlow/justd/blob/master/t_errorHandler.d

On Fri, 07 Nov 2014 08:49:34 -0500
Steven Schveighoffer via Digitalmars-d-learn
<digitalmars-d-learn@puremagic.com> wrote:

> On 11/6/14 11:43 PM, ketmar via Digitalmars-d-learn wrote:
> > On Thu, 06 Nov 2014 22:45:23 -0500
> > Steven Schveighoffer via Digitalmars-d-learn
> > <digitalmars-d-learn@puremagic.com> wrote:
> >
> >> In an environment that you don't control, the default behavior is likely to print "Segmentation Fault" and exit. No core dump, no nothing.
> >>
> >> This leads to unhelpful bug reports, and seeing if you can get your client to "try to make it happen again with this debug build, or with the shell set up to make a core dump".
> >
> > README file, prerequisites: "please, turn on coredump feature if you plan to send bug reports. thank you."
> 
> This doesn't help. We must live in the real world with real customers :)
i do. this really helps when clients wants their problem to be solved.
and if they doesn't, it's sufficient to answer like "thank you for your
report, we are working on it" (and then dumping that "report"
to /dev/null). this works perfectly.

On Fri, 07 Nov 2014 13:52:33 +0000
"Nordlöw" via Digitalmars-d-learn <digitalmars-d-learn@puremagic.com>
wrote:

> On Friday, 7 November 2014 at 03:22:59 UTC, ketmar via Digitalmars-d-learn wrote:
> > crash+coredump is alot more useful than intercepting error
> > and...
> > trying to recover from undefined state? or just exit to OS,
> > losing
> > valuable information about a crash?
> 
> Together with the DUB package backtrace this gives really nice default behaviour printing stacktrace where memory fault occurred.
> 
> For details see my show case at: https://github.com/nordlow/justd/blob/master/t_errorHandler.d
but i don't want stacktrace! i want coredump, so i can inspect the program, it's variables and it's internal state. i want to know *how* *exactly* program manages to shot itself in the foot.

easily catchable segfaults are not surviving testing. and if segfault survives, most of the time it's not enough to get stack trace, i need to fire gdb with coredump and try to understand what the hell is going on there.

i also developed a habit of writing assert()s before dereferencing
pointers first time (including class refs) in appropriate places, so
i'll got that stack trace for free. ;-) and i never turning off that
asserts in "release builds".

> i also developed a habit of writing assert()s before dereferencing
> pointers first time (including class refs) in appropriate places, so
> i'll got that stack trace for free. ;-) and i never turning off that
> asserts in "release builds".

About null pointer deref & core dump

I think, it is problem. Dland on windows gives stacktrace without any problem. In general it is expected behavior for many people from different languages (Java, C#). So from my point of view it is bad idea has core dump for null deref in linux by default.

As I remember current linux handler is dirty hack, and it is main reason why it is disabled by default.

On Fri, 07 Nov 2014 13:52:33 +0000
"Nordlöw" via Digitalmars-d-learn <digitalmars-d-learn@puremagic.com>
wrote:

> On Friday, 7 November 2014 at 03:22:59 UTC, ketmar via Digitalmars-d-learn wrote:
> > crash+coredump is alot more useful than intercepting error
> > and...
> > trying to recover from undefined state? or just exit to OS,
> > losing
> > valuable information about a crash?
> 
> Together with the DUB package backtrace this gives really nice
...undefined behavior. this code is not only unsafe (even in perverted D "safety"), it's plainly wrong. you are not allowed to call most of the libc functions from signal handler. actually, the things you can do safely in signal handler is setting some variable or calling _exit(2). ok, there are some more syscalls which are safe, but obviously not FILE* i/o from libc.

so it doesn't matter wether i want coredumps or you want stack traces, the only correct solution is coredumps. printing stack trace from signal handler is UB, and it works only by accident. there is no good in using code that relies on UB.

On Sat, 08 Nov 2014 06:23:39 +0000
Nikolay via Digitalmars-d-learn <digitalmars-d-learn@puremagic.com>
wrote:

> I think, it is problem. Dland on windows gives stacktrace without any problem. In general it is expected behavior for many people from different languages (Java, C#). So from my point of view it is bad idea has core dump for null deref in linux by default.
this is the only choice. invoking file i/o from signal handler is UB.

On Sat, Nov 08, 2014 at 08:50:20AM +0200, ketmar via Digitalmars-d-learn wrote:
> On Fri, 07 Nov 2014 13:52:33 +0000
> "Nordlöw" via Digitalmars-d-learn <digitalmars-d-learn@puremagic.com>
> wrote:
> 
> > On Friday, 7 November 2014 at 03:22:59 UTC, ketmar via Digitalmars-d-learn wrote:
> > > crash+coredump is alot more useful than intercepting error and... trying to recover from undefined state? or just exit to OS, losing valuable information about a crash?
> > 
> > Together with the DUB package backtrace this gives really nice
> ...undefined behavior. this code is not only unsafe (even in perverted D "safety"), it's plainly wrong. you are not allowed to call most of the libc functions from signal handler. actually, the things you can do safely in signal handler is setting some variable or calling _exit(2).  ok, there are some more syscalls which are safe, but obviously not FILE* i/o from libc.
> 
> so it doesn't matter wether i want coredumps or you want stack traces, the only correct solution is coredumps. printing stack trace from signal handler is UB, and it works only by accident. there is no good in using code that relies on UB.

Some time ago deadalnix gave a neat (if scary) hack where the signal handler overwrites its return address on the stack to redirect the code to a handler that operates outside signal handler context, so it has no restrictions on syscalls that it can use. Since by the time control passes to that handler, the "official" signal handler has returned, you can do whatever you want without running into UB. (Of course, overwriting return addresses on the stack arguably qualifies as UB, but hey, when a man is desperate...)


T

-- 
"Real programmers can write assembly code in any language. :-)" -- Larry Wall