Emacs-w32... still crashing...

Emacs-w32... still crashing...

[Zdzislaw Meglicki]

It just crashed on me again, after a couple of days
of no crashes at all. The versions of everything
are unchanged since my last message. But this
time, and this is new, I have not seen it before, 
it did not give me the gdb option. Instead it just
crashed and said: "Segmentation fault (core dumped)..."
I have the core, though I don't know if it's going to
be of much use to anyone. I have been reading
mail, scrolling through the messages, with rmail at the 
time.

Zdzislaw (Gustav) Meglicki
Indiana University

--
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-w32... still crashing...

[Ken Brown]

On 5/21/2014 4:14 PM, Zdzislaw Meglicki wrote:
> It just crashed on me again, after a couple of days
> of no crashes at all. The versions of everything
> are unchanged since my last message. But this
> time, and this is new, I have not seen it before,
> it did not give me the gdb option. Instead it just
> crashed and said: "Segmentation fault (core dumped)..."
> I have the core, though I don't know if it's going to
> be of much use to anyone. I have been reading
> mail, scrolling through the messages, with rmail at the
> time.

You only get the prompt to attach gdb if the exception is caught by 
emacs, which then calls emacs_abort.  If the exception is handled at a 
higher level, this won't happen.  The best thing is to just start emacs 
under gdb to begin with.

Ken


--
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-w32... Still Crashing

[Ken Brown]

On 7/9/2014 8:22 AM, Corinna Vinschen wrote:
> On Jul  9 12:15, Corinna Vinschen wrote:
>> On Jul  8 09:55, Ken Brown wrote:
>>> On 7/7/2014 3:12 PM, Zdzislaw Meglicki wrote:
>>>> Program received signal SIGTRAP, Trace/breakpoint trap.
>>>> [Switching to Thread 4532.0xa100]
>>>> 0x00007ff974f39e3b in KERNELBASE!DebugBreak () from /cygdrive/c/WINDOWS/system32/KERNELBASE.dll
>>>> (gdb) bt
>>>> #0  0x00007ff974f39e3b in KERNELBASE!DebugBreak () from /cygdrive/c/WINDOWS/system32/KERNELBASE.dll
>>>> #1  0x000000010061a7a4 in emacs_abort () at /usr/src/debug/emacs-24.3.91-1/src/w32fns.c:8474
>>>> #2  0x000000010043b702 in check_message_stack () at /usr/src/debug/emacs-24.3.91-1/src/xdisp.c:10993
>>>> #3  0x00000001004fd763 in shut_down_emacs (sig=0, stuff=4305643570) at /usr/src/debug/emacs-24.3.91-1/src/emacs.c:2042
>>>> #4  0x00000001004fd591 in Fkill_emacs (arg=60) at /usr/src/debug/emacs-24.3.91-1/src/emacs.c:1952
>>>> #5  0x00000001004fb159 in terminate_due_to_signal (sig=15, backtrace_limit=40) at /usr/src/debug/emacs-24.3.91-1/src/emacs.c:360
>>>> #6  0x0000000100520429 in handle_fatal_signal (sig=15) at /usr/src/debug/emacs-24.3.91-1/src/sysdep.c:1630
>>>> #7  0x000000010052035d in deliver_process_signal (sig=15, handler=0x100520411 ) at /usr/src/debug/emacs-24.3.91-1/src/sysdep.c:1570
>>>> #8  0x0000000100520444 in deliver_fatal_signal (sig=15) at /usr/src/debug/emacs-24.3.91-1/src/sysdep.c:1636
>>>> #9  0x0000000180070c8a in _cygtls::call_signal_handler (this=0x43ce00) at /usr/src/debug/cygwin-1.7.30-1/winsup/cygwin/exceptions.cc:1463
>>>> #10 0x0000000180111db8 in sigdelayed () from /usr/bin/cygwin1.dll
>>>> #11 0x0000000100a2e832 in bss_sbrk_buffer ()
>>>> #12 0x0000000000000000 in ?? ()
>>>
>>> Thanks.  All I can see from this is that a SIGTERM was generated, causing
>>> emacs to abort, but maybe someone else can see more.
>>>
>>> Grasping at straws, as usual, I wonder if these mysterious crashes could be
>>> related to a bug that Corinna just fixed:
>>>
>>>    https://cygwin.com/ml/cygwin-cvs/2014-q3/msg00004.html
>>>
>>> Corinna, is this plausible?  If so, maybe Gustav should try the next
>>> snapshot of the Cygwin DLL.  (The current one doesn't seem to have this fix
>>> in it.)
>>
>> Maybe, but the signal should be SIGSEGV, not SIGTERM.  SIGTERM is
>> usually an application-created signal.
>
> I created new snapshots on http://cygwin.com/snapshots/  They also intend
> to fix a bug in calls to pthread_getattr_np and pthread_attr_getstack
> which seem to raise problems in JIT environments like java, ruby, guile,
> etc.

Thanks.  Gustav, could you try installing the latest snapshot?  I think 
you only have to replace cygwin1.dll if you don't want to install the 
entire snapshot.

Ken


--
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-w32... Still Crashing

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 2721 bytes --]

On Jul  9 12:15, Corinna Vinschen wrote:
> On Jul  8 09:55, Ken Brown wrote:
> > On 7/7/2014 3:12 PM, Zdzislaw Meglicki wrote:
> > >Program received signal SIGTRAP, Trace/breakpoint trap.
> > >[Switching to Thread 4532.0xa100]
> > >0x00007ff974f39e3b in KERNELBASE!DebugBreak () from /cygdrive/c/WINDOWS/system32/KERNELBASE.dll
> > >(gdb) bt
> > >#0  0x00007ff974f39e3b in KERNELBASE!DebugBreak () from /cygdrive/c/WINDOWS/system32/KERNELBASE.dll
> > >#1  0x000000010061a7a4 in emacs_abort () at /usr/src/debug/emacs-24.3.91-1/src/w32fns.c:8474
> > >#2  0x000000010043b702 in check_message_stack () at /usr/src/debug/emacs-24.3.91-1/src/xdisp.c:10993
> > >#3  0x00000001004fd763 in shut_down_emacs (sig=0, stuff=4305643570) at /usr/src/debug/emacs-24.3.91-1/src/emacs.c:2042
> > >#4  0x00000001004fd591 in Fkill_emacs (arg=60) at /usr/src/debug/emacs-24.3.91-1/src/emacs.c:1952
> > >#5  0x00000001004fb159 in terminate_due_to_signal (sig=15, backtrace_limit=40) at /usr/src/debug/emacs-24.3.91-1/src/emacs.c:360
> > >#6  0x0000000100520429 in handle_fatal_signal (sig=15) at /usr/src/debug/emacs-24.3.91-1/src/sysdep.c:1630
> > >#7  0x000000010052035d in deliver_process_signal (sig=15, handler=0x100520411 ) at /usr/src/debug/emacs-24.3.91-1/src/sysdep.c:1570
> > >#8  0x0000000100520444 in deliver_fatal_signal (sig=15) at /usr/src/debug/emacs-24.3.91-1/src/sysdep.c:1636
> > >#9  0x0000000180070c8a in _cygtls::call_signal_handler (this=0x43ce00) at /usr/src/debug/cygwin-1.7.30-1/winsup/cygwin/exceptions.cc:1463
> > >#10 0x0000000180111db8 in sigdelayed () from /usr/bin/cygwin1.dll
> > >#11 0x0000000100a2e832 in bss_sbrk_buffer ()
> > >#12 0x0000000000000000 in ?? ()
> > 
> > Thanks.  All I can see from this is that a SIGTERM was generated, causing
> > emacs to abort, but maybe someone else can see more.
> > 
> > Grasping at straws, as usual, I wonder if these mysterious crashes could be
> > related to a bug that Corinna just fixed:
> > 
> >   https://cygwin.com/ml/cygwin-cvs/2014-q3/msg00004.html
> > 
> > Corinna, is this plausible?  If so, maybe Gustav should try the next
> > snapshot of the Cygwin DLL.  (The current one doesn't seem to have this fix
> > in it.)
> 
> Maybe, but the signal should be SIGSEGV, not SIGTERM.  SIGTERM is 
> usually an application-created signal.

I created new snapshots on http://cygwin.com/snapshots/  They also intend
to fix a bug in calls to pthread_getattr_np and pthread_attr_getstack
which seem to raise problems in JIT environments like java, ruby, guile,
etc.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: Emacs-w32... Still Crashing

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 2094 bytes --]

On Jul  9 12:27, Corinna Vinschen wrote:
> On Jul  8 12:44, Christopher Faylor wrote:
> > On Tue, Jul 08, 2014 at 11:36:07AM -0500, Yaakov Selkowitz wrote:
> > >On 2014-07-08 10:02, Christopher Faylor wrote:
> > >> On Tue, Jul 08, 2014 at 09:55:55AM -0400, Ken Brown wrote:
> > >>> Grasping at straws, as usual, I wonder if these mysterious crashes could
> > >>> be related to a bug that Corinna just fixed:
> > >>>
> > >>>    https://cygwin.com/ml/cygwin-cvs/2014-q3/msg00004.html
> > >>>
> > >>> Corinna, is this plausible?  If so, maybe Gustav should try the next
> > >>> snapshot of the Cygwin DLL.  (The current one doesn't seem to have this
> > >>> fix in it.)
> > >>
> > >> Actually, I was scratching my head over that change and wondering
> > >> what it was supposed to solve.
> > >
> > >We believe that this was the cause of e.g. mandb aborting on x86_64 
> > >without manually enlarging the stack commit size:
> > 
> > "We"?
> 
> Yaakov and me in a discussion with integrated testing on IRC.  What are
> you trying to imply?
> 
> > Isn't that testable by setting the stack size down and putting a
> > printf in cygwin somewhere?
> > 
> > In any event, the comment in my code which is supposed to explain why
> > the tag is commented out is lacking details.  If this patch is a joint
> > effort then please add more details to the change that you made to my
> > code.
> 
> It's not your code.  The function exception::myfault_handle has been
> written by me to workaround the lack of structured exception handling in
> GCC on x86_64.
> 
> I don't understand what's unclear in this comment.  exception::myfault_handle
> is a vectored exception handler (see the comment preceeding the method)
> so it short-circuits structured exception handling.  Thus it short-circuits
> PAGE_GUARD handling, aka stack commits.

