Re: gdb under emacs is now aborting
On Tue, Apr 27, 2021 at 3:14 PM Takashi Yano wrote: > On Tue, 27 Apr 2021 09:58:01 -0400 > "William M. \(Mike\) Miller via Cygwin" wrote: > > I refreshed my Cygwin installation over the weekend, and ever since I > have > > not been able to run gdb under emacs as I previously had done. I use M-x > > gdb to start the gud interface, and as soon as I enter the "run" > command, I > > get a message saying either "Debugger aborted (core dumped)" or a similar > > message reporting a segmentation violation in the debugger. > > Could you please try latest snapshot? > https://cygwin.com/snapshots/ Yes, it works again using the latest snapshot. Thank you for the suggestion. -- William M. (Mike) Miller | Edison Design Group william.m.mil...@gmail.com -- 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
Re: Failed assertion dialog box
On Sun, Nov 15, 2020 at 3:39 PM André Bleau via Cygwin wrote: > > On Sat, Nov 14, 2020 at 11:49 PM Duncan Roe > wrote: > > ... > > > > > Sorry, should have mentioned running on Win7 Home. > > > > When I try it on my wife's Win10 system, I get the dialog box same as > you. > > > > That's disappointing. Thanks for the additional information, though. > > --- > > I would say we got some useful info: > 1- The bug is OS specific; it occurs in Windows 10 > 2- Three persons were able to reproduce it on Windows 10, which improves > the probability of getting fixed. > > - André Bleau > > --- > > Here's some more info: > > It seems the bug is related to pseudo-console support; that explains why > it is Windows 10 specific. > > Experiment: > > CYGWIN=disable_pcon /usr/bin/mintty & > > In the newly created window: > > $ ./a.exe output.txt 2>&1 > Aborted (core dumped) > > No message box popup. > > $ cat output.txt > assertion "false" failed: file "assert.cpp", line 3, function: int main() > > In the original mintty window, with empty CYGWIN env variable: > > $ ./a.exe output.txt 2>&1 > Aborted (core dumped) > > A message box pops > > AND: > > $ cat output.txt > > output.txt is empty > > So, 2 problems here. > > In a CMD Window: > > set path=%PATH%D:\Cygwin\bin; > a.exe outcmd.txt 2>&1 > 1 [main] a 759 cygwin_exception::open_stackdumpfile: Dumping stack > trace to a.exe.stackdump > type outcmd.txt > assertion "false" failed: file "assert.cpp", line 3, function: int main() > 1 [main] a 759 cygwin_exception::open_stackdumpfile: Dumping stack > trace to a.exe.stackdump > > The bug could be in cygwin or in mintty. Maybe this is something that > Thomas Wolff (mintty author) or Takashi Yano (pseudo-console support > expert) would want to look at. > That seems like useful information. However, my experience is a bit different; I get the popup regardless of whether the CYGWIN environment variable is empty or disable_pcon. However, I do see the same behavior as you with regard to mintty versus a command shell window, so I think that would argue in favor of mintty being responsible for popping up the dialog. Thanks for the information! -- William M. (Mike) Miller | Edison Design Group william.m.mil...@gmail.com -- 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
Re: Failed assertion dialog box
On Sat, Nov 14, 2020 at 11:49 PM Duncan Roe
wrote:
> On Fri, Nov 13, 2020 at 11:21:12PM -0500, cygwin wrote:
> > On Fri, Nov 13, 2020 at 10:45 PM Duncan Roe
> > wrote:
> >
> > > Hi William,
> > >
> > > On Fri, Nov 13, 2020 at 12:27:57PM -0500, cygwin wrote:
> > > > I've run into a problem running a collection of tests under Cygwin
> and I
> > > > wonder if anyone can suggest a way around it.
> > > >
> > > > The problem occurs when a program being run fails a C/C++ runtime
> > > > assertion. Ordinarily, this just writes an error message on stderr
> and
> > > > aborts. Under Cygwin, however, if both stdin and stderr are
> redirected to
> > > > files, the program instead pops up a dialog box that must be
> > > interactively
> > > > dismissed before the failed program will exit - holding up all the
> tests
> > > > that follow it.
> > > >
> > > > Specifically, if I have the following as assert.cpp:
> > > >
> > > > #include
> > > > int main() {
> > > > assert(false);
> > > > }
> > > >
> > > > and say
> > > >
> > > > gcc assert.cpp
> > > > ./a.exe < /dev/null > output 2>&1
> > > >
> > > > I get an error dialog box saying
> > > >
> > > > Failed assertion
> > > > false
> > > > at line 3 of file assert.cpp
> > > > in function int main()
> > > >
> > > > If I omit either the stdin or the stderr redirection, the program
> behaves
> > > > as desired with no dialog box.
> > > >
> > > > Is there an environment setting or compiler command-line option I can
> > > give
> > > > to suppress the dialog box and always just write a message to stderr
> and
> > > > abort? Thanks for any insights.
> > >
> > > Your example WFFM, (Cygwin64, gcc 10.2.0, everything else also up to
> date).
> > >
> > > Do you still see this behaviour if you run the installer?
> > >
> >
> > Thanks for your reply; unfortunately, yes, it does. I had refreshed
> > the installation fairly recently, and running the installer only updated
> a
> > few things, not cygwin.dll and not gcc; my installation is the same as
> > yours. I've tried it with three different shells (tcsh, bash, mksh) and
> > with both gcc and clang, and all have the same behavior. (Interestingly,
> if
> > I compile the example with MSVC and run it in a Cygwin shell, it does
> _not_
> > pop up an error dialog box, so presumably it's in the Cygwin runtime,
> > specifically the definition of __assert_func.)
>
> Sorry, should have mentioned running on Win7 Home.
>
> When I try it on my wife's Win10 system, I get the dialog box same as you.
>
That's disappointing. Thanks for the additional information, though.
--
William M. (Mike) Miller | Edison Design Group
william.m.mil...@gmail.com
--
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
Re: Failed assertion dialog box
On Sat, Nov 14, 2020 at 10:26 AM Lemures Lemniscati via Cygwin <
cygwin@cygwin.com> wrote:
> On Sat, 14 Nov 2020 09:12:11 -0500, William M. (Mike) Miller
> > On Sat, Nov 14, 2020 at 12:39 AM Lemures Lemniscati via Cygwin <
> > cygwin@cygwin.com> wrote:
> >
> > > On Sat, 14 Nov 2020 04:37:43 +, André Bleau via Cygwin
> > > >
> > > > On Fri, Nov 13, 2020 at 10:45 PM Duncan Roe
> > > > wrote:
> > > >
> > > > > Hi William,
> > > > >
> > > > > On Fri, Nov 13, 2020 at 12:27:57PM -0500, cygwin wrote:
> > > > > > I've run into a problem running a collection of tests under
> Cygwin
> > > and I
> > > > > > wonder if anyone can suggest a way around it.
> > > > > >
> > > > > > The problem occurs when a program being run fails a C/C++ runtime
> > > > > > assertion. Ordinarily, this just writes an error message on
> stderr
> > > and
> > > > > > aborts. Under Cygwin, however, if both stdin and stderr are
> > > redirected to
> > > > > > files, the program instead pops up a dialog box that must be
> > > > > interactively
> > > > > > dismissed before the failed program will exit - holding up all
> the
> > > tests
> > > > > > that follow it.
> > > > > >
> > > > > > Specifically, if I have the following as assert.cpp:
> > > > > >
> > > > > > #include
> > > > > > int main() {
> > > > > > assert(false);
> > > > > > }
> > > > > >
> > > > > > and say
> > > > > >
> > > > > > gcc assert.cpp
> > > > > > ./a.exe < /dev/null > output 2>&1
> > > > > >
> > > > > > I get an error dialog box saying
> > > > > >
> > > > > > Failed assertion
> > > > > > false
> > > > > > at line 3 of file assert.cpp
> > > > > > in function int main()
> > > > > >
> > > > > > If I omit either the stdin or the stderr redirection, the program
> > > behaves
> > > > > > as desired with no dialog box.
> > > > > >
> > > > > > Is there an environment setting or compiler command-line option
> I can
> > > > > give
> > > > > > to suppress the dialog box and always just write a message to
> stderr
> > > and
> > > > > > abort? Thanks for any insights.
> > > > >
> > > > > Your example WFFM, (Cygwin64, gcc 10.2.0, everything else also up
> to
> > > date).
> > > > >
> > > > > Do you still see this behaviour if you run the installer?
> > > > >
> > > >
> > > > Thanks for your reply; unfortunately, yes, it does. I had refreshed
> > > > the installation fairly recently, and running the installer only
> updated
> > > a
> > > > few things, not cygwin.dll and not gcc; my installation is the same
> as
> > > > yours. I've tried it with three different shells (tcsh, bash, mksh)
> and
> > > > with both gcc and clang, and all have the same behavior.
> (Interestingly,
> > > if
> > > > I compile the example with MSVC and run it in a Cygwin shell, it does
> > > _not_
> > > > pop up an error dialog box, so presumably it's in the Cygwin runtime,
> > > > specifically the definition of __assert_func.)
> > > >
> > > > I see the same behavior as William:
> > > >
> > > > ./a.exe < /dev/null > output.txt 2>&1
> > > > pops a message box.
> > > >
> > > > gcc (GCC) 10.2.0
> > > > CYGWIN_NT-10.0 XXX 3.1.7(0.340/5/3) 2020-08-22 17:48 x86_64 Cygwin
> > > > mintty 3.4.1 (x86_64-pc-cygwin)
> > > >
> > > > - André Bleau
> > >
> > > It works fine for me.
> > > Can you check 'gcc -M assert.cpp' ?
> > > My result is:
> > >
> > > $ gcc -M assert.cpp
> > > assert.o: assert.cpp /usr/include/assert.h /usr/include/_ansi.h \
> > > /usr/include/newlib.h /usr/include/_newlib_version.h \
> > > /usr/include/sys/config.h /usr/include/machine/ieeefp.h \
> > > /usr/include/sys/features.h /usr/include/cygwin/config.h
> > >
> >
> > Mine is identical. (Same for "uname -a" output, which André posted
> above.)
> >
> > The fact that you and André don't get a dialog box gives me hope that
> > there's something in the environment or installation that controls that
> > behavior. (Just to make certain, "works find for me" means that you ran
> the
> > executable, redirecting both stdin and stderror, and did not get an error
> > popup, right?)
>
> Sorry, I tested on a very old machine (CYGWIN_NT-6.1),
> on which no error popup occurred.
>
> But on Windows 10 (CYGWIN_NT-10.0), it does not work on Windows 10,
> and brings an error popup.
>
Ah, that makes sense; I was previously doing this testing on an older
machine (now defunct, so I can't check versions) and didn't have this
issue. Thanks for the update.
--
William M. (Mike) Miller | Edison Design Group
william.m.mil...@gmail.com
--
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
Re: Failed assertion dialog box
On Sat, Nov 14, 2020 at 12:39 AM Lemures Lemniscati via Cygwin <
cygwin@cygwin.com> wrote:
> On Sat, 14 Nov 2020 04:37:43 +, André Bleau via Cygwin
> >
> > On Fri, Nov 13, 2020 at 10:45 PM Duncan Roe
> > wrote:
> >
> > > Hi William,
> > >
> > > On Fri, Nov 13, 2020 at 12:27:57PM -0500, cygwin wrote:
> > > > I've run into a problem running a collection of tests under Cygwin
> and I
> > > > wonder if anyone can suggest a way around it.
> > > >
> > > > The problem occurs when a program being run fails a C/C++ runtime
> > > > assertion. Ordinarily, this just writes an error message on stderr
> and
> > > > aborts. Under Cygwin, however, if both stdin and stderr are
> redirected to
> > > > files, the program instead pops up a dialog box that must be
> > > interactively
> > > > dismissed before the failed program will exit - holding up all the
> tests
> > > > that follow it.
> > > >
> > > > Specifically, if I have the following as assert.cpp:
> > > >
> > > > #include
> > > > int main() {
> > > > assert(false);
> > > > }
> > > >
> > > > and say
> > > >
> > > > gcc assert.cpp
> > > > ./a.exe < /dev/null > output 2>&1
> > > >
> > > > I get an error dialog box saying
> > > >
> > > > Failed assertion
> > > > false
> > > > at line 3 of file assert.cpp
> > > > in function int main()
> > > >
> > > > If I omit either the stdin or the stderr redirection, the program
> behaves
> > > > as desired with no dialog box.
> > > >
> > > > Is there an environment setting or compiler command-line option I can
> > > give
> > > > to suppress the dialog box and always just write a message to stderr
> and
> > > > abort? Thanks for any insights.
> > >
> > > Your example WFFM, (Cygwin64, gcc 10.2.0, everything else also up to
> date).
> > >
> > > Do you still see this behaviour if you run the installer?
> > >
> >
> > Thanks for your reply; unfortunately, yes, it does. I had refreshed
> > the installation fairly recently, and running the installer only updated
> a
> > few things, not cygwin.dll and not gcc; my installation is the same as
> > yours. I've tried it with three different shells (tcsh, bash, mksh) and
> > with both gcc and clang, and all have the same behavior. (Interestingly,
> if
> > I compile the example with MSVC and run it in a Cygwin shell, it does
> _not_
> > pop up an error dialog box, so presumably it's in the Cygwin runtime,
> > specifically the definition of __assert_func.)
> >
> > I see the same behavior as William:
> >
> > ./a.exe < /dev/null > output.txt 2>&1
> > pops a message box.
> >
> > gcc (GCC) 10.2.0
> > CYGWIN_NT-10.0 XXX 3.1.7(0.340/5/3) 2020-08-22 17:48 x86_64 Cygwin
> > mintty 3.4.1 (x86_64-pc-cygwin)
> >
> > - André Bleau
>
> It works fine for me.
> Can you check 'gcc -M assert.cpp' ?
> My result is:
>
> $ gcc -M assert.cpp
> assert.o: assert.cpp /usr/include/assert.h /usr/include/_ansi.h \
> /usr/include/newlib.h /usr/include/_newlib_version.h \
> /usr/include/sys/config.h /usr/include/machine/ieeefp.h \
> /usr/include/sys/features.h /usr/include/cygwin/config.h
>
Mine is identical. (Same for "uname -a" output, which André posted above.)
The fact that you and André don't get a dialog box gives me hope that
there's something in the environment or installation that controls that
behavior. (Just to make certain, "works find for me" means that you ran the
executable, redirecting both stdin and stderror, and did not get an error
popup, right?)
--
William M. (Mike) Miller | Edison Design Group
william.m.mil...@gmail.com
--
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
Re: Failed assertion dialog box
On Fri, Nov 13, 2020 at 10:45 PM Duncan Roe
wrote:
> Hi William,
>
> On Fri, Nov 13, 2020 at 12:27:57PM -0500, cygwin wrote:
> > I've run into a problem running a collection of tests under Cygwin and I
> > wonder if anyone can suggest a way around it.
> >
> > The problem occurs when a program being run fails a C/C++ runtime
> > assertion. Ordinarily, this just writes an error message on stderr and
> > aborts. Under Cygwin, however, if both stdin and stderr are redirected to
> > files, the program instead pops up a dialog box that must be
> interactively
> > dismissed before the failed program will exit - holding up all the tests
> > that follow it.
> >
> > Specifically, if I have the following as assert.cpp:
> >
> > #include
> > int main() {
> > assert(false);
> > }
> >
> > and say
> >
> > gcc assert.cpp
> > ./a.exe < /dev/null > output 2>&1
> >
> > I get an error dialog box saying
> >
> > Failed assertion
> > false
> > at line 3 of file assert.cpp
> > in function int main()
> >
> > If I omit either the stdin or the stderr redirection, the program behaves
> > as desired with no dialog box.
> >
> > Is there an environment setting or compiler command-line option I can
> give
> > to suppress the dialog box and always just write a message to stderr and
> > abort? Thanks for any insights.
>
> Your example WFFM, (Cygwin64, gcc 10.2.0, everything else also up to date).
>
> Do you still see this behaviour if you run the installer?
>
Thanks for your reply; unfortunately, yes, it does. I had refreshed
the installation fairly recently, and running the installer only updated a
few things, not cygwin.dll and not gcc; my installation is the same as
yours. I've tried it with three different shells (tcsh, bash, mksh) and
with both gcc and clang, and all have the same behavior. (Interestingly, if
I compile the example with MSVC and run it in a Cygwin shell, it does _not_
pop up an error dialog box, so presumably it's in the Cygwin runtime,
specifically the definition of __assert_func.)
--
William M. (Mike) Miller | Edison Design Group
william.m.mil...@gmail.com
--
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
Failed assertion dialog box
I've run into a problem running a collection of tests under Cygwin and I
wonder if anyone can suggest a way around it.
The problem occurs when a program being run fails a C/C++ runtime
assertion. Ordinarily, this just writes an error message on stderr and
aborts. Under Cygwin, however, if both stdin and stderr are redirected to
files, the program instead pops up a dialog box that must be interactively
dismissed before the failed program will exit - holding up all the tests
that follow it.
Specifically, if I have the following as assert.cpp:
#include
int main() {
assert(false);
}
and say
gcc assert.cpp
./a.exe < /dev/null > output 2>&1
I get an error dialog box saying
Failed assertion
false
at line 3 of file assert.cpp
in function int main()
If I omit either the stdin or the stderr redirection, the program behaves
as desired with no dialog box.
Is there an environment setting or compiler command-line option I can give
to suppress the dialog box and always just write a message to stderr and
abort? Thanks for any insights.
--
William M. (Mike) Miller | Edison Design Group
william.m.mil...@gmail.com
--
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
Re: After cygwin upgrade, Emacs shell buffers with colors are corrupted
On Thu, Mar 19, 2020 at 3:51 PM David Karr via Cygwin wrote: > On Wed, Mar 18, 2020 at 2:17 PM David Karr <> wrote: > > > On Wed, Mar 18, 2020 at 9:38 AM Ken Brown via Cygwin <> wrote: > > > >> On 3/18/2020 11:22 AM, Andrey Repin wrote: > >> > Greetings, David Karr! > >> > > >> >> Thanks, that worked. For now, I guess I have to figure out how to > set > >> that > >> >> property permanently, or until this pty bug is fixed.. I start Emacs > >> from a > >> >> shortcut, executing "emacs.xml". I see the file appears to have some > >> >> syntax for setting the environment, but I've never inspected that > file > >> >> before. > >> > > >> > You set it in Windows. > >> > >> Not necessarily. He might just want to set it for emacs. Editing > >> emacs.xml is > >> a fine way to do it. > >> > > > > I have no idea whether I would want to do it only for Emacs, as I don't > > know what the issue is. > > > > However, if I wanted to, could you point me to the documentation for > > changing that file? The README doesn't say anything about this. > > > > > Just so it's clear, Ken Brown directly sent me some information of what he > knew about the emacs.xml documentation, but it didn't appear to work. > > I've verified that setting the CYGWIN variable globally to "disable_pcon" > has resolved the problem. > This is what I did as well to address the problem of M-x gdb not working in emacs in a new Cygwin installation. I don't know what I might be losing in other functionality by setting the CYGWIN environment variable globally to "disable_pcon", but it did address my gdb issue effectively. -- William M. (Mike) Miller | Edison Design Group william.m.mil...@gmail.com -- 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
Re: Emacs gud not working on new installation
On Thu, Mar 5, 2020 at 5:40 AM Takashi Yano wrote: > On Wed, 4 Mar 2020 10:39:11 -0500 > "William M. (Mike) Miller" wrote: > > On Wed, Mar 4, 2020 at 9:58 AM Ken Brown wrote: > > > > > On 3/4/2020 9:44 AM, William M. (Mike) Miller wrote: > > > > I installed Cygwin on a new computer last weekend. On my previous > > > computer, > > > > I used gud with gdb in emacs (M-x gdb) for debugging. However, on > the new > > > > computer it is not working. I suspect that gdb is producing output > that > > > is > > > > not formatted correctly for gud to parse. > > > > [...snip...] > > > > > > > > I don't know whether this is an emacs problem or a Cygwin problem. > Here > > > are two things you can try: > > > > > > 1. Roll back the cygwin package to 3.0.7 to see if that fixes the > > > problem. If so, the problem is likely related to the pty changes in > > > cygwin-3.1.x. > > > > > > > This worked. Thanks for the tip! > > I guess starting emacs with: > CYGWIN=disable_pcon emacs > helps in cygwin 3.1.4. > Thanks! I will keep that in mind in case I update to a newer version of Cygwin before this issue is addressed. -- William M. (Mike) Miller | Edison Design Group william.m.mil...@gmail.com -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Emacs gud not working on new installation
On Wed, Mar 4, 2020 at 9:58 AM Ken Brown wrote: > On 3/4/2020 9:44 AM, William M. (Mike) Miller wrote: > > I installed Cygwin on a new computer last weekend. On my previous > computer, > > I used gud with gdb in emacs (M-x gdb) for debugging. However, on the new > > computer it is not working. I suspect that gdb is producing output that > is > > not formatted correctly for gud to parse. [...snip...] > > I don't know whether this is an emacs problem or a Cygwin problem. Here > are two things you can try: > > 1. Roll back the cygwin package to 3.0.7 to see if that fixes the > problem. If so, the problem is likely related to the pty changes in > cygwin-3.1.x. > This worked. Thanks for the tip! -- William M. (Mike) Miller | Edison Design Group william.m.mil...@gmail.com -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Emacs gud not working on new installation
I installed Cygwin on a new computer last weekend. On my previous computer, I used gud with gdb in emacs (M-x gdb) for debugging. However, on the new computer it is not working. I suspect that gdb is producing output that is not formatted correctly for gud to parse. When I start gud in emacs on the new computer, I get the usual 6-pane configuration, and gdb puts out its usual configuration and start-up information. When I type the "run" command, however, the program being debugged starts and runs, the command pane correctly displays the usual "Starting program" messaged, but the "[New thread...", etc. messages and any further gdb output (breakpoint messages, output of "info", etc.) do not. The program input/output pane updates, but none of the others do. I can type commands that are correctly passed through to gdb, but no gdb output ever appears in the command pane. I also tried just the plain "M-x gud-gdb" interface, and that may give a hint as to what is going on. I did get the gdb output, but with only newlines, no carriage returns, in the command pane. That is, each successive line of output from gdb began one character to the right of the last character of the previous line instead of beginning in column 0, as it did on the old computer. Any suggestions for how to diagnose or fix the problem would be most appreciated. -- William M. (Mike) Miller | Edison Design Group william.m.mil...@gmail.com -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: gdb 7.11.1-2 started within emacs fails
On Wed, Oct 19, 2016 at 12:54 PM, Corinna Vinschen <corinna-cyg...@cygwin.com> wrote: > On Oct 19 12:46, Rockefeller, Harry wrote: >> >-Original Message- >> >From: cygwin-ow...@cygwin.com [mailto:cygwin->ow...@cygwin.com] On Behalf >> >Of William M. (Mike) Miller >> >Sent: Wednesday, October 19, 2016 10:30 AM >> >To: cygwin@cygwin.com >> >Subject: Re: gdb 7.11.1-2 started within emacs fails >> [snip] >> >>>I can confirm that this happens also with gdb-7.11.1-1 but not >> >>>gdb-7.10.1-1. (I tested on x86_64, since gdb-7.10.1-1 is broken on x86.) >> >>>It also fails with M-x gdb instead of M-x gud-gdb, but with a different >> >>>error message: >> >>>Failed to resume program execution (ContinueDebugEvent failed, error >> >>>87) Ken >> >> >> >> I tried using 'ddd' instead of emacs and gdb aborts with the same >> >> readline ... message above. >> >> >Any progress on the above issue? I recently updated my gdb and am running >> >into the same problem. >> >William M. (Mike) Miller | Edison Design Group william.m.mil...@gmail.com >> >> No progress I am aware of. I switched over to 64-bit Cygwin which uses >> gdb-7.10.1-1 to avoid this problem. >> This "request" may be related to the problem: I would like to see the >> autogenerated gdb line: >> "---Type to continue, or q to quit---" to go away. >> gdb pauses posting this line unnecessarily. > > https://sourceware.org/gdb/wiki/FAQ#How_do_I_disable_the_.22Type_.3Creturn.3E_to_continue.2C_or_q_.3Creturn.3E_to_quit.22_pagination_prompt_in_GDB.3F Thanks for the reference. I don't know why the OP thought that might have been related to the gdb crash, but it didn't do anything to help with that when I tried it. -- William M. (Mike) Miller | Edison Design Group william.m.mil...@gmail.com -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: gdb 7.11.1-2 started within emacs fails
On Thu, Sep 29, 2016 at 11:21 AM, Rockefeller, Harry <harry.rockefel...@flightsafety.com> wrote: > >>-Original Message- >>From: cygwin-ow...@cygwin.com [mailto:cygwin->ow...@cygwin.com] On Behalf Of >>Ken Brown >>Sent: Tuesday, September 27, 2016 3:16 PM >>To: cygwin@cygwin.com >>Subject: Re: gdb 7.11.1-2 started within emacs fails > >>On 9/27/2016 2:47 PM, Rockefeller, Harry wrote: >>> Using program foo: >>> program foo >>> e = 1.0 >>> stop >>> end >>> >>> $ /usr/bin/gfortran-g foo.f -o foo >>> >>> Emacs version info: GNU Emacs 25.1.1 (i686-pc-cygwin, GTK+ Version >>> 3.18.9) of 2016-09-17 >>> >>> Inside emacs I ran M-x gud-gdb and got ... GNU gdb (GDB) (Cygwin >>> 7.11.1-2) 7.11.1 ... >>> (gdb) b 1 >>> Breakpoint 1 at 0x4011d6: file foo.f, line 1. >>> (gdb) r >>> Starting program: /cygdrive/c/Users/harryr/foo.exe [New Thread >>> 6296.0x22ac] [New Thread 6296.0x24d4] >>> readline: readline_callback_read_char() called with no handler! >>> Debugger aborted (core dumped) >>> >>> Foo written in C++ also fails with the same message. >>> Running gdb foo in bash gives the expected result: >>> gdb stops at first executable line prompting for next gdb command. >>I can confirm that this happens also with gdb-7.11.1-1 but not gdb-7.10.1-1. >>(I tested on x86_64, since gdb-7.10.1-1 is broken on x86.) >>It also fails with M-x gdb instead of M-x gud-gdb, but with a different error >>message: >>Failed to resume program execution (ContinueDebugEvent failed, error 87) >>Ken > > I tried using 'ddd' instead of emacs and gdb aborts with the same readline > ... message above. Any progress on the above issue? I recently updated my gdb and am running into the same problem. -- William M. (Mike) Miller | Edison Design Group william.m.mil...@gmail.com -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: emacs gud-interface is not updated after gdb command execution (maybe because of incomplete output from gdb)
On Thu, May 26, 2016 at 5:30 AM, Tobias Zawada <i_in...@tn-home.de> wrote: > Hello, > when debugging c-programs (the special program does not matter) with gud/gdb > the > prompt "(gdb)" > is missing after the execution of the "start" command. This also happens with > other commands such as "next". Also variable values and outputs are not > correctly updated. > I do not have this problem under linux. > > There was already a similar problem with the update of the gdb-interface: > https://www.cygwin.com/ml/cygwin/2015-06/msg00277.html > That thread has a dead end. As the initiator of that thread, thank you very much for bringing up the issue again and for all the investigative work. Since my initial report did not result in any fixes, I have given up on gud and am using cgdb, which is inferior but works well enough, but it would be very welcome to have a fully-working gud again. Just one update on that original report: item #3 has been fixed by recent versions of gdb and is no longer a problem. -- William M. (Mike) Miller | Edison Design Group william.m.mil...@gmail.com -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Performance of "ls -F"
On Thu, Jan 21, 2016 at 10:44 AM, Achim Gratz <strom...@nexgo.de> wrote: > I am finding a large performance gap between plain "ls" and "ls -F" in a > directory with many files on a network share (NetApp disguised as NTFS if > that matters). This has been there for quite a while, I've just now > realized what the reason was (I have "ls -F" as an alias for "ls" in my > interactive shells). In a directory with 1300 files, a plain "ls" completes > in 0.3s, while "ls -F" requires about 95s. Determining the file class seems > to require around 70...90ms per file, which I can confirm also for > directories with a lot less files. What's involved in that determination > that takes such a long time? The overhead appears to be in checking for executable files; using --file-type instead of -F, which just omits the '*' category, reduces the time for ls in one of my (local) large directories from over one second to 0.04 seconds. -- William M. (Mike) Miller | Edison Design Group william.m.mil...@gmail.com -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] Updated: gdb-7.10.1-1 (TEST)
On Thu, Jan 14, 2016 at 10:11 AM, Jon Turney <jon.tur...@dronecode.org.uk> wrote: > > The following package has been updated in the Cygwin distribution: > > * gdb-7.10.1-1 > > The GNU debugger allows you to debug programs written in C, C++, an other > languages, by executing them in a controlled fashion and printing their > data. > > This is an update to the latest upstream version. See the > /usr/share/doc/gdb/NEWS file for a list of user-visible changes. > > In addition, it contains the following patches carried forward from the > previous Cygwin package: > > * Teach the demangler to deal with '@'-decorated __stdcall functions > * Various fixes for Cygwin signal handling > * (experimental) Teach gdb how to unwind frames for the Cygwin signal > delivery wrapper functions _sigbe and sigdelayed > > and the following new patches: > > * Warn rather than stopping with an error if realpath() for a DLL fails > (Tim Chick) > Addresses: https://cygwin.com/ml/cygwin/2014-08/msg00401.html > * Fix a memory leak which would occur in the case when the result of > realpath() is greater than or equal to SO_NAME_MAX_PATH_SIZE (Corinna > Vinschen) > > known issues: > > There seems to be a regression since 7.8, apparently due to gdb core > changes, where gdb experiences an internal error when attempting to > single-step in one thread as another thread receives a SIGCHLD. Does this version contain the fix that was discussed here a few months ago for gdb arbitrarily starting extra threads, preventing stepping, continuing, etc.? (See the discussion containing https://cygwin.com/ml/cygwin/2015-06/msg00321.html for context.) -- William M. (Mike) Miller | Edison Design Group william.m.mil...@gmail.com -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] Updated: gdb-7.10.1-1 (TEST)
On Thu, Jan 14, 2016 at 6:33 PM, Jon Turney <jon.tur...@dronecode.org.uk> wrote: > On 14/01/2016 15:53, William M. (Mike) Miller wrote: >> >> On Thu, Jan 14, 2016 at 10:11 AM, Jon Turney >> <jon.tur...@dronecode.org.uk> wrote: >>> >>> >>> The following package has been updated in the Cygwin distribution: >>> >>> * gdb-7.10.1-1 >>> > [...] >> >> >> Does this version contain the fix that was discussed here a few months >> ago for gdb arbitrarily starting extra threads, preventing stepping, >> continuing, etc.? (See the discussion containing >> https://cygwin.com/ml/cygwin/2015-06/msg00321.html for context.) > > > It includes the patch from [1] which that thread eventually leads to > > I hope that fixes your issue, but I can't test that. > > [1] https://sourceware.org/bugzilla/show_bug.cgi?id=18127 Great, thanks. I'll give it a try as soon as it gets to my usual mirror (wasn't there yet when I checked earlier). -- William M. (Mike) Miller | Edison Design Group william.m.mil...@gmail.com -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: gdb arbitrarily starting threads
On Wed, Jun 24, 2015 at 10:33 AM, Eli Zaretskii <e...@gnu.org> wrote: > People who can reproduce this problem and can also build their own GDB > are encouraged to try the patch posted here: > > https://sourceware.org/ml/gdb/2015-06/msg00071.html > > and report whether it solves the problem on Cygwin. (I already > verified that the native MinGW debugging is fixed by that patch.) Any estimate on when a gdb release containing this patch might make it to Cygwin? It's not in the most recent version in setup (7.9.1-1). -- William M. (Mike) Miller | Edison Design Group william.m.mil...@gmail.com -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: gdb arbitrarily starting threads
On Wed, Jun 24, 2015 at 10:33 AM, Eli Zaretskii <e...@gnu.org> wrote: > People who can reproduce this problem and can also build their own GDB > are encouraged to try the patch posted here: > > https://sourceware.org/ml/gdb/2015-06/msg00071.html > > and report whether it solves the problem on Cygwin. (I already > verified that the native MinGW debugging is fixed by that patch.) Any prognosis for if/when a version of gdb containing this patch might make it to Cygwin? -- William M. (Mike) Miller | Edison Design Group william.m.mil...@gmail.com -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: gdb arbitrarily starting threads
On Sun, Jun 21, 2015 at 3:29 PM, Ken Brown kbr...@cornell.edu wrote: On 6/20/2015 4:51 PM, William M. (Mike) Miller wrote: On Sat, Jun 20, 2015 at 4:42 PM, Ken Brown kbr...@cornell.edu wrote: On 6/20/2015 4:02 PM, William M. (Mike) Miller wrote: Thanks for the reply. My concern, however, isn't that new threads are being created; it's that when gdb does this, it sets the state of all threads, including my main thread, to (running) so that I can't single-step through my program any more. If I try to say next, I get the error: Cannot execute this command while the selected thread is running. But I did nothing overt to start my thread. It never used to do this, but it happens regularly now. Eli Zaretskii has asked me to pass on the following information: On 6/21/2015 2:43 PM, Eli Zaretskii wrote: Please point the people discussing this on the Cygwin list to these 2 threads on GDB mailing lists: https://sourceware.org/ml/gdb/2015-03/msg00024.html https://sourceware.org/ml/gdb/2015-06/msg5.html https://sourceware.org/ml/gdb-patches/2015-06/msg00215.html Bottom line: (1) it happens on Windows 7, not just on 8.1; (2) it happens in the MinGW build of GDB, and so is not specific to threads started by Cygwin for its own purposes; (3) it will most probably be solved soon, since it is currently blocking the release of the upcoming GDB 7.10. Please keep Eli in the CC on any replies since he is not subscribed to the Cygwin list. Thanks to Eli for the work on tracking this down! It certainly is annoying, so I'll definitely keep my eye out for a 7.10 announcement. Thanks for the info. -- William M. (Mike) Miller | Edison Design Group william.m.mil...@gmail.com -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
gdb arbitrarily starting threads
I have a single-threaded executable that has a number of debug-print routines that can be called interactively in the debugger to display data structures to stderr. Something has changed in gdb/gcc/Cygwin during the last year or so (I don't update my installation very often) so that when I call one of these functions, _sometimes_ gdb will start a new thread and put my current thread into running status, so that I can't step, etc. (although the thread isn't actually running). Here's the scenario: 1) I say gdb xxx.exe, set a breakpoint, and run. When I hit the breakpoint, info threads shows me two threads, one for my executable and one with some _cygtls/cygthread/ntdll frames; both are stopped. 2) I say up a couple of times, then p db_foo(p) (where db_foo is one of these debug-print routines that displays to stderr the data structure pointed to by p). Sometimes, but not always, gdb will respond with [New Thread 1436.0x1f00] and although a bt will show the stack as still stopped at the breakpoint, info threads will show all threads as (running), and typing n is met with the error, Cannot execute this command while the selected thread is running. (Actually, for the first time just now, while running my scenario to make sure I got all the details right for this email, I saw gdb start a new thread in response to a next command -- (gdb) n [New Thread 1436.0x1a0c] after I had done a p db_foo(p) a couple of times without seeing a new thread created, so apparently it's not just invoking one of these debug-print functions that can result in this behavior.) Changing to one of the newly-created threads reveals this stack trace: #0 0x7733df6c in ntdll!ZwWaitForWorkViaWorkerFactory () from /c/WINDOWS/SYSTEM32/ntdll.dll #1 0x77320153 in ntdll!RtlRunOnceBeginInitialize () from /c/WINDOWS/SYSTEM32/ntdll.dll #2 0x6100626b in _cygtls::call2(unsigned long (*)(void*, void*), void*, void*) () from /usr/bin/cygwin1.dll #3 0x61006306 in _cygtls::call(unsigned long (*)(void*, void*), void*) () from /usr/bin/cygwin1.dll #4 0x610828d8 in threadfunc_fe(void*) () from /usr/bin/cygwin1.dll #5 0x74be7c04 in KERNEL32!BaseThreadInitThunk () from /c/WINDOWS/SYSTEM32/KERNEL32.DLL #6 0x7735ad1f in ntdll!RtlInitializeExceptionChain () from /c/WINDOWS/SYSTEM32/ntdll.dll #7 0x7735acea in ntdll!RtlInitializeExceptionChain () from /c/WINDOWS/SYSTEM32/ntdll.dll #8 0x in ?? () Any ideas on what I can do to avoid this annoying behavior or to regain control of my debugging session after it occurs? I'm running 32-bit Cygwin on Windows 8.1. Thanks. -- William M. (Mike) Miller | Edison Design Group william.m.mil...@gmail.com -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: gdb arbitrarily starting threads
On Sat, Jun 20, 2015 at 2:47 PM, Corinna Vinschen corinna-cyg...@cygwin.com wrote: On Jun 20 09:29, William M. (Mike) Miller wrote: I have a single-threaded executable that has a number of debug-print routines that can be called interactively in the debugger to display data structures to stderr. Something has changed in gdb/gcc/Cygwin during the last year or so (I don't update my installation very often) so that when I call one of these functions, _sometimes_ gdb will start a new thread and put my current thread into running status, so that I can't step, etc. (although the thread isn't actually running). Here's the scenario: 1) I say gdb xxx.exe, set a breakpoint, and run. When I hit the breakpoint, info threads shows me two threads, one for my executable and one with some _cygtls/cygthread/ntdll frames; both are stopped. 2) I say up a couple of times, then p db_foo(p) (where db_foo is one of these debug-print routines that displays to stderr the data structure pointed to by p). Sometimes, but not always, gdb will respond with [New Thread 1436.0x1f00] You don't have this under control. Nor does Cygwin, most of the time. E.g, a debugged Windows executable has always at least two threads, one is your process thread, one is the thread created by the OS when the debugger attaches to a process. Every Cygwin process has at least two threads, your process thread, as well as a so-called signal thread, the thread handling POSIX signals, created at every process startup by the Cygwin DLL. Certain Windows system calls create threads in your process to perform tasks under the hood. Cygwin is doing the same, for instance to implement interruptible system calls where the underlying OS call is non-interuptible. select(2) may start multiple threads at once. Etc. There's no way around that. Windows process handling is centered around cheap thread creation and termination. Have a look into the Details view in Windows Task Manager. Activate the Threads column. Note that almost all processes are running with more than one thread. Just don't worry about it, it's kind of system inherent. Thanks for the reply. My concern, however, isn't that new threads are being created; it's that when gdb does this, it sets the state of all threads, including my main thread, to (running) so that I can't single-step through my program any more. If I try to say next, I get the error: Cannot execute this command while the selected thread is running. But I did nothing overt to start my thread. It never used to do this, but it happens regularly now. -- William M. (Mike) Miller | Edison Design Group william.m.mil...@gmail.com -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: gdb arbitrarily starting threads
On Sat, Jun 20, 2015 at 4:42 PM, Ken Brown kbr...@cornell.edu wrote: On 6/20/2015 4:02 PM, William M. (Mike) Miller wrote: Thanks for the reply. My concern, however, isn't that new threads are being created; it's that when gdb does this, it sets the state of all threads, including my main thread, to (running) so that I can't single-step through my program any more. If I try to say next, I get the error: Cannot execute this command while the selected thread is running. But I did nothing overt to start my thread. It never used to do this, but it happens regularly now. I'm not seeing this on my system (Windows 7, both 32-bit and 64-bit Cygwin). I'm running 8.1, so that could well be the difference there. I debugged the emacs source, set a breakpoint, and stepped through the program when the breakpoint was hit. Could this be caused by BLODA interference (https://cygwin.com/faq/faq.html#faq.using.bloda)? I certainly won't say that it's impossible, but I think it's unlikely. The symptoms mentioned there don't seem related. Also, the only one of those programs I'm using is Windows Defender, and I've been using it for over two years, but this problem only started within the last few months. (Of course, I suppose it's possible that something in Cygwin/gdb/gcc changed to make it more sensitive, or an update to Windows Defender made it more intrusive...) Failing a way to keep gdb from doing this, is there a way in gdb to stop a thread that's in (running) state? (Even though it's sitting at a breakpoint.) -- William M. (Mike) Miller | Edison Design Group william.m.mil...@gmail.com -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Problems running gdb in emacs on Windows 8.1
On Thu, Jun 18, 2015 at 7:53 AM, Jon TURNEY jon.tur...@dronecode.org.uk wrote: On 17/06/2015 15:53, William M. (Mike) Miller wrote: I'm having numerous problems recently running gdb inside emacs (both -w32 and -X11): [...] All of these things used to work fine. I'm not sure exactly when things changed, as I didn't update my Cygwin installation for quite a while. My current installation has gdb 7.9.1-1 and emacs 24.5-1. Any thoughts on what the problem might be and how to fix it would be appreciated. gdb 7.9.1-1 is supposed to be marked as a test release, so I am not sure how you come to be running it without explicitly asking for it. In any case, you might try downgrading to gdb 7.8-2 to see if that changes anything. Thanks for the reply. Unfortunately, I was having the same problems with gdb 7.8-2 and installed the latest to see if it helped. It didn't. -- William M. (Mike) Miller | Edison Design Group william.m.mil...@gmail.com -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Problems running gdb in emacs on Windows 8.1
On Thu, Jun 18, 2015 at 10:29 AM, Ken Brown kbr...@cornell.edu wrote: On 6/18/2015 8:09 AM, William M. (Mike) Miller wrote: On Thu, Jun 18, 2015 at 7:53 AM, Jon TURNEY jon.tur...@dronecode.org.uk wrote: On 17/06/2015 15:53, William M. (Mike) Miller wrote: I'm having numerous problems recently running gdb inside emacs (both -w32 and -X11): [...] All of these things used to work fine. I'm not sure exactly when things changed, as I didn't update my Cygwin installation for quite a while. My current installation has gdb 7.9.1-1 and emacs 24.5-1. Any thoughts on what the problem might be and how to fix it would be appreciated. gdb 7.9.1-1 is supposed to be marked as a test release, so I am not sure how you come to be running it without explicitly asking for it. In any case, you might try downgrading to gdb 7.8-2 to see if that changes anything. Thanks for the reply. Unfortunately, I was having the same problems with gdb 7.8-2 and installed the latest to see if it helped. It didn't. Can you give a detailed recipe for reproducing the problem (preferably starting from 'emacs -Q' and using gdb 7.8-2)? Here's what I did, after reinstalling gdb 7.8-2. (emacs is emacs-X11.) 1) emacs -Q somefile.c 2) M-x eval-expression (setq gdb-many-windows t) 3) M-x eval-expression (setq gdb-show-threads-by-default t) 4) M-x gdb 5) I edited the path of the executable so that it named a symlink to the executable in the directory in which I wanted to run the program 6) In the *gud-xxx.exe* window: b foo 7) In the *gud-xxx.exe* window: run cmd-line-arguments The breakpoint was hit and the source window updated to the breakpoint location; however, all the other windows (locals, stack frames, threads) were empty. 8) In the *gud-xxx.exe* window: up At this point, the source window (middle-left) is still showing the breakpoint location, not the calling function; the stack frame window has the stack trace but points to frame 0; the locals window shows the variables for frame 0; and the threads windows shows the program threads as stopped. 9) In the *gud-xxx.exe* window: up Windows shift to displaying information for frame 1. 10) In the *gud-xxx.exe* window: p 0 The source and locals windows shift to frame 2 information, but the stack frames window still indicates frame 1. 11) In the *gud-xxx.exe* window: p 0 Now the stack frames window updates to point to frame 2. 12) In the *gud-xxx.exe* window: fr 0 The source window updates to show the breakpoint location again, but the locals and stack frames windows still reflect frame 2. 13) In the *gud-xxx.exe* window: n Locals and stack frames windows update to frame 0. Source window is correctly indicating execution point. 14) In the *gud-xxx.exe* window: p db_foo(x) Output from debugging function db_foo (to stderr) appears in the input/output window correctly, but all threads in the thread window now indicate running instead of stopped. All other windows unchanged; in particular, the source window still shows the execution point where it was. 15) In the *gud-xxx.exe* window: n Bell rings, no changes to any window. At this point I have to run again to get back to the breakpoint. I'm not able to reliably reproduce the replacement of the *gud-xxx.exe* window with a source window; as I said originally, it seems unpredictable when it will happen. -- William M. (Mike) Miller | Edison Design Group william.m.mil...@gmail.com -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problems running gdb in emacs on Windows 8.1
I'm having numerous problems recently running gdb inside emacs (both -w32 and -X11): 1) The stack trace window requires one or two gdb commands to catch up with the current stack frame. E.g., I'll hit a breakpoint after run and then type up; the frame pointer still points at frame 0. I'll type up again, so I'm actually looking at frame 2, but the frame pointer now points at frame 1. I'll type p variable_name, and now the frame pointer correctly points at frame 2. 2) Normally the gdb command window is the upper-left window with the source displayed in the center-left window. Occasionally (I haven't been able to find a pattern), when I execute a gdb command the upper-left window will switch away from the *gud-xxx.exe* buffer to display the current source location, leaving the center-left window also displaying a source window. If I switch the center-left window to *gud-xxx.exe, the window configuration appears to be stable, with the source updating correctly in the upper-left window during the rest of the debugger session. (Simply switching the upper-left window back to *gud-xxx.exe* is generally not stable, with that window likely to switch back to a source buffer within a couple of gdb commands.) 3) My executable has a number of debugging-output functions that are intended to print a data structure to stderr and return. When I call one of these using p db_foo(x), unless it is the first gdb command after a breakpoint, all my threads will switch from stopped to running status so that I can no longer step, etc. All of these things used to work fine. I'm not sure exactly when things changed, as I didn't update my Cygwin installation for quite a while. My current installation has gdb 7.9.1-1 and emacs 24.5-1. Any thoughts on what the problem might be and how to fix it would be appreciated. -- William M. (Mike) Miller | Edison Design Group william.m.mil...@gmail.com -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Fwd: emacs-X11 memory problem after Windows update
On Thu, Dec 12, 2013 at 11:04 AM, Ken Brown kbr...@cornell.edu wrote: On 12/12/2013 10:13 AM, William M. (Mike) Miller wrote: I'm running Windows 8.1 (cygcheck.out attached) and did a Windows update this morning. Since then I cannot run emacs-X11. Sometimes the message is: Memory exhausted--use M-x save-some-buffers then exit and restart Emacs Often there is no message. Once I got: ***MEMORY-ERROR***: emacs[2924]: GSlice: failed to allocate 2040 bytes (alignment: 2048): Cannot allocate memory Fatal error 6: AbortedAbort (core dumped) Does the problem occur with emacs -Q? Yes. Have you checked http://cygwin.com/faq/faq.html#faq.using.bloda ? I hadn't previously. The only thing on that list that I run, to the best of my knowledge, is Windows Defender. I turned off real-time checking and tried emacs-X11 again, with the same result (a Memory exhausted error). -- William M. (Mike) Miller | Edison Design Group william.m.mil...@gmail.com -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Fwd: emacs-X11 memory problem after Windows update
On Thu, Dec 12, 2013 at 11:29 AM, Ken Brown kbr...@cornell.edu wrote: On 12/12/2013 11:17 AM, William M. (Mike) Miller wrote: On Thu, Dec 12, 2013 at 11:04 AM, Ken Brown kbr...@cornell.edu wrote: On 12/12/2013 10:13 AM, William M. (Mike) Miller wrote: I'm running Windows 8.1 (cygcheck.out attached) and did a Windows update this morning. Since then I cannot run emacs-X11. Sometimes the message is: Memory exhausted--use M-x save-some-buffers then exit and restart Emacs Often there is no message. Once I got: ***MEMORY-ERROR***: emacs[2924]: GSlice: failed to allocate 2040 bytes (alignment: 2048): Cannot allocate memory Fatal error 6: AbortedAbort (core dumped) Have you checked http://cygwin.com/faq/faq.html#faq.using.bloda ? I hadn't previously. The only thing on that list that I run, to the best of my knowledge, is Windows Defender. I turned off real-time checking and tried emacs-X11 again, with the same result (a Memory exhausted error). I'm not sure turning off real-time protection is enough. Can you actually disable Windows Defender completely? Assuming that clearing the Use this program check box in the Administrator tab of Windows Defender disables [it] completely, I just tried that, and it also made no difference. -- William M. (Mike) Miller | Edison Design Group william.m.mil...@gmail.com -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Fwd: Fwd: emacs-X11 memory problem after Windows update
On Thu, Dec 12, 2013 at 2:54 PM, Christopher Faylor wrote: On Thu, Dec 12, 2013 at 02:45:27PM -0500, Ken Brown wrote: On 12/12/2013 1:25 PM, Christopher Faylor wrote: On Thu, Dec 12, 2013 at 12:13:34PM -0500, Ken Brown wrote: On 12/12/2013 11:41 AM, Achim Gratz wrote: Ken Brown writes: ***MEMORY-ERROR***: emacs[2924]: GSlice: failed to allocate 2040 bytes (alignment: 2048): Cannot allocate memory I'm seeing the same thing on Win7/64 Pro, both for 64bit and 32bit Cygwin. Since I don't normally use the X11 Emacs, unfortunately I don't know which update was introducing this, it used to worked OK a few weeks ago. And do you also use Windows Defender? If this isn't BLODA, I'm completely stumped. Would running under strace help? It might. Achim or Mike (or anyone who can reproduce this problem), could you run strace -o strace.out emacs-X11 -Q and post strace.out somewhere? Btw, posting it somewhere is a good suggestion since strace output seems to be giving spamassassin some problems lately, making it hard to send here. Okay, here it is: https://drive.google.com/file/d/0B5QasYpFDUHeWGdsQ0RlWkk5Wm8/edit?usp=sharing I was watching this in Task Manager; the emacs-X11 process got up to around 400+ MB before dying with a segfault. BTW, I am beginning to think that the link with Windows Update is a red herring; I uninstalled all the updates from this morning, one by one, and emacs-X11 still failed. I then rolled back to a restore point from a couple of days ago, again to no effect. I don't know what changed, though; everything was working fine until this morning. -- William M. (Mike) Miller | Edison Design Group william.m.mil...@gmail.com -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Fwd: Fwd: emacs-X11 memory problem after Windows update
On Thu, Dec 12, 2013 at 5:20 PM, Ken Brown wrote: On 12/12/2013 3:42 PM, William M. (Mike) Miller wrote: On Thu, Dec 12, 2013 at 2:54 PM, Christopher Faylor wrote: On Thu, Dec 12, 2013 at 02:45:27PM -0500, Ken Brown wrote: On 12/12/2013 1:25 PM, Christopher Faylor wrote: On Thu, Dec 12, 2013 at 12:13:34PM -0500, Ken Brown wrote: On 12/12/2013 11:41 AM, Achim Gratz wrote: Ken Brown writes: ***MEMORY-ERROR***: emacs[2924]: GSlice: failed to allocate 2040 bytes (alignment: 2048): Cannot allocate memory I'm seeing the same thing on Win7/64 Pro, both for 64bit and 32bit Cygwin. Since I don't normally use the X11 Emacs, unfortunately I don't know which update was introducing this, it used to worked OK a few weeks ago. And do you also use Windows Defender? If this isn't BLODA, I'm completely stumped. Would running under strace help? It might. Achim or Mike (or anyone who can reproduce this problem), could you run strace -o strace.out emacs-X11 -Q and post strace.out somewhere? Btw, posting it somewhere is a good suggestion since strace output seems to be giving spamassassin some problems lately, making it hard to send here. Okay, here it is: https://drive.google.com/file/d/0B5QasYpFDUHeWGdsQ0RlWkk5Wm8/edit?usp=sharing There's something weird going on with fonts. I'm not very good at interpreting strace output, but it looks like emacs is trying to read all the fonts on your system and running out of memory. I suggest that you delete the directories ~/.fontconfig and ~/.cache/fontconfig. Then run (as administrator) fc-cache -fsv. See if that helps. I did not have those directories in my home directory, but I ran the fc-cache command as you suggested, and that fixed the problem. Thanks! -- William M. (Mike) Miller | Edison Design Group william.m.mil...@gmail.com -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Static destructors not running
On 5/10/05, Christopher Faylor [EMAIL PROTECTED] wrote:
Previous to 1.5.16, static destructors were always called via a
gcc atexit mechanism. This meant that there were scenarios where
destructors would not be called at all so I made cygwin's exit call
the destructors explicitly. I just forgot to make cygwin do the right
thing when returning from main rather than exiting. This will be
fixed in the next snapshot.
There's one more glitch in this. The order of destruction of static
objects should be the inverse of their order of construction,
regardless of whether they are global or local. In 1.5.16 and the
latest snapshot, global static objects are destroyed before local
static objects, regardless of the order of construction. Here's a
demo program:
#include stdio.h
struct A {
int i;
A(int p) : i(p) { printf(A::A(%d)\n, i); }
~A() { printf(A::~A for %d\n, i); }
};
A a(1);
void f() {
static A a(3);
}
main () {
static A a(2);
printf(main\n);
f();
}
In the new Cygwin versions, the output is:
A::A(1)
A::A(2)
main
A::A(3)
A::~A for 1
A::~A for 3
A::~A for 2
The destructors should print 3, 2, 1 instead of 1, 3, 2.
--
William M. (Mike) Miller
[EMAIL PROTECTED]
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
C++ static destructors run in wrong order
I mentioned this at the tail end of the thread on static destructors
not running, but since I got no reaction I guess it was probably
overlooked there.
As noted by Christopher Faylor, the May 10 snapshot fixes the
problem of destructors for static objects not being run when
main() returns. However, it does not fix a problem that was also
introduced in 1.5.16, namely, that destructors for static objects
run in the wrong order. The C++ Standard says that such
destructors run in the inverse order of their constructors, and
that was the case prior to 1.;5.16. However, as demonstrated
by the following sample program, global static objects are now
destroyed before local static objects, ignoring their order of
construction:
#include stdio.h
#include stdlib.h
struct A {
int i;
A(int p) : i(p) { printf(A::A(%d)\n, i); }
~A() { printf(A::~A for %d\n, i); }
};
A a(1);
void f() {
static A a(3);
}
main () {
static A a(2);
printf(main\n);
f();
exit(0);
}
This now prints
A::A(1)
A::A(2)
main
A::A(3)
A::~A for 1
A::~A for 3
A::~A for 2
A::~A for 1 should be last.
--
William M. (Mike) Miller | Edison Design Group
[EMAIL PROTECTED]
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: Static destructors not running
On 5/11/05, Christopher Faylor [EMAIL PROTECTED] wrote: On Wed, May 11, 2005 at 07:01:07AM -0400, William M. (Mike) Miller wrote: The order of destruction of static objects should be the inverse of their order of construction, regardless of whether they are global or local. In 1.5.16 and the latest snapshot, global static objects are destroyed before local static objects, regardless of the order of construction. This should be fixed in the next snapshot. Indeed it is. Thanks again! -- William M. (Mike) Miller [EMAIL PROTECTED] -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Static destructors not running
On 5/9/05, Dave Korn [EMAIL PROTECTED] wrote: Original Message From: William M. (Mike) Miller The output In dtor. is missing. That's because stdout is already closed by the time your dtor runs. I stepped right into it, it does the printf call but somewhere down in the dll it checks the flags field in the stdout FILE object for read/write and finds it's not open for either, so it's at eof. Grep 'cantwrite' if you really want to find it. Anyway, your dtor is called. You're absolutely right -- the destructor is being called. I should have checked that myself, rather than assuming that the absence of its output meant that it was not being executed. Thanks for investigating. I'm still left with the problem of figuring out what changed to cause this result. Until I ran the setup application last Friday, I was seeing output from static destructors, and now I don't. It would save me a lot of work to be able to restore the old behavior, but I don't know what was responsible for this change. -- William M. (Mike) Miller | Edison Design Group [EMAIL PROTECTED] -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
stdout closed before static destructors run
1.9.2-1 libintl 0.10.38-3 libintl1 0.10.40-1 libintl2 0.12.1-3 libintl3 0.14.1-1 libjpeg626b-11 libncurses5 5.2-1 libncurses6 5.2-8 libncurses7 5.3-4 libncurses8 5.4-1 libpcre 4.1-1 libpcre0 4.5-1 libpng12 1.2.5-4 libpopt0 1.6.4-4 libreadline4 4.1-2 libreadline5 4.3-5 libreadline6 5.0-1 libtiff4 3.6.0-5 libungif 4.1.2-1 libXft 2.1.6-1 libXft1 1.0.0-1 libXft2 2.1.6-1 libxml2 2.6.16-2 libxslt 1.1.12-2 login1.9-7 m4 1.4.3-1 make 3.80-1 man 1.5p-1 mingw-runtime3.7-1 minires 1.00-1 mktemp 1.5-3 more 2.11o-1 ncurses 5.4-1 openssh 4.0p1-1 openssl 0.9.7g-1 patch2.5.8-8 patchutils 0.2.30-1 pcre 4.5-1 pcre-doc 4.5-1 pdksh5.2.14-3 perl 5.8.6-4 psutils 1.17-1 python 2.4-1 rcs 5.7-3 readline 5.0-1 rsync2.6.3-1 sed 4.1.4-1 sh-utils 2.0.15-5 sharutils4.2.1-3 splint 3.1.1-1 tar 1.13.25-5 tcltk20030901-1 tcsh 6.14.00-1 termcap 20050421-1 terminfo 5.4_20041009-1 texinfo 4.8-1 textutils2.0.21-2 tidy 041206-1 time 1.7-1 unzip5.50-5 vim 6.3-1 w32api 3.2-1 which1.7-1 wtf 0.0.4-6 X-startup-scripts1.0.10-4 Xaw3d1.5D-5 xorg-x11-base6.8.2.0-1 xorg-x11-bin 6.8.2.0-1 xorg-x11-bin-dlls6.8.2.0-1 xorg-x11-bin-lndir 6.8.2.0-1 xorg-x11-etc 6.8.2.0-1 xorg-x11-fenc6.8.1.0-2 xorg-x11-fnts6.8.1.0-3 xorg-x11-libs-data 6.8.2.0-1 xorg-x11-xwin6.8.2.0-2 xterm196-1 zip 2.3-6 zlib 1.2.2-1 Use -h to see help about each section -- William M. (Mike) Miller [EMAIL PROTECTED] -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Static destructors not running
On 5/10/05, Christopher Faylor [EMAIL PROTECTED] wrote: On Tue, May 10, 2005 at 09:06:36AM -0400, William M. (Mike) Miller wrote: I'm still left with the problem of figuring out what changed to cause this result. Until I ran the setup application last Friday, I was seeing output from static destructors, and now I don't. It would save me a lot of work to be able to restore the old behavior, but I don't know what was responsible for this change. Just as a wild guess, does explicitly calling exit help at all? Yes, the output does appear when I call exit instead of returning from main(). Unfortunately, that's not an option. For one thing, this is shared code that works just fine on other systems (and under Cygwin until I updated last Friday). For another, the semantics of calling exit in main() are not exactly the same as returning from main() -- local automatic objects in main() are not destroyed by the exit() call, which is something some of this code that is now failing relies on. Thanks for the suggestion, though. -- William M. (Mike) Miller | Edison Design Group [EMAIL PROTECTED] -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Static destructors not running
On 5/10/05, Christopher Faylor [EMAIL PROTECTED] wrote: On Tue, May 10, 2005 at 11:54:45AM -0400, William M. (Mike) Miller wrote: Yes, the output does appear when I call exit instead of returning from main(). Unfortunately, that's not an option. For one thing, this is shared code that works just fine on other systems (and under Cygwin until I updated last Friday). For another, the semantics of calling exit in main() are not exactly the same as returning from main() -- local automatic objects in main() are not destroyed by the exit() call, which is something some of this code that is now failing relies on. I was trying to figure out the problem, not suggest that you should change all of your code. Sorry, my misunderstanding. Previous to 1.5.16, static destructors were always called via a gcc atexit mechanism. This meant that there were scenarios where destructors would not be called at all so I made cygwin's exit call the destructors explicitly. I just forgot to make cygwin do the right thing when returning from main rather than exiting. This will be fixed in the next snapshot. Great! Thanks very much. -- William M. (Mike) Miller | Edison Design Group [EMAIL PROTECTED] -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Static destructors not running
On 5/10/05, Christopher Faylor [EMAIL PROTECTED] wrote: Previous to 1.5.16, static destructors were always called via a gcc atexit mechanism. This meant that there were scenarios where destructors would not be called at all so I made cygwin's exit call the destructors explicitly. I just forgot to make cygwin do the right thing when returning from main rather than exiting. This will be fixed in the next snapshot. Sorry, one more question. I thought from the above that reinstalling 1.5.15 would restore the previous behavior for static destructors. According to cygcheck, I now have cygwin 1.5.15-1 installed, but I still don't see the static destructor output. Is there something else I need to revert while waiting for the fix? Thanks again. -- William M. (Mike) Miller [EMAIL PROTECTED] -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Static destructors not running
On 5/10/05, Christopher Faylor [EMAIL PROTECTED] wrote: On Tue, May 10, 2005 at 03:27:02PM -0400, William M. (Mike) Miller wrote: On 5/10/05, Christopher Faylor [EMAIL PROTECTED] wrote: Previous to 1.5.16, static destructors were always called via a gcc atexit mechanism. This meant that there were scenarios where destructors would not be called at all so I made cygwin's exit call the destructors explicitly. I just forgot to make cygwin do the right thing when returning from main rather than exiting. This will be fixed in the next snapshot. Sorry, one more question. I thought from the above that reinstalling 1.5.15 would restore the previous behavior for static destructors. According to cygcheck, I now have cygwin 1.5.15-1 installed, but I still don't see the static destructor output. Is there something else I need to revert while waiting for the fix? Install the snapshot: http://cygwin.com/snapshots/ Yep, fixed. Thanks again. -- William M. (Mike) Miller | Edison Design Group [EMAIL PROTECTED] -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Static destructors not running
I'm sure this is the result of my having done something stupid
with the setup application, but suddenly static destructors no
longer run. That is, for the following program:
#include stdio.h
struct S {
S();
~S();
} s;
S::S() {
printf(In ctor.\n);
}
S::~S() {
printf(In dtor.\n);
}
int main() {
printf(In main.\n);
}
the output is
In ctor.
In main.
The output In dtor. is missing.
I have tried to update all the gcc compilers and mingw libraries to
the latest versions that the setup application allows me, on the
assumption that somehow I managed to get an old version of a
library during my last update, but nothing I have done restores the
static destructor output. From cygcheck, here are the versions of
things I think might matter:
gcc 3.4.1-1
gcc-ada 3.4.1-1
gcc-core 3.4.1-1
gcc-g++ 3.4.1-1
gcc-g77 3.4.1-1
gcc-java 3.4.1-1
gcc-mingw20040810-1
gcc-mingw-ada20040822-1
gcc-mingw-core 20040822-1
gcc-mingw-g++20040822-1
gcc-mingw-g7720040822-1
gcc-mingw-java 20040822-1
mingw-runtime3.7-1
Anyone have any idea how I managed to do this to myself and,
more importantly, how I can undo it?
Thanks!
--
William M. (Mike) Miller
[EMAIL PROTECTED]
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: Wrong results from isfinite with gcc 3.4.1
William M. (Mike) Miller wrote:
The definitions of isfinite() (and fpclassify(), on which isfinite()
depends) from math.h are as follows:
#define fpclassify(x) \
(__extension__ ({__typeof__(x) __x = (x); \
(sizeof (__x) == sizeof (float)) ?
__fpclassifyf(__x) : __fpclassifyd(__x);}))
#define isfinite(x) \
(__extension__ ({__typeof__(x) __x = (x); \
fpclassify(__x) != FP_INFINITE
fpclassify(__x) != FP_NAN;}))
In case anyone else is interested, Andrew Pinski on the newlib
list came up with the diagnosis. The definition of isfinite()
declares a local variable, __x, for the floating point value
being examined and passes that in the call to the macro
fpclassify(). fpclassify() declares its own local variable, __x,
and initializes it with the macro argument. The expansion of
this declaration in fpclassify() shows exactly what is going wrong:
__typeof__(__x) __x = (__x);
In other words, fpclassify()'s __x is initialized to its own
uninitialized value, not to the value passed to isfinite().
Presumably a fix will trickle down eventually. In the meantime,
it's easy to fix locally if anyone else runs into the problem.
--
William M. (Mike) Miller | Edison Design Group, Inc.
[EMAIL PROTECTED]
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Wrong results from isfinite with gcc 3.4.1
There was a thread about this problem a few months ago
(http://sources.redhat.com/ml/cygwin/2004-08/msg00128.html). The
OP at that time was referred to the newlib mailing list, but I
can't find anything on the topic there.
I've recently run into this problem as well, and may have some
new information on it. First, here's an example that shows the
problem:
#include stdio.h
#include math.h
int main() {
float f = 12.34;
double d = 12.34;
long double ld = 12.34;
printf(f = %d\nd = %d\nld = %d\n,
isfinite(f), isfinite(d), isfinite(ld));
}
This prints
f = 1
d = 0
ld = 0
instead of all values being 1 as expected. The value of
isfinite() appears to be consistent across runs with the same
executable, but it varies with usage. For example, executing all
three isfinite() invocations first, saving the results, and
printing the saved values gives different output. For another
example, the application where I encountered this problem can be
built with different feature sets by build options; specifying
different build options (none directly affecting the code where
isfinite() is used) causes isfinite() to return different results
for the same input, presumably just based on the differing memory
images of the executables or differing stack garbage.
The definitions of isfinite() (and fpclassify(), on which
isfinite() depends) from math.h are as follows:
#define fpclassify(x) \
(__extension__ ({__typeof__(x) __x = (x); \
(sizeof (__x) == sizeof (float)) ?
__fpclassifyf(__x) : __fpclassifyd(__x);}))
#define isfinite(x) \
(__extension__ ({__typeof__(x) __x = (x); \
fpclassify(__x) != FP_INFINITE fpclassify(__x) !=
FP_NAN;}))
In the test cases I ran, fpclassify(), used directly rather than
as part of isfinite(), always returns the correct result for the
given value. As an experiment, I tried redefining isfinite() to
incorporate the features of fpclassify() directly rather than
invoking it:
#undef isfinite
#define isfinite(x) \
(__extension__ ({__typeof__(x) __x = (x); \
int __y=(sizeof(__x)==sizeof(float)?__fpclassifyf(__x):__fpclassifyd(__x)); \
__y != FP_INFINITE __y != FP_NAN;}))
In all the cases I tried, this version of isfinite() gave correct
results. Given the instability of the behavior with the math.h
definition of isfinite(), I'm not sure whether this can be
attributed to some problem with the nested macro calls or whether
it's just harder to create a failing scenario with this
definition. However, I thought I'd pass the experience along in
case it triggered some association among the cognoscenti.
As someone who is not too knowledgeable about Cygwin, I do have
some questions about the definition of isfinite() in math.h.
Where did this math.h header come from? It doesn't look like the
math.h on my Linux system (but that's gcc 3.3.3 rather than
3.4.1, so I probably shouldn't expect it to be the same, I
guess). In addition to triggering this bug, there's another
problem with this definition: it doesn't handle long double. The
math.h on my Linux system uses three functions -- __finitef(),
__finite(), and __finitel() -- for implementing isfinite(), while
the Cygwin math.h only uses __fpclassifyf() and __fpclassifyd(),
omitting a version for long double. This could give false
positives for infinities if the long double value overflows when
converted to a double in the call to __fpclassifyd().
--
William M. (Mike) Miller | Edison Design Group, Inc.
[EMAIL PROTECTED]
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: Wrong results from isfinite with gcc 3.4.1
Christopher Faylor wrote: On Wed, Feb 02, 2005 at 03:56:43PM -0500, William M. (Mike) Miller wrote: There was a thread about this problem a few months ago (http://sources.redhat.com/ml/cygwin/2004-08/msg00128.html). The OP at that time was referred to the newlib mailing list, but I can't find anything on the topic there. [snip] As someone who is not too knowledgeable about Cygwin, I do have some questions about the definition of isfinite() in math.h. Where did this math.h header come from? I've put these two paragraphs close together so that hopefully you will be able to come to your own conclusions about where math.h comes from. I don't see any particular need to resort to sarcasm here. The fact that cygwin uses the newlib library for all of its math operations (as you pointed out in your post in the earlier thread) does not necessarily mean that they provided the Standard C header file, just that the math infrastructure code came from newlib. However, poking around for a few minutes in their CVS repository did, in fact, turn up a copy of math.h that looks identical to the one I have here. Thanks for the information. -- William M. (Mike) Miller | Edison Design Group, Inc. [EMAIL PROTECTED] -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
