Re: [Monotone-devel] Okay I'm tired of exception when aborting windows mtn command...
On Sat, May 8, 2010 at 11:09, Timothy Brownawell tbrow...@prjek.net wrote: On 05/03/2010 01:29 PM, Daniel Atallah wrote: Initially, it looked like this was working nicely and the annoying crash message no longer appeared when Ctrl+C was issued. However, it looks like the fix for this has an (at least in my view) undesirable side effect. I frequently run something like mtn commit file1 file2 mtn push, and the the first command tends to be what I cancel (e.g. if I realize while writing the commit message that I need to add additional files, etc). Previously, when the first command was canceled, the exit value was non-zero and the second command didn't run. Now, the first command is indicating successful completion despite the operation canceled: user interrupt message, and the second command runs. I can't think of a use case where this wold be the desired behavior (perhaps I'm missing something). Oops, this should be fixed in 8b38c089e7a11ef78e4ebb332b5d7d8c5cfb0eea. Sorry about that. Thanks for the quick fix. -D ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Okay I'm tired of exception when aborting windows mtn command...
On 05/03/2010 01:29 PM, Daniel Atallah wrote: Initially, it looked like this was working nicely and the annoying crash message no longer appeared when Ctrl+C was issued. However, it looks like the fix for this has an (at least in my view) undesirable side effect. I frequently run something like mtn commit file1 file2 mtn push, and the the first command tends to be what I cancel (e.g. if I realize while writing the commit message that I need to add additional files, etc). Previously, when the first command was canceled, the exit value was non-zero and the second command didn't run. Now, the first command is indicating successful completion despite the operation canceled: user interrupt message, and the second command runs. I can't think of a use case where this wold be the desired behavior (perhaps I'm missing something). Oops, this should be fixed in 8b38c089e7a11ef78e4ebb332b5d7d8c5cfb0eea. Sorry about that. -- Timothy Free public monotone hosting: http://mtn-host.prjek.net ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Okay I'm tired of exception when aborting windows mtn command...
On Thu, Mar 4, 2010 at 09:51, Timothy Brownawell tbrow...@prjek.net wrote: Timothy Brownawell wrote: 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. This is committed now, so it should be in the next release. I was pleased to see a fix for this go into 0.47 and I got around to upgrading my Windows box to that version this morning. Initially, it looked like this was working nicely and the annoying crash message no longer appeared when Ctrl+C was issued. However, it looks like the fix for this has an (at least in my view) undesirable side effect. I frequently run something like mtn commit file1 file2 mtn push, and the the first command tends to be what I cancel (e.g. if I realize while writing the commit message that I need to add additional files, etc). Previously, when the first command was canceled, the exit value was non-zero and the second command didn't run. Now, the first command is indicating successful completion despite the operation canceled: user interrupt message, and the second command runs. I can't think of a use case where this wold be the desired behavior (perhaps I'm missing something). Sorry for bringing this back up. Thanks, -Daniel ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Okay I'm tired of exception when aborting windows mtn command...
Timothy Brownawell wrote: 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. This is committed now, so it should be in the next release. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Okay I'm tired of exception when aborting windows mtn command...
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? On Tue, Mar 2, 2010 at 12:43 PM, Timothy Brownawell tbrow...@prjek.net 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. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Okay I'm tired of exception when aborting windows mtn command...
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 tbrow...@prjek.net 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. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Okay I'm tired of exception when aborting windows mtn command...
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! If I start a mtn log (that's too long) or mtn commit, and relaize I messed up the message, or a sync, and realize there was another commit I wanted... I often halt a montone op with ctrl-c ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Okay I'm tired of exception when aborting windows mtn command...
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). And since my PC is 6 years old and my Windows is in a VM, I don't particularly feel like trying to debug this until I get a new computer (currently thinking early next year). ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
