This is the mail archive of the
mailing list for the Cygwin project.
Cygwin, gdb and SEH [was RE: 1.5.19: changes have broken Qt3]
- From: "Dave Korn" <dave dot korn at artimi dot com>
- To: <cygwin at cygwin dot com>
- Date: Wed, 24 May 2006 19:06:32 +0100
- Subject: Cygwin, gdb and SEH [was RE: 1.5.19: changes have broken Qt3]
On 24 May 2006 17:13, Ralf Habacker wrote:
> Brian Dessent schrieb:
>> Ralf Habacker wrote:
>> And yes, it used to be that gdb was too dumb to recognise that these
>> faults in IsBadReadPtr were not actual faults, and it would print them
>> as spurious SIGSEGVs, just as it currently does for "myfault"s. Then it
>> was patched to ignore faults in kernel32.dll. Now that the handler is
>> in cygwin1.dll, it had to be taught to ignore faults there too, and if
>> you use a CVS GDB, it does.
> This kind of exceptions are handled complete in cygwin itself. Is there
> no way to limit this exceptions to the cygwin library itself and to hide
> them to the rest ?
<smacks forehead> I'm going to have to start shouting now, because you
clearly can't hear or aren't listening to anything that's being said.
YES, THERE IS A WAY!
WHAT IS MORE YOU HAVE ALREADY HAD IT EXPLAINED TO YOU A DOZEN TIMES IN THIS
THE WAY IS TO USE AN UP-TO-DATE GDB!
<takes deep breath>
You have everything back to front. The problem is not for cygwin to hide
these exceptions from gdb; the problem is for gdb not to jump in ahead of
cygwin and intercept them. *That* is why fixing gdb is the right thing.
> This way exceptions are handled looks to me like a specific
> implementation detail, which will worry users more than that it helps to
> find problems in an application.
Yes, that is why GDB has been patched. However, there is no way on earth
that an old out-of-date gdb could know about some trick that was only
introduced into the cygwin source years later. We aim for backward
compatibility, forward is trickier.
> You may say to, this has to be done by gdb, but what about strace ? Do I
> need to run strace through gdb to avoid such exception messages ? Or
> will strace be patched too to hide such messages ?
Learn to use "grep -v" or RTFM about the --mask option to strace. The fact
that *you* do not want to see these messages does not mean they are not useful
> Remember the previously listed examples where those messages occupies
> about 70% of the whole output of an straced application.
If you attempt to misuse strace as a tool for debugging your applications,
you will run into this kind of problem, and it will be your fault. RTFM:
quite clearly states "This program is mainly useful for debugging the Cygwin
> Because this exception addresses are located in the cygwin dll it will
> produce many, many obsolate support requests to the cygwin mailing list
> (as I was faced)
See, this is the *real* problem: you read an obscure internal debugging
message emitted by what is effectively a kernel debugging tool, but then you
just guessed at what it signified, instead of finding out. The leap to the
false conclusion was yours.
> and will stresses the support people instead that they
LOL! What support people? There are none.
> can give support for the real problems and will eat time from the
You appear to be under the same misunderstanding as the guy from yesterday
who thought cygwin might have a use for "market research". There is no
company, no support team, and any developers whose employers might assign them
to work on anything related to cygwin are under no obligation to work on other
> And what about the usage of other windows debuggers ? Does they have
> also such specific exception hiding support ? If not will there be a
> manual how to disable this internal messages ?
Cygwin does not support the use of "other" debuggers. Cygwin is based
around the GNU toolchain. We do not attempt compatibility with MSVC or
> As summary, I don't think that patching gdb is the best solution.
However your conclusions are based on a faulty understanding of the
> would be better to limit these exception to the cygwin dll and to hide
> this message to the rest.
The issue is not "limiting" the exceptions, which are already and always
have been innately limited by their very nature; nothing further up the stack
than the SEH handler frame will ever know the slightest thing about them. It
is only when a *DEBUGGER* is controlling the flow of the program that it is
even *possible* for anything to get in there ahead of the standard win32
exception handling mechanism that cygwin is already using to do what you ask.
I recommend you do not post to this thread again until you have read
1) The cygwin user guide
2) The cygwin FAQ
3) The MSDN documentation about __try ... __except
3) Matt Pietrek's classic article from MSJ '97 about the internals of SEH.
because you're just repeating yourself now.
Can't think of a witty .sigline today....
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html