I rephrased the comment, maybe it's easier to understand this way.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: Emacs-w32... Still Crashing

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1902 bytes --]

On Jul  8 12:44, Christopher Faylor wrote:
> On Tue, Jul 08, 2014 at 11:36:07AM -0500, Yaakov Selkowitz wrote:
> >On 2014-07-08 10:02, Christopher Faylor wrote:
> >> On Tue, Jul 08, 2014 at 09:55:55AM -0400, Ken Brown wrote:
> >>> Grasping at straws, as usual, I wonder if these mysterious crashes could
> >>> be related to a bug that Corinna just fixed:
> >>>
> >>>    https://cygwin.com/ml/cygwin-cvs/2014-q3/msg00004.html
> >>>
> >>> Corinna, is this plausible?  If so, maybe Gustav should try the next
> >>> snapshot of the Cygwin DLL.  (The current one doesn't seem to have this
> >>> fix in it.)
> >>
> >> Actually, I was scratching my head over that change and wondering
> >> what it was supposed to solve.
> >
> >We believe that this was the cause of e.g. mandb aborting on x86_64 
> >without manually enlarging the stack commit size:
> 
> "We"?

Yaakov and me in a discussion with integrated testing on IRC.  What are
you trying to imply?

> Isn't that testable by setting the stack size down and putting a
> printf in cygwin somewhere?
> 
> In any event, the comment in my code which is supposed to explain why
> the tag is commented out is lacking details.  If this patch is a joint
> effort then please add more details to the change that you made to my
> code.

It's not your code.  The function exception::myfault_handle has been
written by me to workaround the lack of structured exception handling in
GCC on x86_64.

I don't understand what's unclear in this comment.  exception::myfault_handle
is a vectored exception handler (see the comment preceeding the method)
so it short-circuits structured exception handling.  Thus it short-circuits
PAGE_GUARD handling, aka stack commits.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: Emacs-w32... Still Crashing

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 2383 bytes --]

On Jul  8 09:55, Ken Brown wrote:
> On 7/7/2014 3:12 PM, Zdzislaw Meglicki wrote:
> >Program received signal SIGTRAP, Trace/breakpoint trap.
> >[Switching to Thread 4532.0xa100]
> >0x00007ff974f39e3b in KERNELBASE!DebugBreak () from /cygdrive/c/WINDOWS/system32/KERNELBASE.dll
> >(gdb) bt
> >#0  0x00007ff974f39e3b in KERNELBASE!DebugBreak () from /cygdrive/c/WINDOWS/system32/KERNELBASE.dll
> >#1  0x000000010061a7a4 in emacs_abort () at /usr/src/debug/emacs-24.3.91-1/src/w32fns.c:8474
> >#2  0x000000010043b702 in check_message_stack () at /usr/src/debug/emacs-24.3.91-1/src/xdisp.c:10993
> >#3  0x00000001004fd763 in shut_down_emacs (sig=0, stuff=4305643570) at /usr/src/debug/emacs-24.3.91-1/src/emacs.c:2042
> >#4  0x00000001004fd591 in Fkill_emacs (arg=60) at /usr/src/debug/emacs-24.3.91-1/src/emacs.c:1952
> >#5  0x00000001004fb159 in terminate_due_to_signal (sig=15, backtrace_limit=40) at /usr/src/debug/emacs-24.3.91-1/src/emacs.c:360
> >#6  0x0000000100520429 in handle_fatal_signal (sig=15) at /usr/src/debug/emacs-24.3.91-1/src/sysdep.c:1630
> >#7  0x000000010052035d in deliver_process_signal (sig=15, handler=0x100520411 ) at /usr/src/debug/emacs-24.3.91-1/src/sysdep.c:1570
> >#8  0x0000000100520444 in deliver_fatal_signal (sig=15) at /usr/src/debug/emacs-24.3.91-1/src/sysdep.c:1636
> >#9  0x0000000180070c8a in _cygtls::call_signal_handler (this=0x43ce00) at /usr/src/debug/cygwin-1.7.30-1/winsup/cygwin/exceptions.cc:1463
> >#10 0x0000000180111db8 in sigdelayed () from /usr/bin/cygwin1.dll
> >#11 0x0000000100a2e832 in bss_sbrk_buffer ()
> >#12 0x0000000000000000 in ?? ()
> 
> Thanks.  All I can see from this is that a SIGTERM was generated, causing
> emacs to abort, but maybe someone else can see more.
> 
> Grasping at straws, as usual, I wonder if these mysterious crashes could be
> related to a bug that Corinna just fixed:
> 
>   https://cygwin.com/ml/cygwin-cvs/2014-q3/msg00004.html
> 
> Corinna, is this plausible?  If so, maybe Gustav should try the next
> snapshot of the Cygwin DLL.  (The current one doesn't seem to have this fix
> in it.)

Maybe, but the signal should be SIGSEGV, not SIGTERM.  SIGTERM is 
usually an application-created signal.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: Emacs-w32... Still Crashing

[Christopher Faylor]

On Tue, Jul 08, 2014 at 11:36:07AM -0500, Yaakov Selkowitz wrote:
>On 2014-07-08 10:02, Christopher Faylor wrote:
>> On Tue, Jul 08, 2014 at 09:55:55AM -0400, Ken Brown wrote:
>>> Grasping at straws, as usual, I wonder if these mysterious crashes could
>>> be related to a bug that Corinna just fixed:
>>>
>>>    https://cygwin.com/ml/cygwin-cvs/2014-q3/msg00004.html
>>>
>>> Corinna, is this plausible?  If so, maybe Gustav should try the next
>>> snapshot of the Cygwin DLL.  (The current one doesn't seem to have this
>>> fix in it.)
>>
>> Actually, I was scratching my head over that change and wondering
>> what it was supposed to solve.
>
>We believe that this was the cause of e.g. mandb aborting on x86_64 
>without manually enlarging the stack commit size:

"We"?  Isn't that testable by setting the stack size down and putting a
printf in cygwin somewhere?

In any event, the comment in my code which is supposed to explain why
the tag is commented out is lacking details.  If this patch is a joint
effort then please add more details to the change that you made to my
code.

cgf

--
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-w32... Still Crashing

[Yaakov Selkowitz]

On 2014-07-08 10:02, Christopher Faylor wrote:
> On Tue, Jul 08, 2014 at 09:55:55AM -0400, Ken Brown wrote:
>> Grasping at straws, as usual, I wonder if these mysterious crashes could
>> be related to a bug that Corinna just fixed:
>>
>>    https://cygwin.com/ml/cygwin-cvs/2014-q3/msg00004.html
>>
>> Corinna, is this plausible?  If so, maybe Gustav should try the next
>> snapshot of the Cygwin DLL.  (The current one doesn't seem to have this
>> fix in it.)
>
> Actually, I was scratching my head over that change and wondering
> what it was supposed to solve.

We believe that this was the cause of e.g. mandb aborting on x86_64 
without manually enlarging the stack commit size:

https://cygwin.com/ml/cygwin/2014-07/msg00046.html

