Re: [Monotone-devel] Okay I'm tired of exception when aborting windows mtn command...

[Timothy Brownawell]

J Decker wrote:
> ExitProcess invokes things like static class destructors, and atexit()
> registered code.  Terminate process ends the process immediately.
> Probably the default break handler calls ExitProcess... and don't you
> mean a break handler that returns TRUE so it doesn't segfault?

The issue with returning TRUE is that it would do nothing when run from 
cmd.exe, and is supposed to do nothing.

Whatever it does needs to end up with the monotone process exiting, and 
preferable in a way that's independent of how monotone was started. But, 
the only things that exit consistently (which are also the things that 
are supposed to exit) are making sure ExitProcess() is called (which 
always seems to segfault), or calling TerminateProcess() (which comes 
with warnings about doing horrible things to your DLLs).

Hm, maybe calling TerminateProcess() would be the better choice. The 
warning is "The state of global data maintained by dynamic-link 
libraries (DLLs) may be compromised if TerminateProcess is used rather 
than ExitProcess.", and since none of our shared libraries are for IPC 
I'd guess they don't use shared memory so we don't have to actually 
care. This would I think also be consistent with not calling exit() from 
our unix SIGINT handler, but just re-raising it after printing a nice 
message.

> On Tue, Mar 2, 2010 at 12:43 PM, Timothy Brownawell <address@hidden> wrote:
> > Way back in October, Timothy Brownawell wrote:
> > > J Decker wrote:
> > > > When I abort an operation in monotone for windows, an exception is
> > > > generated.  I have tolerated this since version 0.26... but... no I'm
> > > > tried of having to wait for the exception handler to log the
> > > > exception... y'all should implement
> > > >
> > > > SetConsoleCtrlHandler
> > > >
> > > > and handle exiting nicely instead of blowing up.  PLEASE!
> > > Patches welcome?
> > >
> > > I've tried this before, but IIRC calling ExitProcess() from the handler
> > > would still segfault (I also think I recall trying TerminateProcess()
> > > with the same result, but that doesn't seem to make sense).
> > Without a ctrl handler (how things are now), ^C causes a segfault.
> >
> > With a ctrl handler that returns FALSE (makes it call the default handler),
> > it segfaults.
> >
> > With a ctrl handler that calls ExitProcess(), it segfaults.
> >
> > With a ctrl handler that returns TRUE (don't call the next handler), it
> > *exits*.
> >
> > With a ctrl handler that calls TerminateProcess(), it exits.
> >
> > If I run from cmd.exe instead of the msys shell...
> >        returning FALSE segfaults
> >        returning TRUE does nothing (like it should)
> >
> >
> >
> > So... maybe we should have a ctrl handler that returns FALSE after setting a
> > flag to make the segfault handler print a less dire message? I'm not sure
> > how to make sense of what it's doing.