Re: Throw stack trace from program kill

2022-01-19 Thread Hipreme via Digitalmars-d-learn
On Sunday, 16 January 2022 at 18:03:53 UTC, Paul Backus wrote: On Sunday, 16 January 2022 at 15:15:07 UTC, Hipreme wrote: Is there some way to throw a stack trace when killing the program from the CTRL+C from the terminal? It would help a lot into debugging occasional infinity loops On POSIX

Re: Throw stack trace from program kill

2022-01-16 Thread Era Scarecrow via Digitalmars-d-learn
On Sunday, 16 January 2022 at 18:03:53 UTC, Paul Backus wrote: On POSIX, you can use the `sigaction` function to install a signal handler for `SIGINT`, the signal generated by CTRL+C. To terminate the program with a stack trace, simply have the signal handler `throw` an `Error`. I never quit

Re: Throw stack trace from program kill

2022-01-16 Thread H. S. Teoh via Digitalmars-d-learn
On Sun, Jan 16, 2022 at 01:42:21PM -0500, Steven Schveighoffer via Digitalmars-d-learn wrote: > On 1/16/22 1:33 PM, Paul Backus wrote: [...] > > ```d > > extern(C) void handleCtrlC(int) > > { > > import core.stdc.stdlib: exit; > > import std.stdio: writeln; > > > > try throw new Ex

Re: Throw stack trace from program kill

2022-01-16 Thread Steven Schveighoffer via Digitalmars-d-learn
On 1/16/22 1:33 PM, Paul Backus wrote: It worked when I tested it, Yeah, but your example is designed specifically to only encounter the signal in one specific spot (inside a D function). but I'm not sure how reliable it is. A more conservative implementation would be something like ```d

Re: Throw stack trace from program kill

2022-01-16 Thread Steven Schveighoffer via Digitalmars-d-learn
On 1/16/22 1:42 PM, Steven Schveighoffer wrote: This too is not going to be a good idea. writeln(e.info) is going to possibly start allocating. A signal can come at any time, even when locks are held or things are in an intermediate state. That being said, if this is being used for debugging,

Re: Throw stack trace from program kill

2022-01-16 Thread Paul Backus via Digitalmars-d-learn
On Sunday, 16 January 2022 at 18:22:04 UTC, Steven Schveighoffer wrote: Does this work normally? The memory error handler for Linux jumps through a lot of hoops to be able to throw an error from a signal handler. See https://github.com/dlang/druntime/blob/master/src/etc/linux/memoryerror.d

Re: Throw stack trace from program kill

2022-01-16 Thread Adam D Ruppe via Digitalmars-d-learn
On Sunday, 16 January 2022 at 18:03:53 UTC, Paul Backus wrote: extern(C) void handleCtrlC(int) { throw new Error("Killed by CTRL+C"); } This is really iffy since signals can come to random threads at random times. The best thing to do is typically to just set a "user requested quit"

Re: Throw stack trace from program kill

2022-01-16 Thread Steven Schveighoffer via Digitalmars-d-learn
On 1/16/22 1:03 PM, Paul Backus wrote: On Sunday, 16 January 2022 at 15:15:07 UTC, Hipreme wrote: Is there some way to throw a stack trace when killing the program from the CTRL+C from the terminal? It would help a lot into debugging occasional infinity loops On POSIX, you can use the `sigac

Re: Throw stack trace from program kill

2022-01-16 Thread Paul Backus via Digitalmars-d-learn
On Sunday, 16 January 2022 at 15:15:07 UTC, Hipreme wrote: Is there some way to throw a stack trace when killing the program from the CTRL+C from the terminal? It would help a lot into debugging occasional infinity loops On POSIX, you can use the `sigaction` function to install a signal hand

Re: Throw stack trace from program kill

2022-01-16 Thread Ali Çehreli via Digitalmars-d-learn
On 1/16/22 07:15, Hipreme wrote: > Is there some way to throw a stack trace when killing the program from > the CTRL+C from the terminal? I am interested in how to add Ctrl+C support for a D program as well. > It would help a lot into debugging occasional infinity loops One way of achieving tha

Throw stack trace from program kill

2022-01-16 Thread Hipreme via Digitalmars-d-learn
Is there some way to throw a stack trace when killing the program from the CTRL+C from the terminal? It would help a lot into debugging occasional infinity loops