Perhaps those seeing emacs crashes could try `peflags -X0x20000 
/usr/bin/emacs*.exe' and see if that helps?  If so, that would confirm 
the need for this patch.


Yaakov


--
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-w32... Still Crashing

[Christopher Faylor]

On Tue, Jul 08, 2014 at 09:55:55AM -0400, Ken Brown wrote:
>On 7/7/2014 3:12 PM, Zdzislaw Meglicki wrote:
>> The current version of Emacs that I have is
>> emacs                   24.3.91-1            OK
>> emacs debuginfo         24.3.91-1            OK
>> emacs-el                24.3.91-1            OK
>> emacs-w32               24.3.91-1            OK
>> emacs-X11               24.3.91-1            OK
>>
>> Cygwin is
>> Cygwin DLL version info:
>> DLL version: 1.7.30
>> DLL epoch: 19
>> DLL old termios: 5
>> DLL malloc env: 28
>> Cygwin conv: 181
>> API major: 0
>> API minor: 272
>> Shared data: 5
>> DLL identifier: cygwin1
>> Mount registry: 3
>> Cygwin registry name: Cygwin
>> Program options name: Program Options
>> Installations name: Installations
>> Cygdrive default prefix:
>> Build date:
>> Shared id: cygwin1S5
>>
>> Windows is
>>
>> Windows 8.1 Pro on AMD A8-5500 APU, 3.20 GHz, 64-bit OS, x64 CPU
>>
>> These days, Emacs no longer crashes as often as it used to.
>
>That's good to hear.
>
>> So, there's been nothing to report until now. Emacs-w32 hanged
>> and produced the "do you want to enter debugger" window,
>> with the following backtrace produced by gdb:
>>
>> Program received signal SIGTRAP, Trace/breakpoint trap.
>> [Switching to Thread 4532.0xa100]
>> 0x00007ff974f39e3b in KERNELBASE!DebugBreak () from /cygdrive/c/WINDOWS/system32/KERNELBASE.dll
>> (gdb) bt
>> #0  0x00007ff974f39e3b in KERNELBASE!DebugBreak () from /cygdrive/c/WINDOWS/system32/KERNELBASE.dll
>> #1  0x000000010061a7a4 in emacs_abort () at /usr/src/debug/emacs-24.3.91-1/src/w32fns.c:8474
>> #2  0x000000010043b702 in check_message_stack () at /usr/src/debug/emacs-24.3.91-1/src/xdisp.c:10993
>> #3  0x00000001004fd763 in shut_down_emacs (sig=0, stuff=4305643570) at /usr/src/debug/emacs-24.3.91-1/src/emacs.c:2042
>> #4  0x00000001004fd591 in Fkill_emacs (arg=60) at /usr/src/debug/emacs-24.3.91-1/src/emacs.c:1952
>> #5  0x00000001004fb159 in terminate_due_to_signal (sig=15, backtrace_limit=40) at /usr/src/debug/emacs-24.3.91-1/src/emacs.c:360
>> #6  0x0000000100520429 in handle_fatal_signal (sig=15) at /usr/src/debug/emacs-24.3.91-1/src/sysdep.c:1630
>> #7  0x000000010052035d in deliver_process_signal (sig=15, handler=0x100520411 ) at /usr/src/debug/emacs-24.3.91-1/src/sysdep.c:1570
>> #8  0x0000000100520444 in deliver_fatal_signal (sig=15) at /usr/src/debug/emacs-24.3.91-1/src/sysdep.c:1636
>> #9  0x0000000180070c8a in _cygtls::call_signal_handler (this=0x43ce00) at /usr/src/debug/cygwin-1.7.30-1/winsup/cygwin/exceptions.cc:1463
>> #10 0x0000000180111db8 in sigdelayed () from /usr/bin/cygwin1.dll
>> #11 0x0000000100a2e832 in bss_sbrk_buffer ()
>> #12 0x0000000000000000 in ?? ()
>
>Thanks.  All I can see from this is that a SIGTERM was generated, 
>causing emacs to abort, but maybe someone else can see more.
>
>Grasping at straws, as usual, I wonder if these mysterious crashes could 
>be related to a bug that Corinna just fixed:
>
>   https://cygwin.com/ml/cygwin-cvs/2014-q3/msg00004.html
>
>Corinna, is this plausible?  If so, maybe Gustav should try the next 
>snapshot of the Cygwin DLL.  (The current one doesn't seem to have this 
>fix in it.)

Actually, I was scratching my head over that change and wondering
what it was supposed to solve.

cgf

--
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-w32... Still Crashing

[Ken Brown]

On 7/7/2014 3:12 PM, Zdzislaw Meglicki wrote:
> The current version of Emacs that I have is
> emacs                   24.3.91-1            OK
> emacs debuginfo         24.3.91-1            OK
> emacs-el                24.3.91-1            OK
> emacs-w32               24.3.91-1            OK
> emacs-X11               24.3.91-1            OK
>
> Cygwin is
> Cygwin DLL version info:
> DLL version: 1.7.30
> DLL epoch: 19
> DLL old termios: 5
> DLL malloc env: 28
> Cygwin conv: 181
> API major: 0
> API minor: 272
> Shared data: 5
> DLL identifier: cygwin1
> Mount registry: 3
> Cygwin registry name: Cygwin
> Program options name: Program Options
> Installations name: Installations
> Cygdrive default prefix:
> Build date:
> Shared id: cygwin1S5
>
> Windows is
>
> Windows 8.1 Pro on AMD A8-5500 APU, 3.20 GHz, 64-bit OS, x64 CPU
>
> These days, Emacs no longer crashes as often as it used to.

That's good to hear.

> So, there's been nothing to report until now. Emacs-w32 hanged
> and produced the "do you want to enter debugger" window,
> with the following backtrace produced by gdb:
>
> Program received signal SIGTRAP, Trace/breakpoint trap.
> [Switching to Thread 4532.0xa100]
> 0x00007ff974f39e3b in KERNELBASE!DebugBreak () from /cygdrive/c/WINDOWS/system32/KERNELBASE.dll
> (gdb) bt
> #0  0x00007ff974f39e3b in KERNELBASE!DebugBreak () from /cygdrive/c/WINDOWS/system32/KERNELBASE.dll
> #1  0x000000010061a7a4 in emacs_abort () at /usr/src/debug/emacs-24.3.91-1/src/w32fns.c:8474
> #2  0x000000010043b702 in check_message_stack () at /usr/src/debug/emacs-24.3.91-1/src/xdisp.c:10993
> #3  0x00000001004fd763 in shut_down_emacs (sig=0, stuff=4305643570) at /usr/src/debug/emacs-24.3.91-1/src/emacs.c:2042
> #4  0x00000001004fd591 in Fkill_emacs (arg=60) at /usr/src/debug/emacs-24.3.91-1/src/emacs.c:1952
> #5  0x00000001004fb159 in terminate_due_to_signal (sig=15, backtrace_limit=40) at /usr/src/debug/emacs-24.3.91-1/src/emacs.c:360
> #6  0x0000000100520429 in handle_fatal_signal (sig=15) at /usr/src/debug/emacs-24.3.91-1/src/sysdep.c:1630
> #7  0x000000010052035d in deliver_process_signal (sig=15, handler=0x100520411 ) at /usr/src/debug/emacs-24.3.91-1/src/sysdep.c:1570
> #8  0x0000000100520444 in deliver_fatal_signal (sig=15) at /usr/src/debug/emacs-24.3.91-1/src/sysdep.c:1636
> #9  0x0000000180070c8a in _cygtls::call_signal_handler (this=0x43ce00) at /usr/src/debug/cygwin-1.7.30-1/winsup/cygwin/exceptions.cc:1463
> #10 0x0000000180111db8 in sigdelayed () from /usr/bin/cygwin1.dll
> #11 0x0000000100a2e832 in bss_sbrk_buffer ()
> #12 0x0000000000000000 in ?? ()

Thanks.  All I can see from this is that a SIGTERM was generated, 
causing emacs to abort, but maybe someone else can see more.

Grasping at straws, as usual, I wonder if these mysterious crashes could 
be related to a bug that Corinna just fixed:

   https://cygwin.com/ml/cygwin-cvs/2014-q3/msg00004.html

Corinna, is this plausible?  If so, maybe Gustav should try the next 
snapshot of the Cygwin DLL.  (The current one doesn't seem to have this 
fix in it.)

Ken

--
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-w32... Still Crashing

[Zdzislaw Meglicki]

The current version of Emacs that I have is
emacs                   24.3.91-1            OK
emacs debuginfo         24.3.91-1            OK
emacs-el                24.3.91-1            OK
emacs-w32               24.3.91-1            OK
emacs-X11               24.3.91-1            OK

Cygwin is 
Cygwin DLL version info:
DLL version: 1.7.30
DLL epoch: 19
DLL old termios: 5
DLL malloc env: 28
Cygwin conv: 181
API major: 0
API minor: 272
Shared data: 5
DLL identifier: cygwin1
Mount registry: 3
Cygwin registry name: Cygwin
Program options name: Program Options
Installations name: Installations
Cygdrive default prefix:
Build date:
Shared id: cygwin1S5

Windows is 

Windows 8.1 Pro on AMD A8-5500 APU, 3.20 GHz, 64-bit OS, x64 CPU

These days, Emacs no longer crashes as often as it used to. 
So, there's been nothing to report until now. Emacs-w32 hanged
and produced the "do you want to enter debugger" window,
with the following backtrace produced by gdb:

Program received signal SIGTRAP, Trace/breakpoint trap.
[Switching to Thread 4532.0xa100]
0x00007ff974f39e3b in KERNELBASE!DebugBreak () from /cygdrive/c/WINDOWS/system32/KERNELBASE.dll 
(gdb) bt 
#0  0x00007ff974f39e3b in KERNELBASE!DebugBreak () from /cygdrive/c/WINDOWS/system32/KERNELBASE.dll 
#1  0x000000010061a7a4 in emacs_abort () at /usr/src/debug/emacs-24.3.91-1/src/w32fns.c:8474 
#2  0x000000010043b702 in check_message_stack () at /usr/src/debug/emacs-24.3.91-1/src/xdisp.c:10993 
#3  0x00000001004fd763 in shut_down_emacs (sig=0, stuff=4305643570) at /usr/src/debug/emacs-24.3.91-1/src/emacs.c:2042 
#4  0x00000001004fd591 in Fkill_emacs (arg=60) at /usr/src/debug/emacs-24.3.91-1/src/emacs.c:1952 
#5  0x00000001004fb159 in terminate_due_to_signal (sig=15, backtrace_limit=40) at /usr/src/debug/emacs-24.3.91-1/src/emacs.c:360 
#6  0x0000000100520429 in handle_fatal_signal (sig=15) at /usr/src/debug/emacs-24.3.91-1/src/sysdep.c:1630 
#7  0x000000010052035d in deliver_process_signal (sig=15, handler=0x100520411 ) at /usr/src/debug/emacs-24.3.91-1/src/sysdep.c:1570 
#8  0x0000000100520444 in deliver_fatal_signal (sig=15) at /usr/src/debug/emacs-24.3.91-1/src/sysdep.c:1636 
#9  0x0000000180070c8a in _cygtls::call_signal_handler (this=0x43ce00) at /usr/src/debug/cygwin-1.7.30-1/winsup/cygwin/exceptions.cc:1463 
#10 0x0000000180111db8 in sigdelayed () from /usr/bin/cygwin1.dll 
#11 0x0000000100a2e832 in bss_sbrk_buffer ()
#12 0x0000000000000000 in ?? () 
(gdb) 

Zdzislaw (Gustav) Meglicki
Indiana University


--
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-w32... still crashing

[Zdzislaw Meglicki]

OK, the latest crash, after the latest upgrades, 
about which in the follow up posting. I was running 
emacs-w32 under gdb. Emacs crashed on segmentation 
fault and the backtrace points to... (Emacs) alloc. 
Here it is:

Program received signal SIGSEGV, Segmentation fault.
0x00007ff9778dec8b in ?? ()
(gdb) backtrace 
#0  0x00007ff9778dec8b in ?? () 
#1  0x00007ff97582d2d6 in RtlFillMemory () from /cygdrive/c/WINDOWS/system32/KERNEL32.DLL 
#2  0x00000000004338ac in ?? () 
#3  0x0000000000000028 in ?? () 
#4  0x0000000000000028 in ?? () 
#5  0x00000001004f7ef2 in xrealloc (block=, size=25770479024) at /usr/src/debug/emacs-24.3-7/src/alloc.c:708 
#6  0x00000001005790cf in w32font_text_extents ( font=0x100fc1d58 , code=0x100fc1d58 , nglyphs=0, metrics=0x1008ab750 ) at /usr/src/debug/emacs-24.3-7/src/w32font.c:511 
#7  0x000000010041a89e in get_per_char_metric ( font=font@entry=0x100fc1d58 , char2b=) at /usr/src/debug/emacs-24.3-7/src/xdisp.c:23010 
#8  0x000000010043bcdf in x_produce_glyphs (it=0x437d10) at /usr/src/debug/emacs-24.3-7/src/xdisp.c:24787 
#9  0x00000001004258cf in move_it_in_display_line_to (it=it@entry=0x437d10, to_charpos=to_charpos@entry=21, to_x=to_x@entry=-1, op=op@entry=MOVE_TO_POS) at /usr/src/debug/emacs-24.3-7/src/xdisp.c:8337 
#10 0x000000010042d1bc in move_it_to (it=0x437d10, to_charpos=21, to_x=-1, to_y=-1, to_vpos=-1, op=8) at /usr/src/debug/emacs-24.3-7/src/xdisp.c:8895 
#11 0x000000010043234c in resize_mini_window ( w=w@entry=0x100f7fc60 , exact_p=exact_p@entry=0) at /usr/src/debug/emacs-24.3-7/src/xdisp.c:10404 
#12 0x00000001004324d2 in display_echo_area_1 (a1=4311219296, a2=, a3=, a4=) at /usr/src/debug/emacs-24.3-7/src/xdisp.c:10269 
#13 0x0000000100418a90 in with_echo_area_buffer ( w=w@entry=0x100f7fc60 , which=, fn=fn@entry=0x1004324c0 , a1=a1@entry=4311219296, a2=a2@entry=4304630834, a3=a3@entry=0, a4=a4@entry=0) at /usr/src/debug/emacs-24.3-7/src/xdisp.c:10062 
#14 0x0000000100436de2 in display_echo_area ( w=0x100f7fc60 ) at /usr/src/debug/emacs-24.3-7/src/xdisp.c:10239 
#15 echo_area_display (update_frame_p=update_frame_p@entry=0) at /usr/src/debug/emacs-24.3-7/src/xdisp.c:10827 
#16 0x0000000100435d97 in redisplay_internal () at /usr/src/debug/emacs-24.3-7/src/xdisp.c:13176 
#17 0x0000000100437d16 in redisplay_preserve_echo_area ( from_where=) at /usr/src/debug/emacs-24.3-7/src/xdisp.c:13750
#
18 0x00000001004aa2da in detect_input_pending_run_timers ( do_display=do_display@entry=true) 
#19 0x0000000100551406 in wait_reading_process_output ( time_limit=time_limit@entry=0, nsecs=nsecs@entry=0, read_kbd=read_kbd@entry=-1, do_display=do_display@entry=true, wait_for_cell=wait_for_cell@entry=4304630834, wait_proc=wait_proc@entry=0x0, just_wait_proc=just_wait_proc@entry=0) at /usr/src/debug/emacs-24.3-7/src/process.c:4743 
#20 0x00000001004ab2ae in kbd_buffer_get_event (end_time=0x0, used_mouse_menu=0x43a2c7, kbp=) at /usr/src/debug/emacs-24.3-7/src/keyboard.c:3803 
#21 read_char (commandflag=1, nmaps=2, maps=0x43a1a0, prev_event=4304630834, used_mouse_menu=0x43a2c7, end_time=end_time@entry=0x0) at /usr/src/debug/emacs-24.3-7/src/keyboard.c:2769 
#22 0x00000001004ad463 in read_key_sequence (keybuf=keybuf@entry=0x43a410, prompt=, dont_downcase_last=dont_downcase_last@entry=false, can_return_switch_frame=can_return_switch_frame@entry=true, fix_current_buffer=fix_current_buffer@entry=true, bufsize=30) at /usr/src/debug/emacs-24.3-7/src/keyboard.c:9231 
#23 0x00000001004af75e in command_loop_1 () at /usr/src/debug/emacs-24.3-7/src/keyboard.c:1459 
#24 0x0000000100510cde in internal_condition_case ( bfun=bfun@entry=0x1004af540 , handlers=4304832354, hfun=hfun@entry=0x1004a58a0 ) 
at /usr/src/debug/emacs-24.3-7/src/eval.c:1289 
#25 0x00000001004a09da in command_loop_2 (ignore=ignore@entry=4304630834) at /usr/src/debug/emacs-24.3-7/src/keyboard.c:1168 
#26 0x0000000100510b9f in internal_catch (tag=, func=func@entry=0x1004a09b0 , arg=4304630834) at /usr/src/debug/emacs-24.3-7/src/eval.c:1060 
#27 0x00000001004a5374 in command_loop () at /usr/src/debug/emacs-24.3-7/src/keyboard.c:1147 
#28 recursive_edit_1 () at /usr/src/debug/emacs-24.3-7/src/keyboard.c:779 
#29 0x00000001004a56a7 in Frecursive_edit () at /usr/src/debug/emacs-24.3-7/src/keyboard.c:843
#30 0x00000001005ab7d3 in main (argc=, argv=) at /usr/src/debug/emacs-24.3-7/src/emacs.c:1532 

Other problems... gdb hangs on quit after the program it was supervising was stopped and killed. Killing the Cygwin window from 
the ask manager stuffs up things so bad, hat Cygwin terminal can no longer be restarted. I only get the message:

   Failed to fork child process: No such file or directory. 

A log-off, log-on is required.

Gustav Meglicki,
Indiana University


--
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-w32... still crashing

[Csaba Raduly]

On Thu, Jun 5, 2014 at 9:51 PM, Christopher Faylor  wrote:
> On Thu, Jun 05, 2014 at 03:05:43PM -0400, Ken Brown wrote:
>>On 6/3/2014 6:00 PM, Zdzislaw Meglicki wrote:
>>> And... another crash. I didn't run it under gdb this
>>> time and it didn't dump anything either, but I got
>>> interesting new message I didn't see before:
>>>
>>> *** fatal error - WFSO failed waiting for timer thread, Win32 error 0
>>
>>This message comes from the function timer_tracker::cancel in timer.cc
>>in the Cygwin sources.  I'm afraid I have no idea what the timer thread
>>is or why WaitForSingleObject might fail waiting for it.
>>
>>cgf or Corinna (or anyone else), can you shed any light on what might
>>cause this?  Could it be BLODA, for instance?
>
> I really don't see how WaitForSingleObject can fail like this but I have
> demoted that fatal condition to a warning and added slightly more
> debugging output to it.
(snip)

That doesn't seem right. If the return code is WAIT_FAILED, api_fatal
*should* be called (which presumably calls GetLastError).
Other return values like WAIT_ABANDONED or WAIT_TIMEOUT can be let off
with a system_printf.

Csaba
-- 
GCS a+ e++ d- C++ ULS$ L+$ !E- W++ P+++$ w++$ tv+ b++ DI D++ 5++
The Tao of math: The numbers you can count are not the real numbers.
Life is complex, with real and imaginary parts.
"Ok, it boots. Which means it must be bug-free and perfect. " -- Linus Torvalds
"People disagree with me. I just ignore them." -- Linus Torvalds

--
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-w32... still crashing

[Ken Brown]

On 6/5/2014 3:51 PM, Christopher Faylor wrote:
> On Thu, Jun 05, 2014 at 03:05:43PM -0400, Ken Brown wrote:
>> On 6/3/2014 6:00 PM, Zdzislaw Meglicki wrote:
>>> And... another crash. I didn't run it under gdb this
>>> time and it didn't dump anything either, but I got
>>> interesting new message I didn't see before:
>>>
>>> *** fatal error - WFSO failed waiting for timer thread, Win32 error 0
>>
>> This message comes from the function timer_tracker::cancel in timer.cc
>> in the Cygwin sources.  I'm afraid I have no idea what the timer thread
>> is or why WaitForSingleObject might fail waiting for it.
>>
>> cgf or Corinna (or anyone else), can you shed any light on what might
>> cause this?  Could it be BLODA, for instance?
>
> I really don't see how WaitForSingleObject can fail like this but I have
> demoted that fatal condition to a warning and added slightly more
> debugging output to it.  The next snapshot will have that change.

Thanks.  Gustav, can you install the latest snapshot?  That might help 
debug this in case you get that WFSO failure again.

Ken


--
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-w32... still crashing

[Christopher Faylor]

On Thu, Jun 05, 2014 at 03:05:43PM -0400, Ken Brown wrote:
>On 6/3/2014 6:00 PM, Zdzislaw Meglicki wrote:
>> And... another crash. I didn't run it under gdb this
>> time and it didn't dump anything either, but I got
>> interesting new message I didn't see before:
>>
>> *** fatal error - WFSO failed waiting for timer thread, Win32 error 0
>
>This message comes from the function timer_tracker::cancel in timer.cc 
>in the Cygwin sources.  I'm afraid I have no idea what the timer thread 
>is or why WaitForSingleObject might fail waiting for it.
>
>cgf or Corinna (or anyone else), can you shed any light on what might 
>cause this?  Could it be BLODA, for instance?

I really don't see how WaitForSingleObject can fail like this but I have
demoted that fatal condition to a warning and added slightly more
debugging output to it.  The next snapshot will have that change.

cgf

--
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-w32... still crashing

[Ken Brown]

On 6/3/2014 6:00 PM, Zdzislaw Meglicki wrote:
> And... another crash. I didn't run it under gdb this
> time and it didn't dump anything either, but I got
> interesting new message I didn't see before:
>
> *** fatal error - WFSO failed waiting for timer thread, Win32 error 0

This message comes from the function timer_tracker::cancel in timer.cc 
in the Cygwin sources.  I'm afraid I have no idea what the timer thread 
is or why WaitForSingleObject might fail waiting for it.

cgf or Corinna (or anyone else), can you shed any light on what might 
cause this?  Could it be BLODA, for instance?

We're seeing these strange crashes only on 64-bit Cygwin, FWIW.

Ken

--
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-w32... still crashing

[Zdzislaw Meglicki]

This is just to confirm: I had a yet another crash,
was running my emacs session under gdb and captured
the event. The trace is the same as before, that is,
there is a problem in deselect_palette that causes
segmentation fault.

Yes, I will report the bug to Emacs maintainers.

Zdzislaw (Gustav) Meglicki
Indiana University

--
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-w32... still crashing

[Ken Brown]

On 6/3/2014 4:01 PM, Zdzislaw Meglicki wrote:
> And another crash... captured under gdb again.
> Segmentation fault again, but this time:
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x0000000100631d84 in deselect_palette (f=0x0, hdc=0x0) at /usr/src/debug/emacs-24.3.90-1/src/w32xfns.c:123
> 123       if (f->output_data.w32->old_palette)
>
> and the backtrace shows the following:
>
> (gdb) backtrace
> #0  0x0000000100631d84 in deselect_palette (f=0x0, hdc=0x0) at /usr/src/debug/emacs-24.3.90-1/src/w32xfns.c:123
> #1  0x0000000100631e53 in release_frame_dc (f=0x0, hdc=0x0) at /usr/src/debug/emacs-24.3.90-1/src/w32xfns.c:154
> #2  0x00000001006351f9 in uniscribe_encode_char ( font=0x101071d30 , c=99) at /usr/src/debug/emacs-24.3.90-1/src/w32uniscribe.c:585
> #3  0x0000000100462d9b in get_char_glyph_code (c=99, font=0x101071d30 , char2b=0x434726 L"") at /usr/src/debug/emacs-24.3.90-1/src/xdisp.c:23697
> #4  0x000000010046b995 in x_produce_glyphs (it=0x435790) at /usr/src/debug/emacs-24.3.90-1/src/xdisp.c:25806
> #5  0x00000001004572c5 in display_line (it=0x435790) at /usr/src/debug/emacs-24.3.90-1/src/xdisp.c:19963
> #6  0x000000010044c7b4 in try_window (window=4312112205, pos=..., flags=0) at /usr/src/debug/emacs-24.3.90-1/src/xdisp.c:16708
> #7  0x000000010044937a in redisplay_window (window=4312112205, just_this_one_p=true) at /usr/src/debug/emacs-24.3.90-1/src/xdisp.c:15983
> #8  0x0000000100442ccb in redisplay_window_1 (window=4312112205) at /usr/src/debug/emacs-24.3.90-1/src/xdisp.c:14188
> #9  0x00000001005968ac in internal_condition_case_1 ( bfun=0x100442c8c , arg=4312112205, handlers=4305621542, hfun=0x100442c09 ) at /usr/src/debug/emacs-24.3.90-1/src/eval.c:1378
> #10 0x00000001004420a5 in redisplay_internal () at /usr/src/debug/emacs-24.3.90-1/src/xdisp.c:13834
> #11 0x0000000100442606 in redisplay_preserve_echo_area (from_where=2) at /usr/src/debug/emacs-24.3.90-1/src/xdisp.c:14017
> #12 0x000000010040e024 in Fredisplay (force=4305639474) at /usr/src/debug/emacs-24.3.90-1/src/dispnew.c:5834
> #13 0x0000000100599b62 in Ffuncall (nargs=1, args=0x439140) at /usr/src/debug/emacs-24.3.90-1/src/eval.c:2815
> #14 0x00000001005dcaa2 in exec_byte_code (bytestr=4301839321, vector=4301839357, maxdepth=28, args_template=3076, nargs=1, args=0x4396c8) at /usr/src/debug/emacs-24.3.90-1/src/bytecode.c:919
> #15 0x000000010059a286 in funcall_lambda (fun=4301839277, nargs=1, arg_vector=0x4396c0) at /usr/src/debug/emacs-24.3.90-1/src/eval.c:2983
> #16 0x0000000100599d77 in Ffuncall (nargs=2, args=0x4396b8) at /usr/src/debug/emacs-24.3.90-1/src/eval.c:2864
> #17 0x00000001005dcaa2 in exec_byte_code (bytestr=4303055217, vector=4303055253, maxdepth=16, args_template=4305639474, nargs=0, args=0x0) at /usr/src/debug/emacs-24.3.90-1/src/bytecode.c:919
> #18 0x000000010059a5a0 in funcall_lambda (fun=4303055165, nargs=1, arg_vector=0x1007b6995 ) at /usr/src/debug/emacs-24.3.90-1/src/eval.c:3049
> #19 0x0000000100599d77 in Ffuncall (nargs=2, args=0x439c90) at /usr/src/debug/emacs-24.3.90-1/src/eval.c:2864
> #20 0x0000000100593cfb in Fcall_interactively (function=4310211282, record_flag=4305639474, keys=25777929493) at /usr/src/debug/emacs-24.3.90-1/src/callint.c:836
> #21 0x0000000100599bb3 in Ffuncall (nargs=4, args=0x439fc8) at /usr/src/debug/emacs-24.3.90-1/src/eval.c:2822
> #22 0x00000001005dcaa2 in exec_byte_code (bytestr=4302634489, vector=4302634525, maxdepth=52, args_template=4100, nargs=1, args=0x43a560) at /usr/src/debug/emacs-24.3.90-1/src/bytecode.c:919
> #23 0x000000010059a286 in funcall_lambda (fun=4302634445, nargs=1, arg_vector=0x43a558) at /usr/src/debug/emacs-24.3.90-1/src/eval.c:2983
> #24 0x0000000100599d77 in Ffuncall (nargs=2, args=0x43a550) at /usr/src/debug/emacs-24.3.90-1/src/eval.c:2864
> #25 0x00000001005994ca in call1 (fn=4305696770, arg1=4310211282) at /usr/src/debug/emacs-24.3.90-1/src/eval.c:2614
> #26 0x0000000100500128 in command_loop_1 () at /usr/src/debug/emacs-24.3.90-1/src/keyboard.c:1556
> #27 0x0000000100596707 in internal_condition_case ( bfun=0x1004ff821 , handlers=4305705682, hfun=0x1004fef62 ) at /usr/src/debug/emacs-24.3.90-1/src/eval.c:1354
> #28 0x00000001004ff4e5 in command_loop_2 (ignore=4305639474) at /usr/src/debug/emacs-24.3.90-1/src/keyboard.c:1174
> #29 0x0000000100595e81 in internal_catch (tag=4305695746, func=0x1004ff4b3 , arg=4305639474) at /usr/src/debug/emacs-24.3.90-1/src/eval.c:1118
> #30 0x00000001004ff474 in command_loop () at /usr/src/debug/emacs-24.3.90-1/src/keyboard.c:1153
> #31 0x00000001004feadf in recursive_edit_1 () at /usr/src/debug/emacs-24.3.90-1/src/keyboard.c:777
> #32 0x00000001004fec83 in Frecursive_edit () at /usr/src/debug/emacs-24.3.90-1/src/keyboard.c:845
> #33 0x00000001004fca49 in main (argc=2, argv=0x43ab00) at /usr/src/debug/emacs-24.3.90-1/src/emacs.c:1646
>

Would you mind making an emacs bug report (M-x report-emacs-bug)?  For 
the first time, this looks like a backtrace that the emacs experts might 
be able to make sense out of.

In the future, it would help debug these crashes if you would follow the 
three steps I suggested at the end of

   https://cygwin.com/ml/cygwin/2014-05/msg00397.html

Thanks.

Ken

--
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-w32... still crashing

[Zdzislaw Meglicki]

And... another crash. I didn't run it under gdb this
time and it didn't dump anything either, but I got
interesting new message I didn't see before:

*** fatal error - WFSO failed waiting for timer thread, Win32 error 0

Interesting? Perhaps all these crashes have something to
do with the timer?

Zdzislaw (Gustav) Meglicki
Indiana University


--
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-w32... still crashing

[Larry Hall (Cygwin)]

On 06/03/2014 04:01 PM, Zdzislaw Meglicki wrote:
> And another crash... captured under gdb again.
> Segmentation fault again, but this time:
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x0000000100631d84 in deselect_palette (f=0x0, hdc=0x0) at /usr/src/debug/emacs-24.3.90-1/src/w32xfns.c:123
> 123       if (f->output_data.w32->old_palette)

And, unlike the last one that crashed somewhere deep down under Cygwin in
O/S calls, this one never touches the Cygwin DLL.  This suggests to me
that this particular problem is shared with any non-Cygwin version of
Emacs-w32.  You may want to check for possible solutions in other forums
as well as a result.

Disclaimer - I do not use emacs in any form.


-- 
Larry

_____________________________________________________________________

A: Yes.
 > Q: Are you sure?
 >> A: Because it reverses the logical flow of conversation.
 >>> Q: Why is top posting annoying in email?

--
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-w32... still crashing

[Zdzislaw Meglicki]

And another crash... captured under gdb again.
Segmentation fault again, but this time:

Program received signal SIGSEGV, Segmentation fault.
0x0000000100631d84 in deselect_palette (f=0x0, hdc=0x0) at /usr/src/debug/emacs-24.3.90-1/src/w32xfns.c:123
123       if (f->output_data.w32->old_palette) 

and the backtrace shows the following:

(gdb) backtrace 
#0  0x0000000100631d84 in deselect_palette (f=0x0, hdc=0x0) at /usr/src/debug/emacs-24.3.90-1/src/w32xfns.c:123 
#1  0x0000000100631e53 in release_frame_dc (f=0x0, hdc=0x0) at /usr/src/debug/emacs-24.3.90-1/src/w32xfns.c:154 
#2  0x00000001006351f9 in uniscribe_encode_char ( font=0x101071d30 , c=99) at /usr/src/debug/emacs-24.3.90-1/src/w32uniscribe.c:585 
#3  0x0000000100462d9b in get_char_glyph_code (c=99, font=0x101071d30 , char2b=0x434726 L"") at /usr/src/debug/emacs-24.3.90-1/src/xdisp.c:23697 
#4  0x000000010046b995 in x_produce_glyphs (it=0x435790) at /usr/src/debug/emacs-24.3.90-1/src/xdisp.c:25806 
#5  0x00000001004572c5 in display_line (it=0x435790) at /usr/src/debug/emacs-24.3.90-1/src/xdisp.c:19963 
#6  0x000000010044c7b4 in try_window (window=4312112205, pos=..., flags=0) at /usr/src/debug/emacs-24.3.90-1/src/xdisp.c:16708 
#7  0x000000010044937a in redisplay_window (window=4312112205, just_this_one_p=true) at /usr/src/debug/emacs-24.3.90-1/src/xdisp.c:15983 
#8  0x0000000100442ccb in redisplay_window_1 (window=4312112205) at /usr/src/debug/emacs-24.3.90-1/src/xdisp.c:14188 
#9  0x00000001005968ac in internal_condition_case_1 ( bfun=0x100442c8c , arg=4312112205, handlers=4305621542, hfun=0x100442c09 ) at /usr/src/debug/emacs-24.3.90-1/src/eval.c:1378 
#10 0x00000001004420a5 in redisplay_internal () at /usr/src/debug/emacs-24.3.90-1/src/xdisp.c:13834 
#11 0x0000000100442606 in redisplay_preserve_echo_area (from_where=2) at /usr/src/debug/emacs-24.3.90-1/src/xdisp.c:14017 
#12 0x000000010040e024 in Fredisplay (force=4305639474) at /usr/src/debug/emacs-24.3.90-1/src/dispnew.c:5834 
#13 0x0000000100599b62 in Ffuncall (nargs=1, args=0x439140) at /usr/src/debug/emacs-24.3.90-1/src/eval.c:2815 
#14 0x00000001005dcaa2 in exec_byte_code (bytestr=4301839321, vector=4301839357, maxdepth=28, args_template=3076, nargs=1, args=0x4396c8) at /usr/src/debug/emacs-24.3.90-1/src/bytecode.c:919 
#15 0x000000010059a286 in funcall_lambda (fun=4301839277, nargs=1, arg_vector=0x4396c0) at /usr/src/debug/emacs-24.3.90-1/src/eval.c:2983 
#16 0x0000000100599d77 in Ffuncall (nargs=2, args=0x4396b8) at /usr/src/debug/emacs-24.3.90-1/src/eval.c:2864 
#17 0x00000001005dcaa2 in exec_byte_code (bytestr=4303055217, vector=4303055253, maxdepth=16, args_template=4305639474, nargs=0, args=0x0) at /usr/src/debug/emacs-24.3.90-1/src/bytecode.c:919 
#18 0x000000010059a5a0 in funcall_lambda (fun=4303055165, nargs=1, arg_vector=0x1007b6995 ) at /usr/src/debug/emacs-24.3.90-1/src/eval.c:3049 
#19 0x0000000100599d77 in Ffuncall (nargs=2, args=0x439c90) at /usr/src/debug/emacs-24.3.90-1/src/eval.c:2864 
#20 0x0000000100593cfb in Fcall_interactively (function=4310211282, record_flag=4305639474, keys=25777929493) at /usr/src/debug/emacs-24.3.90-1/src/callint.c:836 
#21 0x0000000100599bb3 in Ffuncall (nargs=4, args=0x439fc8) at /usr/src/debug/emacs-24.3.90-1/src/eval.c:2822 
#22 0x00000001005dcaa2 in exec_byte_code (bytestr=4302634489, vector=4302634525, maxdepth=52, args_template=4100, nargs=1, args=0x43a560) at /usr/src/debug/emacs-24.3.90-1/src/bytecode.c:919 
#23 0x000000010059a286 in funcall_lambda (fun=4302634445, nargs=1, arg_vector=0x43a558) at /usr/src/debug/emacs-24.3.90-1/src/eval.c:2983 
#24 0x0000000100599d77 in Ffuncall (nargs=2, args=0x43a550) at /usr/src/debug/emacs-24.3.90-1/src/eval.c:2864 
#25 0x00000001005994ca in call1 (fn=4305696770, arg1=4310211282) at /usr/src/debug/emacs-24.3.90-1/src/eval.c:2614 
#26 0x0000000100500128 in command_loop_1 () at /usr/src/debug/emacs-24.3.90-1/src/keyboard.c:1556 
#27 0x0000000100596707 in internal_condition_case ( bfun=0x1004ff821 , handlers=4305705682, hfun=0x1004fef62 ) at /usr/src/debug/emacs-24.3.90-1/src/eval.c:1354
#28 0x00000001004ff4e5 in command_loop_2 (ignore=4305639474) at /usr/src/debug/emacs-24.3.90-1/src/keyboard.c:1174 
#29 0x0000000100595e81 in internal_catch (tag=4305695746, func=0x1004ff4b3 , arg=4305639474) at /usr/src/debug/emacs-24.3.90-1/src/eval.c:1118 
#30 0x00000001004ff474 in command_loop () at /usr/src/debug/emacs-24.3.90-1/src/keyboard.c:1153 
#31 0x00000001004feadf in recursive_edit_1 () at /usr/src/debug/emacs-24.3.90-1/src/keyboard.c:777 
#32 0x00000001004fec83 in Frecursive_edit () at /usr/src/debug/emacs-24.3.90-1/src/keyboard.c:845 
#33 0x00000001004fca49 in main (argc=2, argv=0x43ab00) at /usr/src/debug/emacs-24.3.90-1/src/emacs.c:1646 

--
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-w32... still crashing

[Zdzislaw Meglicki]

This time we've been running it under gdb and
I managed to capture the crash. It aborted 
upon having received SIGABRT, and printed the
following:

Program received signal SIGABRT, Aborted.
0x000000010064ed67 in xg_select (fds_lim=4428800, rfds= 0x1800c46cd , wfds=0x4392e0, efds=0x439a90, timeout=0x439aa0, sigmask=0x4392e0) at /usr/src/debug/emacs-24.3.90-1/src/xgselect.c:99
99        nfds = pselect (fds_lim, &all_rfds, have_wfds ? &all_wfds : NULL, 

And here is the backtrace:

(gdb) backtrace 
#0  0x000000010064ed67 in xg_select (fds_lim=4428800, rfds=0x1800c46cd , wfds=0x4392e0, efds=0x439a90, timeout=0x439aa0, sigmask=0x4392e0) at /usr/src/debug/emacs-24.3.90-1/src/xgselect.c:99 
#1  0x000000018010c54a in select_stuff::cleanup (this=0xea60, this@entry=0x4392e0) at /usr/src/debug/cygwin-1.7.29-2/winsup/cygwin/select.cc:261 
#2  0x000000018010d02b in select (maxfds=maxfds@entry=11, readfds=0x1, writefds=0x439a00, writefds@entry=0x439a90, exceptfds=0x888, ms=, ms@entry=499) at /usr/src/debug/cygwin-1.7.29-2/winsup/cygwin/select.cc:200 
#3  0x000000018010d5c4 in cygwin_select (maxfds=maxfds@entry=11, readfds=readfds@entry=0x439aa0, writefds=writefds@entry=0x439a90, exceptfds=exceptfds@entry=0x0, to=0x4394b0) at /usr/src/debug/cygwin-1.7.29-2/winsup/cygwin/select.cc:120 
#4  0x000000018010d90a in pselect (maxfds=11, readfds=0x439aa0, writefds=0x439a90, exceptfds=0x0, ts=0x439c00, set=0x0) at /usr/src/debug/cygwin-1.7.29-2/winsup/cygwin/select.cc:244 
#5  0x000000018011197b in _sigfe () from /usr/bin/cygwin1.dll 
#6  0x00000000004396b0 in ?? () 
#7  0x000000010059ad98 in unbind_to (count=4434748, value=140708849620591) at /usr/src/debug/emacs-24.3.90-1/src/eval.c:3326 
#8  0x0000000000000001 in ?? ()
---Type to continue, or q to quit--- 
#9  0x000000000043ab3c in ?? () 
#10 0x00007ff954ff966f in KERNELBASE!GetSystemTimePreciseAsFileTime () from /cygdrive/c/WINDOWS/system32/KERNELBASE.dll 
#11 0x000004b78f1a6ecc in ?? () 
#12 0x0000000000439720 in ?? () 
#13 0x0000000000439830 in ?? () 
#14 0x0000000000000004 in ?? () 
#15 0x0000000000439860 in ?? () 
#16 0x000000018013dee5 in get_system_time (systime=0x439720) at /usr/src/debug/cygwin-1.7.29-2/winsup/cygwin/times.cc:41 
#17 hires_ms::nsecs (this=) at /usr/src/debug/cygwin-1.7.29-2/winsup/cygwin/times.cc:497 
#18 0x00007ff957c10f77 in ?? () 
#19 0x0000000000439770 in ?? () 
#20 0x00000001004f76f7 in XSETCDR ( c=, n=) at /usr/src/debug/emacs-24.3.90-1/src/lisp.h:1027
Backtrace stopped: previous frame inner to this frame (corrupt stack?) 
(gdb) 

--
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-w32... still crashing...

[Ken Brown]

On 5/19/2014 10:42 AM, Ken Brown wrote:
> On 5/19/2014 9:20 AM, Zdzislaw Meglicki wrote:
>> (gdb) backtrace
>> #0  0x00007ff9550c9e3b in KERNELBASE!DebugBreak ()
>> from /cygdrive/c/WINDOWS/system32/KERNELBASE.dll
>> #1  0x000000010061a344 in emacs_abort ()
>> at /usr/src/debug/emacs-24.3.90-1/src/w32fns.c:8460
>> #2  0x000000010057e7ce in arithcompare (num1=0, num2=4000000,
>> comparison=ARITH_GRTR_OR_EQUAL)
>> at /usr/src/debug/emacs-24.3.90-1/src/data.c:2319
>
> Thanks. These crashes are very mysterious to me.  Two of them have
> recently been reported to the emacs bug tracker, including one by me a
> couple hours ago:
>
>    http://debbugs.gnu.org/cgi/bugreport.cgi?bug=17526
>

FYI, this turned out to be an emacs bug that had nothing to do with 
Cygwin and is now apparently fixed.  Your crash, on the other hand, 
remains mysterious.

Ken

--
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-w32... still crashing...

[Ken Brown]

On 5/19/2014 9:20 AM, Zdzislaw Meglicki wrote:
> I got it this time. It crashed on me just a few seconds after I started it,
> while reading mail with rmail. This time I had the right debug info
> installed for this version of emacs and here is the backtrace:
>
> =============================================
> (gdb) backtrace
> #0  0x00007ff9550c9e3b in KERNELBASE!DebugBreak ()
> from /cygdrive/c/WINDOWS/system32/KERNELBASE.dll
> #1  0x000000010061a344 in emacs_abort ()
> at /usr/src/debug/emacs-24.3.90-1/src/w32fns.c:8460
> #2  0x000000010057e7ce in arithcompare (num1=0, num2=4000000,
> comparison=ARITH_GRTR_OR_EQUAL)
> at /usr/src/debug/emacs-24.3.90-1/src/data.c:2319
> #3  0x00000001005df264 in exec_byte_code (bytestr=25771187393,
> vector=4312129309, maxdepth=28, args_template=4305639474, nargs=0,
> args=0x0) at /usr/src/debug/emacs-24.3.90-1/src/bytecode.c:1468
> #4  0x000000010059a5a0 in funcall_lambda (fun=4309134989, nargs=2,
> arg_vector=0x10105df1d <bss_sbrk_buffer+6847133>)
> at /usr/src/debug/emacs-24.3.90-1/src/eval.c:3049
> #5  0x0000000100599d77 in Ffuncall (nargs=3, args=0x4387d8)
> at /usr/src/debug/emacs-24.3.90-1/src/eval.c:2864
> #6  0x00000001005dcaa2 in exec_byte_code (bytestr=4303067497,
> vector=4303067533, maxdepth=24, args_template=4305639474, nargs=0,
> args=0x0) at /usr/src/debug/emacs-24.3.90-1/src/bytecode.c:919
> #7  0x000000010059a5a0 in funcall_lambda (fun=4303067373, nargs=4,
> arg_vector=0x1007b998d <pure+1353837>)
> at /usr/src/debug/emacs-24.3.90-1/src/eval.c:3049
> #8  0x0000000100599d77 in Ffuncall (nargs=5, args=0x438d78)
> at /usr/src/debug/emacs-24.3.90-1/src/eval.c:2864
> #9  0x00000001005dcaa2 in exec_byte_code (bytestr=4303067977,
> vector=4303068013, maxdepth=28, args_template=4305639474, nargs=0,
> args=0x0) at /usr/src/debug/emacs-24.3.90-1/src/bytecode.c:919
> #10 0x000000010059a5a0 in funcall_lambda (fun=4303067917, nargs=3,
> arg_vector=0x1007b9b6d <pure+1354317>)
> at /usr/src/debug/emacs-24.3.90-1/src/eval.c:3049
> #11 0x0000000100599d77 in Ffuncall (nargs=4, args=0x4392f8)
> at /usr/src/debug/emacs-24.3.90-1/src/eval.c:2864
> #12 0x00000001005dcaa2 in exec_byte_code (bytestr=4303070921,
> vector=4303070957, maxdepth=20, args_template=4305639474, nargs=0,
> args=0x0) at /usr/src/debug/emacs-24.3.90-1/src/bytecode.c:919
> #13 0x000000010059a5a0 in funcall_lambda (fun=4303070877, nargs=1,
> arg_vector=0x1007ba6ed <pure+1357261>)
> at /usr/src/debug/emacs-24.3.90-1/src/eval.c:3049
> #14 0x0000000100599d77 in Ffuncall (nargs=2, args=0x439870)
> at /usr/src/debug/emacs-24.3.90-1/src/eval.c:2864
> #15 0x00000001005994ca in call1 (fn=4305692866, arg1=4313865909)
> at /usr/src/debug/emacs-24.3.90-1/src/eval.c:2614
> #16 0x0000000100506af0 in timer_check_2 (timers=25776357158,
> idle_timers=4305639474)
> at /usr/src/debug/emacs-24.3.90-1/src/keyboard.c:4510
> #17 0x0000000100506c89 in timer_check ()
> at /usr/src/debug/emacs-24.3.90-1/src/keyboard.c:4577
> #18 0x0000000100504b4b in readable_events (flags=1)
> at /usr/src/debug/emacs-24.3.90-1/src/keyboard.c:3444
> #19 0x000000010050afe4 in get_input_pending (flags=1)
> at /usr/src/debug/emacs-24.3.90-1/src/keyboard.c:6761
> #20 0x0000000100511142 in detect_input_pending_run_timers (do_display=true)
> at /usr/src/debug/emacs-24.3.90-1/src/keyboard.c:9884
> #21 0x00000001005e9939 in wait_reading_process_output (time_limit=30, nsecs=0,
> read_kbd=-1, do_display=true, wait_for_cell=4305639474, wait_proc=0x0,
> just_wait_proc=0) at /usr/src/debug/emacs-24.3.90-1/src/process.c:4699
> #22 0x000000010040df39 in sit_for (timeout=120, reading=true, display_option=1)
> at /usr/src/debug/emacs-24.3.90-1/src/dispnew.c:5805
> #23 0x0000000100503226 in read_char (commandflag=1, map=25776355574,
> prev_event=4305639474, used_mouse_menu=0x43a3ff, end_time=0x0)
> at /usr/src/debug/emacs-24.3.90-1/src/keyboard.c:2806
> #24 0x000000010050f622 in read_key_sequence (keybuf=0x43a610, bufsize=30,
> prompt=4305639474, dont_downcase_last=false, can_return_switch_frame=true,
> fix_current_buffer=true, prevent_redisplay=false)
> at /usr/src/debug/emacs-24.3.90-1/src/keyboard.c:9079
> #25 0x00000001004ffcf3 in command_loop_1 ()
> at /usr/src/debug/emacs-24.3.90-1/src/keyboard.c:1449
> #26 0x0000000100596707 in internal_condition_case (
> bfun=0x1004ff821 <command_loop_1>, handlers=4305705682,
> hfun=0x1004fef62 <cmd_error>)
> at /usr/src/debug/emacs-24.3.90-1/src/eval.c:1354
> #27 0x00000001004ff4e5 in command_loop_2 (ignore=4305639474)
> at /usr/src/debug/emacs-24.3.90-1/src/keyboard.c:1174
> #28 0x0000000100595e81 in internal_catch (tag=4305695746,
> func=0x1004ff4b3 <command_loop_2>, arg=4305639474)
> at /usr/src/debug/emacs-24.3.90-1/src/eval.c:1118
> #29 0x00000001004ff474 in command_loop ()
> at /usr/src/debug/emacs-24.3.90-1/src/keyboard.c:1153
> #30 0x00000001004feadf in recursive_edit_1 ()
> at /usr/src/debug/emacs-24.3.90-1/src/keyboard.c:777
> #31 0x00000001004fec83 in Frecursive_edit ()
> at /usr/src/debug/emacs-24.3.90-1/src/keyboard.c:845
> #32 0x00000001004fca49 in main (argc=2, argv=0x43ab30)
> at /usr/src/debug/emacs-24.3.90-1/src/emacs.c:1646
> (gdb)
>
> ================================================

Thanks. These crashes are very mysterious to me.  Two of them have 
recently been reported to the emacs bug tracker, including one by me a 
couple hours ago:

   http://debbugs.gnu.org/cgi/bugreport.cgi?bug=17526

Unfortunately, nothing in the backtrace (yours or mine) is giving me any 
clue.  Maybe someone more knowledgeable, especially about the Cygwin-w32 
build, will have some ideas.  (Daniel?)

For future reference, here are some suggestions:

1. Once you've started gdb, give the command "source 
/usr/share/emacs/24.3.90/etc/.gdbinit".  This defines some gdb commands 
that are useful for debugging emacs.  Among other things, this will 
cause the "backtrace" command to include a lisp backtrace.

2. After getting a backtrace and reporting it somewhere (see item 3 
below), keep the gdb session open, if possible, in case someone wants 
you to try to get more info.

3. If you are willing to help debug these crashes, send your backtraces 
as emacs bug reports instead of sending them to this list.  You can do 
that easily via the command `M-x report-emacs-bug' within emacs, or you 
can just send email to bug-gnu-emacs@gnu.org.

