On Sunday, 4 May 2025 at 06:18:28 UTC, Richard (Rikki) Andrew Cattermole wrote:
> On 04/05/2025 5:40 PM, Timon Gehr wrote:
>> The whole: "We really need to make sure people cannot get any information out of a failing process unless they run the program from the command line and then we need to make sure nothing but a stack trace will escape unless we are running in a debugger" is simply not workable. I don't understand what you are chasing in this instance, but it is not utility. It almost seems like your only experience with remote crashes is those that happen frequently and repeatably, and within a terminal.
>
> This may be where you need to emphasize that you are talking from a users perspective, not a language developer.
>
> Based upon your other comments, its resulting in some severe problems for you.

Of course the problem isn't unique to Timon; it hits everybody doing anything remotely usable.

It is the equivalent of a program crashing and showing an unhelpful dialog saying: "The program crashed.". The response is an universal one, along the lines of "Thank you for telling me that, it didn't occur to me."

The minimum acceptable response is a dialog with opt-out sending of crash report. For CLI programs you have more leeway though.

On Sunday, 4 May 2025 at 01:19:53 UTC, Walter Bright wrote:

>
> As for real mode, that's 16 bit architecture which D does not (officially) support.

In 32-bit MCUs, the region near 0 is usually mapped to flash memory and often left unprotected for reads (where "often" means "I have no idea how often exactly").

On Sunday, 4 May 2025 at 04:49:48 UTC, Timon Gehr wrote:
>
> My understanding is that null pointer dereference being UB is a widespread assumption in the LLVM and GCC optimizers. Simply "disabling the behavior" is not practical.


I recently read somewhere, (not sure if it was in these forums, Hacker News, or Lobsters), that recent versions of LLVM have now gained the ability to express that some forms of pointer will not experience that behaviour.

i.e. something in the syntax (text form, and presumably bitcode) allows one to indicate that dereference of a NULL pointer is not to be viewed as undefined behaviour, and so it most not optimise on the assumption that it is.

I assume that means a attempt to deref a NULL reference will then end up being passed to the actual CPU in terms of code generated.

I suspect this may only be the most recent version, possibly the pre-release development HEAD.  I have no idea about any equivalent in the GCC middle and back ends.

On Sunday, 4 May 2025 at 06:55:02 UTC, Sebastiaan Koppe wrote:
> The minimum acceptable response is a dialog with opt-out sending of crash report. For CLI programs you have more leeway though.

Somehow UB is not a problem for C++ in this case https://mpc-hc.org/crash-reporter/

On 5/4/25 12:24, Derek Fawcus wrote:
> 
> I suspect this may only be the most recent version, possibly the pre- release development HEAD.  I have no idea about any equivalent in the GCC middle and back ends.

Thanks! Found what you are talking about: https://releases.llvm.org/10.0.0/docs/LangRef.html#id1105

Look for: "null-pointer-is-valid"

This means that Walter's suggestion to LDC developers to disable the UB on null pointer deref seems in fact to be practical if they add this attribute on all functions. I don't think something like this exists in GCC though.

This does not change the main point of contention though, which is that error reporting should be in the hands of the developer as much as possible and moving further and further in the direction of taking that kind of control away is a tragedy.

On 5/4/25 08:18, Richard (Rikki) Andrew Cattermole wrote:
> On 04/05/2025 5:40 PM, Timon Gehr wrote:
>> The whole: "We really need to make sure people cannot get any information out of a failing process unless they run the program from the command line and then we need to make sure nothing but a stack trace will escape unless we are running in a debugger" is simply not workable. I don't understand what you are chasing in this instance, but it is not utility. It almost seems like your only experience with remote crashes is those that happen frequently and repeatably, and within a terminal.
> 
> This may be where you need to emphasize that you are talking from a users perspective, not a language developer.
> ...

