On 16/05/2025 16:43, Takashi Yano wrote:
Hi Jon,
[...]
I could reproduce that. And also found cygwin 3.4.10 does not have this
issue. I'll look into this.
I could bisect the issue and found the next commit triggered the issue.
commit 91457377d6c9f89a08b1b70e45cbae87ef467119
Author: Jon Turney <jon.tur...@dronecode.org.uk>
Date: Thu Jan 11 20:00:14 2024 +0000
[...]
Thanks for looking into this.
I also found the following patch fixes the issue. I'm not sure
this is the right thing, so could you please have a look?
diff --git a/winsup/cygwin/exceptions.cc b/winsup/cygwin/exceptions.cc
index 9763a1b04..aea2821f6 100644
--- a/winsup/cygwin/exceptions.cc
+++ b/winsup/cygwin/exceptions.cc
@@ -597,7 +597,7 @@ try_to_debug ()
{
extern void break_here ();
break_here ();
- return 1;
+ return 0;
}
/* Otherwise, invoke the JIT debugger, if set */
Hmm... at this remove in time, I'm not sure why I made that change.
Well, "consistently return non-zero from try_to_debug() if we debugged",
but maybe that misunderstands the meaning of the return value...
(I'm not sure what the pure bafflegab at the end of exception::handle()
does to make things work differently, we exit with
ExceptionContinueExecution in both cases.)
I think this is similar to/related to the problem [1], which I
unfortunately never got around to investigating properly.
I think perhaps we should probably also restore the behavior of not
trying to break_here() (==DebugBreak()) if no JIT debugger is
configured. (i.e. try_to_debug() should just immediately return 0, if
debugger_command is NULL).
(This would seem to make try_to_debug() less useful, as it then does
nothing if you're just run under gdb, but it's what the code used to do...)
I'll put together a patch tomorrow.
[1] https://cygwin.com/pipermail/cygwin/2024-May/256058.html
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation: https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