Ken

--
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-w32... still crashing...

[Zdzislaw Meglicki]

I got it this time. It crashed on me just a few seconds after I started it,
while reading mail with rmail. This time I had the right debug info
installed for this version of emacs and here is the backtrace:

=============================================
(gdb) backtrace
#0  0x00007ff9550c9e3b in KERNELBASE!DebugBreak ()
from /cygdrive/c/WINDOWS/system32/KERNELBASE.dll
#1  0x000000010061a344 in emacs_abort ()
at /usr/src/debug/emacs-24.3.90-1/src/w32fns.c:8460
#2  0x000000010057e7ce in arithcompare (num1=0, num2=4000000,
comparison=ARITH_GRTR_OR_EQUAL)
at /usr/src/debug/emacs-24.3.90-1/src/data.c:2319
#3  0x00000001005df264 in exec_byte_code (bytestr=25771187393,
vector=4312129309, maxdepth=28, args_template=4305639474, nargs=0,
args=0x0) at /usr/src/debug/emacs-24.3.90-1/src/bytecode.c:1468
#4  0x000000010059a5a0 in funcall_lambda (fun=4309134989, nargs=2,
arg_vector=0x10105df1d <bss_sbrk_buffer+6847133>)
at /usr/src/debug/emacs-24.3.90-1/src/eval.c:3049
#5  0x0000000100599d77 in Ffuncall (nargs=3, args=0x4387d8)
at /usr/src/debug/emacs-24.3.90-1/src/eval.c:2864
#6  0x00000001005dcaa2 in exec_byte_code (bytestr=4303067497,
vector=4303067533, maxdepth=24, args_template=4305639474, nargs=0,
args=0x0) at /usr/src/debug/emacs-24.3.90-1/src/bytecode.c:919
#7  0x000000010059a5a0 in funcall_lambda (fun=4303067373, nargs=4,
arg_vector=0x1007b998d <pure+1353837>)
at /usr/src/debug/emacs-24.3.90-1/src/eval.c:3049
#8  0x0000000100599d77 in Ffuncall (nargs=5, args=0x438d78)
at /usr/src/debug/emacs-24.3.90-1/src/eval.c:2864
#9  0x00000001005dcaa2 in exec_byte_code (bytestr=4303067977,
vector=4303068013, maxdepth=28, args_template=4305639474, nargs=0,
args=0x0) at /usr/src/debug/emacs-24.3.90-1/src/bytecode.c:919
#10 0x000000010059a5a0 in funcall_lambda (fun=4303067917, nargs=3,
arg_vector=0x1007b9b6d <pure+1354317>)
at /usr/src/debug/emacs-24.3.90-1/src/eval.c:3049
#11 0x0000000100599d77 in Ffuncall (nargs=4, args=0x4392f8)
at /usr/src/debug/emacs-24.3.90-1/src/eval.c:2864
#12 0x00000001005dcaa2 in exec_byte_code (bytestr=4303070921,
vector=4303070957, maxdepth=20, args_template=4305639474, nargs=0,
args=0x0) at /usr/src/debug/emacs-24.3.90-1/src/bytecode.c:919
#13 0x000000010059a5a0 in funcall_lambda (fun=4303070877, nargs=1,
arg_vector=0x1007ba6ed <pure+1357261>)
at /usr/src/debug/emacs-24.3.90-1/src/eval.c:3049
#14 0x0000000100599d77 in Ffuncall (nargs=2, args=0x439870)
at /usr/src/debug/emacs-24.3.90-1/src/eval.c:2864
#15 0x00000001005994ca in call1 (fn=4305692866, arg1=4313865909)
at /usr/src/debug/emacs-24.3.90-1/src/eval.c:2614
#16 0x0000000100506af0 in timer_check_2 (timers=25776357158,
idle_timers=4305639474)
at /usr/src/debug/emacs-24.3.90-1/src/keyboard.c:4510
#17 0x0000000100506c89 in timer_check ()
at /usr/src/debug/emacs-24.3.90-1/src/keyboard.c:4577
#18 0x0000000100504b4b in readable_events (flags=1)
at /usr/src/debug/emacs-24.3.90-1/src/keyboard.c:3444
#19 0x000000010050afe4 in get_input_pending (flags=1)
at /usr/src/debug/emacs-24.3.90-1/src/keyboard.c:6761
#20 0x0000000100511142 in detect_input_pending_run_timers (do_display=true)
at /usr/src/debug/emacs-24.3.90-1/src/keyboard.c:9884
#21 0x00000001005e9939 in wait_reading_process_output (time_limit=30, nsecs=0,
read_kbd=-1, do_display=true, wait_for_cell=4305639474, wait_proc=0x0,
just_wait_proc=0) at /usr/src/debug/emacs-24.3.90-1/src/process.c:4699
#22 0x000000010040df39 in sit_for (timeout=120, reading=true, display_option=1)
at /usr/src/debug/emacs-24.3.90-1/src/dispnew.c:5805
#23 0x0000000100503226 in read_char (commandflag=1, map=25776355574,
prev_event=4305639474, used_mouse_menu=0x43a3ff, end_time=0x0)
at /usr/src/debug/emacs-24.3.90-1/src/keyboard.c:2806
#24 0x000000010050f622 in read_key_sequence (keybuf=0x43a610, bufsize=30,
prompt=4305639474, dont_downcase_last=false, can_return_switch_frame=true,
fix_current_buffer=true, prevent_redisplay=false)
at /usr/src/debug/emacs-24.3.90-1/src/keyboard.c:9079
#25 0x00000001004ffcf3 in command_loop_1 ()
at /usr/src/debug/emacs-24.3.90-1/src/keyboard.c:1449
#26 0x0000000100596707 in internal_condition_case (
bfun=0x1004ff821 <command_loop_1>, handlers=4305705682,
hfun=0x1004fef62 <cmd_error>)
at /usr/src/debug/emacs-24.3.90-1/src/eval.c:1354
#27 0x00000001004ff4e5 in command_loop_2 (ignore=4305639474)
at /usr/src/debug/emacs-24.3.90-1/src/keyboard.c:1174
#28 0x0000000100595e81 in internal_catch (tag=4305695746,
func=0x1004ff4b3 <command_loop_2>, arg=4305639474)
at /usr/src/debug/emacs-24.3.90-1/src/eval.c:1118
#29 0x00000001004ff474 in command_loop ()
at /usr/src/debug/emacs-24.3.90-1/src/keyboard.c:1153
#30 0x00000001004feadf in recursive_edit_1 ()
at /usr/src/debug/emacs-24.3.90-1/src/keyboard.c:777
#31 0x00000001004fec83 in Frecursive_edit ()
at /usr/src/debug/emacs-24.3.90-1/src/keyboard.c:845
#32 0x00000001004fca49 in main (argc=2, argv=0x43ab30)
at /usr/src/debug/emacs-24.3.90-1/src/emacs.c:1646
(gdb)