I am talking from the perspective of a language developer, I just happen to actually have also made bad experiences as a user in practice. Note that often I lay out a theoretical argument, it is ignored, and a few years down the line there are actual users complaining about their practical experience. It just seems not everyone is drawing the connection between the two.

I don't really like the dynamic where if I lay out the theoretical argument people ask for examples, and if I provide examples from my own experience, that experience is discounted as somehow being irrelevant in the fashion of "you are holding it wrong".

I am sure there is some workaround that will allow me to get more information from that user, perhaps I can redirect stderr to a file to at least get a stack trace, perhaps not. I will not know whether that works until the crash happens again (and I am actually informed that it happened). There being more cases that behave like this means there is less to go on. For all I know there is a seg fault within a C dependency, or it could just be D working against me. Just vastly lowering the likelihood that D is the culprit would already help me isolate the issue.

> Based upon your other comments, its resulting in some severe problems for you.
> 

Well, Windows users are used to unexplained software failures, and I don't know whether a null deference is even the culprit in this case. I don't know anything about this particular crash, as it is so rare.

The point is that Walter seems to be moving in the direction of creating even more cases where I would not be able to get any information back from normie Windows users, while still not acknowledging that segfaults are useless and unworkable in practically relevant cases.

On 5/3/2025 9:49 PM, Timon Gehr wrote:
> For the record, even if my application would not run very sluggishly when compiled with DMD, in this particular case it does not matter how accurate the segfault location is as I am not getting any information in the first place.

You suggested in another reply that I no experience debugging programs that do not have a tty attached. This is incorrect. When I've had programs "wink out" leaving no trail nor context behind, I add logging code. In particular, I add a line to the entry of key functions, something like `fprintf(log, "function name\n");` which appends to a log file. Examining the log file gives clues as to where the program was when it failed and a trail how it got there. I add more logging statements as needed to gradually close in to where the fault is.


> My understanding is that null pointer dereference being UB is a widespread assumption in the LLVM and GCC optimizers. Simply "disabling the behavior" is not practical.

It may be dependent on the optimization level.

There are all kinds of UB behavior that the LLVM and GCC optimizers just delete because, hey, it's undefined behavior that will never happen so it can be just deleted. Things like `(x + 1 > x)` being replaced with `1`. There's a way for the compiler to emit a warning when this is done, perhaps try that?

The compiler's ability to check at compile time for a null pointer dereference (and hence delete it) is extremely limited. It relies on data flow analysis where it can prove the pointer is null, not just "it might be". I read that compilers issue a warning when this is the case. Why not try `p = null; `*p = 3;` in your setup and see if the compiler you're using gives a warning?

If it does, but the warning does not happen with your code, then you know the compiler is not deleting the reference, and so the CPU will check it and seg fault it at runtime.


> Perhaps I could add `-fsanitize=null` to add null checks, but that would not really solve the main problem as it is not integrated with D scope guards.

It would at least tell you if it is a null pointer dereference or not. That in itself would be valuable information.

I have no idea what your program does, but I suspect your most practical option is to add logging to a file, and ask your customer to email the file to you when it crashes.

Another thing you can try is build your program with dmd and see if it behaves differently regarding the mysterious crash.

On 5/4/2025 8:43 AM, Timon Gehr wrote:
> The point is that Walter seems to be moving in the direction of creating even more cases where I would not be able to get any information back from normie Windows users,

I replied to you already: "I had no idea anyone was using it for that purpose. I guess I can't change that :-)"

Besides, you could still use `try ... catch (Error e)` instead of `scope(failure)`. After all, the `scope` construct literally is just rewritten as try...catch or try...finally.


> while still not acknowledging that segfaults are useless and unworkable in practically relevant cases.

Worst case, you can write a signal handler for any of the signals that can be generated (not just null pointer signals), and have the handler write all it can to a file that can be emailed to you.

You can also hook atexit() as maybe your program is exiting that way.

Have you considered it might be a stack overflow?