================================================

It did not dump the core. It just popped up the window about
gdb. 

For completeness, here are my most recent system numbers:

Windows 8.1 Pro (with the latest patches, it's up to date as
of May 19th, 2014)
AMD A8-5500 APU with Radeon HD Graphics 3.20 GHz
8GB memory
64-bit OS, x64-based processor
3073k 2014/04/07 C:\cygwin64\bin\cygwin1.dll
Cygwin DLL version info:
DLL version: 1.7.29
DLL epoch: 19
DLL old termios: 5
DLL malloc env: 28
Cygwin conv: 181
API major: 0
API minor: 272
Shared data: 5
DLL identifier: cygwin1
Mount registry: 3
Cygwin registry name: Cygwin
Program options name: Program Options
Installations name: Installations
Cygdrive default prefix:
Build date:
Shared id: cygwin1S5

=================================
emacs                                     24.3.90-1                        OK
emacs-auctex                              11.87-2                          OK
emacs-cmake                               2.8.11.2-1                       OK
emacs-debuginfo                           24.3.90-1                        OK
emacs-el                                  24.3.90-1                        OK
emacs-gettext                             0.18.1.1-3                       OK
emacs-mercurial                           2.7.1-1                          OK
emacs-ocaml                               4.01.0-2                         OK
emacs-w32                                 24.3.90-1                        OK
emacs-X11                                 24.3.90-1                        OK
=================================

Zdzislaw (Gustav) Meglicki
Indiana University

--
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-w32... still crashing...

[Ken Brown]

On 5/14/2014 5:12 PM, Zdzislaw Meglicki wrote:
> OK, I've manage to catch it this time. But it looks like
> it didn't get very far, because the info in emacs-w32.exe.dbg
> appears to be wrong.
>[...]
> Reading symbols from /usr/bin/emacs-w32.exe...
> warning: the debug information found in "/usr/lib/debug//usr/bin/emacs-w32.exe.dbg" does not match "/usr/bin/emacs-w32.exe" (CRC mismatch).

Make sure you have version 24.3.90-1 of emacs, emacs-w32, and 
emacs-debuginfo.  Since these are test releases, you have to explicitly 
choose to keep them every time you run setup.  Here's what I see on my 
system:

$ cygcheck -cd | grep emacs | grep -v auctex
emacs                                     24.3.90-1
emacs-debuginfo                           24.3.90-1
emacs-el                                  24.3.90-1
emacs-w32                                 24.3.90-1
emacs-X11                                 24.3.90-1

$ emacs-w32.exe &
[1] 11244

$ gdb -p 11244
GNU gdb (GDB) 7.6.50.20130728-cvs (cygwin-special)
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-pc-cygwin".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word".

Attaching to process 12892
[New Thread 12892.0xdac]
[New Thread 12892.0xecc]
[New Thread 12892.0x11ac]
[New Thread 12892.0x31bc]
[New Thread 12892.0x1064]
[New Thread 12892.0x22b8]
[New Thread 12892.0x29a8]
[New Thread 12892.0x27d4]
[New Thread 12892.0x1994]
[New Thread 12892.0xdcc]
Reading symbols from /usr/bin/emacs-w32.exe...Reading symbols from 
/usr/lib/debug/usr/bin/emacs-w32.exe.dbg...done.
done.
(gdb) c
Continuing.

Ken

--
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-w32... still crashing...

[Zdzislaw Meglicki]

OK, I've manage to catch it this time. But it looks like
it didn't get very far, because the info in emacs-w32.exe.dbg
appears to be wrong. Here's what happens:
515 $ ps -ef
UID     PID    PPID  TTY        STIME COMMAND
gustav   19900       1 ?        07:51:01 /usr/bin/ssh-agent
gustav   38280   17268 pty0     07:59:32 /usr/bin/emacs-w32
gustav   30868   38280 pty2     08:02:20 /usr/bin/bash
gustav   17268   33180 pty0     07:50:46 /usr/bin/bash
gustav   23076   38280 pty1     08:00:02 /usr/bin/idn
gustav   19804   17268 pty0     17:04:30 /usr/bin/ps
gustav   27892       1 ?        07:51:35 /home/gustav/bin/fetchmail
gustav   33180       1 ?        07:50:46 /usr/bin/mintty
516 $ gdb -p 38280
GNU gdb (GDB) 7.6.50.20130728-cvs (cygwin-special)
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-pc-cygwin".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word".
Attaching to process 10936
[New Thread 10936.0x5ba8]
[New Thread 10936.0x869c]
[New Thread 10936.0xa78]
[New Thread 10936.0x39dc]
[New Thread 10936.0x6ef0]
[New Thread 10936.0x16dc]
[New Thread 10936.0x3790]
[New Thread 10936.0x10c8]
[New Thread 10936.0x2b84]
[New Thread 10936.0x5e5c]
[New Thread 10936.0x1d1c]
[New Thread 10936.0x7330]
[New Thread 10936.0x88f8]
[New Thread 10936.0x6474]
[New Thread 10936.0x2568]
[New Thread 10936.0x21f4]
Reading symbols from /usr/bin/emacs-w32.exe...
warning: the debug information found in "/usr/lib/debug//usr/bin/emacs-w32.exe.dbg" does not match "/usr/bin/emacs-w32.exe" (CRC mismatch).
　
warning: the debug information found in "/usr/lib/debug/usr/bin/emacs-w32.exe.dbg" does not match "/usr/bin/emacs-w32.exe" (CRC mismatch).
(no debugging symbols found)...done.
(gdb) continue
Continuing.
[Thread 10936.0x21f4 exited with code 0]
Program received signal SIGTRAP, Trace/breakpoint trap.
[Switching to Thread 10936.0x5ba8]
0x00007ffa6ff09e3b in KERNELBASE!DebugBreak ()
from /cygdrive/c/WINDOWS/system32/KERNELBASE.dll
(gdb) backtrace
#0  0x00007ffa6ff09e3b in KERNELBASE!DebugBreak ()
from /cygdrive/c/WINDOWS/system32/KERNELBASE.dll
#1  0x000000010061a344 in ?? ()
#2  0x801e70c000000000 in ?? ()
#3  0x0000000000000001 in ?? ()
#4  0x0000000000000000 in ?? ()
(gdb)


--
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