64-bit emacs crashes a lot

64-bit emacs crashes a lot

[Ryan Johnson]

Hi all,

Running 64-bit cygwin 1.7.22(0.268/5/3), with emacs-nox 24.3-4 inside 
mintty 1.2-beta1-1, I keep getting seg faults and "Fatal error 6: Aborted"

The most recent stackdump was:
> Stack trace:
> Frame        Function    Args
> 0000021F960  0018006F893 (001008C3C40, 400000000FFF0000, 00180127C0D, 
> 00000229900)
> 00000000006  00180070D5A (00000000000, 00100000000, 000000001DC, 
> 00000000000)
> 0000021FB40  00180119F08 (006000670D0, 0000022D440, 0000021FC8C, 
> 00600067178)
> 000000000C1  00180116FBE (0000021FFD0, 00000000000, 00000000000, 
> 0010049F140)
> 00000000006  0018011748B (00000000000, 00000000000, 00000000000, 
> 00000000006)
> 00000000006  0018011765C (00000000000, 00000000000, 00000000000, 
> 00000000000)
> 00000000006  001801130CB (00000000000, 00000000000, 00000000000, 
> 00000000000)
> End of stack trace
... addr2line translates to:
> /usr/src/debug/cygwin-1.7.22-1/winsup/cygwin/exception.h:65
> /usr/src/debug/cygwin-1.7.22-1/winsup/cygwin/exceptions.cc:1453
> /usr/src/debug/cygwin-1.7.22-1/winsup/cygwin/sigproc.cc:678
> /usr/src/debug/cygwin-1.7.22-1/winsup/cygwin/signal.cc:248
> /usr/src/debug/cygwin-1.7.22-1/winsup/cygwin/pinfo.h:171
> /usr/src/debug/cygwin-1.7.22-1/winsup/cygwin/signal.cc:285

It happens at strange times, invariably during I/O of some kind (either 
keyboard input or output from some compilation window); I don't get the 
impression it's fork-related. I don't know how to get a backtrace from 
emacs, given the way any exception or signal always loses the "userland" 
stack (suggestions welcome).

Anyone else seeing this?

Ryan

(BTW, off topic a bit: emacs+gdb -mi integration is vastly improved 
since I last tried emacs-24, hooray!)


--
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: 64-bit emacs crashes a lot

[Ken Brown]

On 7/26/2013 8:32 PM, Ryan Johnson wrote:
> Hi all,
>
> Running 64-bit cygwin 1.7.22(0.268/5/3), with emacs-nox 24.3-4 inside
> mintty 1.2-beta1-1, I keep getting seg faults and "Fatal error 6: Aborted"
>
> The most recent stackdump was:
>> Stack trace:
>> Frame        Function    Args
>> 0000021F960  0018006F893 (001008C3C40, 400000000FFF0000, 00180127C0D,
>> 00000229900)
>> 00000000006  00180070D5A (00000000000, 00100000000, 000000001DC,
>> 00000000000)
>> 0000021FB40  00180119F08 (006000670D0, 0000022D440, 0000021FC8C,
>> 00600067178)
>> 000000000C1  00180116FBE (0000021FFD0, 00000000000, 00000000000,
>> 0010049F140)
>> 00000000006  0018011748B (00000000000, 00000000000, 00000000000,
>> 00000000006)
>> 00000000006  0018011765C (00000000000, 00000000000, 00000000000,
>> 00000000000)
>> 00000000006  001801130CB (00000000000, 00000000000, 00000000000,
>> 00000000000)
>> End of stack trace
> ... addr2line translates to:
>> /usr/src/debug/cygwin-1.7.22-1/winsup/cygwin/exception.h:65
>> /usr/src/debug/cygwin-1.7.22-1/winsup/cygwin/exceptions.cc:1453
>> /usr/src/debug/cygwin-1.7.22-1/winsup/cygwin/sigproc.cc:678
>> /usr/src/debug/cygwin-1.7.22-1/winsup/cygwin/signal.cc:248
>> /usr/src/debug/cygwin-1.7.22-1/winsup/cygwin/pinfo.h:171
>> /usr/src/debug/cygwin-1.7.22-1/winsup/cygwin/signal.cc:285
>
> It happens at strange times, invariably during I/O of some kind (either
> keyboard input or output from some compilation window); I don't get the
> impression it's fork-related. I don't know how to get a backtrace from
> emacs, given the way any exception or signal always loses the "userland"
> stack (suggestions welcome).
>
> Anyone else seeing this?

This doesn't really answer your question since I don't use emacs-nox, 
but I've been running 64-bit emacs-X11 and finding it very stable.  I 
typically keep it running for several days at a time.

You say you don't know how to get a backtrace from emacs.  I assume 
you've installed emacs-debuginfo and run emacs under gdb.  Are you 
saying you can never get a backtrace after it crashes?

Ken

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: 64-bit emacs crashes a lot

[Ryan Johnson]

On 26/07/2013 10:50 PM, Ken Brown wrote:
> On 7/26/2013 8:32 PM, Ryan Johnson wrote:
>> Hi all,
>>
>> Running 64-bit cygwin 1.7.22(0.268/5/3), with emacs-nox 24.3-4 inside
>> mintty 1.2-beta1-1, I keep getting seg faults and "Fatal error 6: 
>> Aborted"

>> It happens at strange times, invariably during I/O of some kind (either
>> keyboard input or output from some compilation window); I don't get the
>> impression it's fork-related. I don't know how to get a backtrace from
>> emacs, given the way any exception or signal always loses the "userland"
>> stack (suggestions welcome).
>>
>> Anyone else seeing this?
>
> This doesn't really answer your question since I don't use emacs-nox, 
> but I've been running 64-bit emacs-X11 and finding it very stable.  I 
> typically keep it running for several days at a time.
>
> You say you don't know how to get a backtrace from emacs.  I assume 
> you've installed emacs-debuginfo and run emacs under gdb. Are you 
> saying you can never get a backtrace after it crashes?
I do have the emacs-debuginfo. I meant that the stack dump didn't have 
any emacs frames in it (they were all cygwin1.dll), and my experience 
with cygwin/gdb is that once you've taken a signal or exception you lose 
the cygwin stack and just see a bunch of threads mucking around in 
various low-level Windows dlls.

I have tried attaching gdb to emacs and setting a breakpoint on abort(), 
but it didn't catch anything yet. I'm also hampered by gdb constantly 
getting confused, breaking partway into emacs, and having to 
detach/reattach it. I've started a new thread for that issue.

Ryan

--
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: 64-bit emacs crashes a lot

[Ryan Johnson]

On 26/07/2013 11:32 PM, Ryan Johnson wrote:
> On 26/07/2013 10:50 PM, Ken Brown wrote:
>> On 7/26/2013 8:32 PM, Ryan Johnson wrote:
>>> Hi all,
>>>
>>> Running 64-bit cygwin 1.7.22(0.268/5/3), with emacs-nox 24.3-4 inside
>>> mintty 1.2-beta1-1, I keep getting seg faults and "Fatal error 6: 
>>> Aborted"
>
>>> It happens at strange times, invariably during I/O of some kind (either
>>> keyboard input or output from some compilation window); I don't get the
>>> impression it's fork-related. I don't know how to get a backtrace from
>>> emacs, given the way any exception or signal always loses the 
>>> "userland"
>>> stack (suggestions welcome).
>>>
>>> Anyone else seeing this?
>>
>> This doesn't really answer your question since I don't use emacs-nox, 
>> but I've been running 64-bit emacs-X11 and finding it very stable.  I 
>> typically keep it running for several days at a time.
>>
>> You say you don't know how to get a backtrace from emacs.  I assume 
>> you've installed emacs-debuginfo and run emacs under gdb. Are you 
>> saying you can never get a backtrace after it crashes?
> I do have the emacs-debuginfo. I meant that the stack dump didn't have 
> any emacs frames in it (they were all cygwin1.dll), and my experience 
> with cygwin/gdb is that once you've taken a signal or exception you 
> lose the cygwin stack and just see a bunch of threads mucking around 
> in various low-level Windows dlls.
>
> I have tried attaching gdb to emacs and setting a breakpoint on 
> abort(), but it didn't catch anything yet. I'm also hampered by gdb 
> constantly getting confused, breaking partway into emacs, and having 
> to detach/reattach it. I've started a new thread for that issue.

Here's a new one... I started a compilation, but before it actually 
invoked the command it started pegging the CPU. After ^G^G^G, it crashed 
with the following:
> Auto-save? (y or n) y
>       0 [main] emacs 5076 C:\cygwin64\bin\emacs-nox.exe: *** fatal 
> error - Internal error: TP_NUM_W_BUFS too small 2268032 >= 10.
> Hangup

The stackdump has the following:
> usr/src/debug/cygwin-1.7.22-1/winsup/cygwin/exception.h:65
> /usr/src/debug/cygwin-1.7.22-1/winsup/cygwin/dcrt0.cc:1268
> /usr/src/debug/cygwin-1.7.22-1/winsup/cygwin/dcrt0.cc:1277
> /usr/src/debug/cygwin-1.7.22-1/winsup/cygwin/tls_pbuf.cc:53
> /usr/src/debug/cygwin-1.7.22-1/winsup/cygwin/path.cc:614
> /usr/src/debug/cygwin-1.7.22-1/winsup/cygwin/syscalls.cc:1894
> 001801130CB
> 00000000023
> 000775DB65E
> /usr/src/debug/cygwin-1.7.22-1/winsup/cygwin/miscfuncs.cc:803
> /usr/src/debug/emacs-24.3-4/src/alloc.c:2147
> /usr/src/debug/emacs-24.3-4/src/fileio.c:5465
> /usr/src/debug/emacs-24.3-4/src/keyboard.c:10755
> /usr/src/debug/emacs-24.3-4/src/sysdep.c:1582
> /usr/src/debug/cygwin-1.7.22-1/winsup/cygwin/exceptions.cc:1453
> 001801131E1

Thoughts?
Ryan


--
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: 64-bit emacs crashes a lot

[Corinna Vinschen]

On Aug  1 22:46, Ryan Johnson wrote:
> On 26/07/2013 11:32 PM, Ryan Johnson wrote:
> >On 26/07/2013 10:50 PM, Ken Brown wrote:
> >>On 7/26/2013 8:32 PM, Ryan Johnson wrote:
> >>>Hi all,
> >>>
> >>>Running 64-bit cygwin 1.7.22(0.268/5/3), with emacs-nox 24.3-4 inside
> >>>mintty 1.2-beta1-1, I keep getting seg faults and "Fatal error
> >>>6: Aborted"
> >
> >>>It happens at strange times, invariably during I/O of some kind (either
> >>>keyboard input or output from some compilation window); I don't get the
> >>>impression it's fork-related. I don't know how to get a backtrace from
> >>>emacs, given the way any exception or signal always loses the
> >>>"userland"
> >>>stack (suggestions welcome).
> >>>
> >>>Anyone else seeing this?
> >>
> >>This doesn't really answer your question since I don't use
> >>emacs-nox, but I've been running 64-bit emacs-X11 and finding it
> >>very stable.  I typically keep it running for several days at a
> >>time.
> >>
> >>You say you don't know how to get a backtrace from emacs.  I
> >>assume you've installed emacs-debuginfo and run emacs under gdb.
> >>Are you saying you can never get a backtrace after it crashes?
> >I do have the emacs-debuginfo. I meant that the stack dump didn't
> >have any emacs frames in it (they were all cygwin1.dll), and my
> >experience with cygwin/gdb is that once you've taken a signal or
> >exception you lose the cygwin stack and just see a bunch of
> >threads mucking around in various low-level Windows dlls.
> >
> >I have tried attaching gdb to emacs and setting a breakpoint on
> >abort(), but it didn't catch anything yet. I'm also hampered by
> >gdb constantly getting confused, breaking partway into emacs, and
> >having to detach/reattach it. I've started a new thread for that
> >issue.
> 
> Here's a new one... I started a compilation, but before it actually
> invoked the command it started pegging the CPU. After ^G^G^G, it
> crashed with the following:
> >Auto-save? (y or n) y
> >      0 [main] emacs 5076 C:\cygwin64\bin\emacs-nox.exe: *** fatal
> >error - Internal error: TP_NUM_W_BUFS too small 2268032 >= 10.

That looks like a memory overwrite.  2268032 is 0x229b80, which looks
suspiciously like a stack address.  And the overwritten value is on the
stack, too, well within the cygwin TLS area.  If *this* value gets
overwritten, the TLS is probbaly totally hosed at this point.  There's
just no way to infer the culprit from this limited info.


Corinna

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

--
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: 64-bit emacs crashes a lot

[Ken Brown]

On 8/2/2013 4:02 AM, Corinna Vinschen wrote:
> On Aug  1 22:46, Ryan Johnson wrote:
>> On 26/07/2013 11:32 PM, Ryan Johnson wrote:
>>> On 26/07/2013 10:50 PM, Ken Brown wrote:
>>>> On 7/26/2013 8:32 PM, Ryan Johnson wrote:
>>>>> Hi all,
>>>>>
>>>>> Running 64-bit cygwin 1.7.22(0.268/5/3), with emacs-nox 24.3-4 inside
>>>>> mintty 1.2-beta1-1, I keep getting seg faults and "Fatal error
>>>>> 6: Aborted"
>>>
>>>>> It happens at strange times, invariably during I/O of some kind (either
>>>>> keyboard input or output from some compilation window); I don't get the
>>>>> impression it's fork-related. I don't know how to get a backtrace from
>>>>> emacs, given the way any exception or signal always loses the
>>>>> "userland"
>>>>> stack (suggestions welcome).
>>>>>
>>>>> Anyone else seeing this?
>>>>
>>>> This doesn't really answer your question since I don't use
>>>> emacs-nox, but I've been running 64-bit emacs-X11 and finding it
>>>> very stable.  I typically keep it running for several days at a
>>>> time.
>>>>
>>>> You say you don't know how to get a backtrace from emacs.  I
>>>> assume you've installed emacs-debuginfo and run emacs under gdb.
>>>> Are you saying you can never get a backtrace after it crashes?
>>> I do have the emacs-debuginfo. I meant that the stack dump didn't
>>> have any emacs frames in it (they were all cygwin1.dll), and my
>>> experience with cygwin/gdb is that once you've taken a signal or
>>> exception you lose the cygwin stack and just see a bunch of
>>> threads mucking around in various low-level Windows dlls.
>>>
>>> I have tried attaching gdb to emacs and setting a breakpoint on
>>> abort(), but it didn't catch anything yet. I'm also hampered by
>>> gdb constantly getting confused, breaking partway into emacs, and
>>> having to detach/reattach it. I've started a new thread for that
>>> issue.
>>
>> Here's a new one... I started a compilation, but before it actually
>> invoked the command it started pegging the CPU. After ^G^G^G, it
>> crashed with the following:
>>> Auto-save? (y or n) y
>>>       0 [main] emacs 5076 C:\cygwin64\bin\emacs-nox.exe: *** fatal
>>> error - Internal error: TP_NUM_W_BUFS too small 2268032 >= 10.
>
> That looks like a memory overwrite.  2268032 is 0x229b80, which looks
> suspiciously like a stack address.  And the overwritten value is on the
> stack, too, well within the cygwin TLS area.  If *this* value gets
> overwritten, the TLS is probbaly totally hosed at this point.  There's
> just no way to infer the culprit from this limited info.

Could this be BLODA?  Ryan, I noticed that you wrote in a different 
thread, "I recently migrated to 64-bit cygwin...and so far have not had 
to disable Windows Defender; the latter was a recurring source of 
trouble for my previous 32-bit cygwin install on Win7/64."

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: 64-bit emacs crashes a lot

[Ryan Johnson]

On 02/08/2013 7:04 AM, Ken Brown wrote:
> On 8/2/2013 4:02 AM, Corinna Vinschen wrote:
>> On Aug  1 22:46, Ryan Johnson wrote:
>>> On 26/07/2013 11:32 PM, Ryan Johnson wrote:
>>>> On 26/07/2013 10:50 PM, Ken Brown wrote:
>>>>> On 7/26/2013 8:32 PM, Ryan Johnson wrote:
>>>>>> Hi all,
>>>>>>
>>>>>> Running 64-bit cygwin 1.7.22(0.268/5/3), with emacs-nox 24.3-4 
>>>>>> inside
>>>>>> mintty 1.2-beta1-1, I keep getting seg faults and "Fatal error
>>>>>> 6: Aborted"
>>>>
>>>>>> It happens at strange times, invariably during I/O of some kind 
>>>>>> (either
>>>>>> keyboard input or output from some compilation window); I don't 
>>>>>> get the
>>>>>> impression it's fork-related. I don't know how to get a backtrace 
>>>>>> from
>>>>>> emacs, given the way any exception or signal always loses the
>>>>>> "userland"
>>>>>> stack (suggestions welcome).
>>>>>>
>>>>>> Anyone else seeing this?
>>>>>
>>>>> This doesn't really answer your question since I don't use
>>>>> emacs-nox, but I've been running 64-bit emacs-X11 and finding it
>>>>> very stable.  I typically keep it running for several days at a
>>>>> time.
>>>>>
>>>>> You say you don't know how to get a backtrace from emacs. I
>>>>> assume you've installed emacs-debuginfo and run emacs under gdb.
>>>>> Are you saying you can never get a backtrace after it crashes?
>>>> I do have the emacs-debuginfo. I meant that the stack dump didn't
>>>> have any emacs frames in it (they were all cygwin1.dll), and my
>>>> experience with cygwin/gdb is that once you've taken a signal or
>>>> exception you lose the cygwin stack and just see a bunch of
>>>> threads mucking around in various low-level Windows dlls.
>>>>
>>>> I have tried attaching gdb to emacs and setting a breakpoint on
>>>> abort(), but it didn't catch anything yet. I'm also hampered by
>>>> gdb constantly getting confused, breaking partway into emacs, and
>>>> having to detach/reattach it. I've started a new thread for that
>>>> issue.
>>>
>>> Here's a new one... I started a compilation, but before it actually
>>> invoked the command it started pegging the CPU. After ^G^G^G, it
>>> crashed with the following:
>>>> Auto-save? (y or n) y
>>>>       0 [main] emacs 5076 C:\cygwin64\bin\emacs-nox.exe: *** fatal
>>>> error - Internal error: TP_NUM_W_BUFS too small 2268032 >= 10.
>>
>> That looks like a memory overwrite.  2268032 is 0x229b80, which looks
>> suspiciously like a stack address.  And the overwritten value is on the
>> stack, too, well within the cygwin TLS area.  If *this* value gets
>> overwritten, the TLS is probbaly totally hosed at this point. There's
>> just no way to infer the culprit from this limited info.
>
> Could this be BLODA?  Ryan, I noticed that you wrote in a different 
> thread, "I recently migrated to 64-bit cygwin...and so far have not 
> had to disable Windows Defender; the latter was a recurring source of 
> trouble for my previous 32-bit cygwin install on Win7/64."
This would be a whole new level of nasty from a BLODA... I thought they 
only interfered with fork()?

However, this *is* Windows Defender we're talking about... service 
disabled and all cygwin processes restarted. I'll let you know in a day 
or so if the crashes go away.

Thanks,
Ryan


--
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: 64-bit emacs crashes a lot

[Ryan Johnson]

On 02/08/2013 8:07 AM, Ryan Johnson wrote:
> On 02/08/2013 7:04 AM, Ken Brown wrote:
>> On 8/2/2013 4:02 AM, Corinna Vinschen wrote:
>>> On Aug  1 22:46, Ryan Johnson wrote:
>>>> Here's a new one... I started a compilation, but before it actually
>>>> invoked the command it started pegging the CPU. After ^G^G^G, it
>>>> crashed with the following:
>>>>> Auto-save? (y or n) y
>>>>>       0 [main] emacs 5076 C:\cygwin64\bin\emacs-nox.exe: *** fatal
>>>>> error - Internal error: TP_NUM_W_BUFS too small 2268032 >= 10.
>>>
>>> That looks like a memory overwrite.  2268032 is 0x229b80, which looks
>>> suspiciously like a stack address.  And the overwritten value is on the
>>> stack, too, well within the cygwin TLS area.  If *this* value gets
>>> overwritten, the TLS is probbaly totally hosed at this point. There's
>>> just no way to infer the culprit from this limited info.
>>
>> Could this be BLODA?  Ryan, I noticed that you wrote in a different 
>> thread, "I recently migrated to 64-bit cygwin...and so far have not 
>> had to disable Windows Defender; the latter was a recurring source of 
>> trouble for my previous 32-bit cygwin install on Win7/64."
> This would be a whole new level of nasty from a BLODA... I thought 
> they only interfered with fork()?
>
> However, this *is* Windows Defender we're talking about... service 
> disabled and all cygwin processes restarted. I'll let you know in a 
> day or so if the crashes go away.
Rats. I just had another crash, the "Fatal error 6" variety. Windows 
Defender has not turned itself back on (it's been known to do that), and 
a scan of the BLODA list didn't match anything else on my system.

So I don't think it's BLODA...

Ideas?
> Ryan


--
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: 64-bit emacs crashes a lot

[Paul Allen]

Hi

On Sat, Aug 3, 2013 at 8:05 PM, Ryan Johnson wrote:

> Rats. I just had another crash, the "Fatal error 6" variety. Windows
> Defender has not turned itself back on (it's been known to do that), and a
> scan of the BLODA list didn't match anything else on my system.
>
> So I don't think it's BLODA...
>
> Ideas?

Yeah, it's a case of MIC (can I have a place in the acronym list?)

Microsoft Is Crap.

-- 
Paul

--
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: 64-bit emacs crashes a lot

[Ken Brown]

On 8/3/2013 3:05 PM, Ryan Johnson wrote:
> On 02/08/2013 8:07 AM, Ryan Johnson wrote:
>> On 02/08/2013 7:04 AM, Ken Brown wrote:
>>> On 8/2/2013 4:02 AM, Corinna Vinschen wrote:
>>>> On Aug  1 22:46, Ryan Johnson wrote:
>>>>> Here's a new one... I started a compilation, but before it actually
>>>>> invoked the command it started pegging the CPU. After ^G^G^G, it
>>>>> crashed with the following:
>>>>>> Auto-save? (y or n) y
>>>>>>       0 [main] emacs 5076 C:\cygwin64\bin\emacs-nox.exe: *** fatal
>>>>>> error - Internal error: TP_NUM_W_BUFS too small 2268032 >= 10.
>>>>
>>>> That looks like a memory overwrite.  2268032 is 0x229b80, which looks
>>>> suspiciously like a stack address.  And the overwritten value is on the
>>>> stack, too, well within the cygwin TLS area.  If *this* value gets
>>>> overwritten, the TLS is probbaly totally hosed at this point. There's
>>>> just no way to infer the culprit from this limited info.
>>>
>>> Could this be BLODA?  Ryan, I noticed that you wrote in a different
>>> thread, "I recently migrated to 64-bit cygwin...and so far have not
>>> had to disable Windows Defender; the latter was a recurring source of
>>> trouble for my previous 32-bit cygwin install on Win7/64."
>> This would be a whole new level of nasty from a BLODA... I thought
>> they only interfered with fork()?
>>
>> However, this *is* Windows Defender we're talking about... service
>> disabled and all cygwin processes restarted. I'll let you know in a
>> day or so if the crashes go away.
> Rats. I just had another crash, the "Fatal error 6" variety. Windows
> Defender has not turned itself back on (it's been known to do that), and
> a scan of the BLODA list didn't match anything else on my system.
>
> So I don't think it's BLODA...
>
> Ideas?

Not really, other than the obvious: (a) Find a reproducible way of 
making emacs-nox crash.  (b) Catch the crash in gdb by setting a 
suitable break point.

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: 64-bit emacs crashes a lot

[Ryan Johnson]

On 05/08/2013 11:00 AM, Ken Brown wrote:
> On 8/3/2013 3:05 PM, Ryan Johnson wrote:
>> On 02/08/2013 8:07 AM, Ryan Johnson wrote:
>>> On 02/08/2013 7:04 AM, Ken Brown wrote:
>>>> On 8/2/2013 4:02 AM, Corinna Vinschen wrote:
>>>>> On Aug  1 22:46, Ryan Johnson wrote:
>>>>>> Here's a new one... I started a compilation, but before it actually
>>>>>> invoked the command it started pegging the CPU. After ^G^G^G, it
>>>>>> crashed with the following:
>>>>>>> Auto-save? (y or n) y
>>>>>>>       0 [main] emacs 5076 C:\cygwin64\bin\emacs-nox.exe: *** fatal
>>>>>>> error - Internal error: TP_NUM_W_BUFS too small 2268032 >= 10.
>>>>>
>>>>> That looks like a memory overwrite.  2268032 is 0x229b80, which looks
>>>>> suspiciously like a stack address.  And the overwritten value is 
>>>>> on the
>>>>> stack, too, well within the cygwin TLS area.  If *this* value gets
>>>>> overwritten, the TLS is probbaly totally hosed at this point. There's
>>>>> just no way to infer the culprit from this limited info.
>>>>
>>>> Could this be BLODA?  Ryan, I noticed that you wrote in a different
>>>> thread, "I recently migrated to 64-bit cygwin...and so far have not
>>>> had to disable Windows Defender; the latter was a recurring source of
>>>> trouble for my previous 32-bit cygwin install on Win7/64."
>>> This would be a whole new level of nasty from a BLODA... I thought
>>> they only interfered with fork()?
>>>
>>> However, this *is* Windows Defender we're talking about... service
>>> disabled and all cygwin processes restarted. I'll let you know in a
>>> day or so if the crashes go away.
>> Rats. I just had another crash, the "Fatal error 6" variety. Windows
>> Defender has not turned itself back on (it's been known to do that), and
>> a scan of the BLODA list didn't match anything else on my system.
>>
>> So I don't think it's BLODA...
>>
>> Ideas?
>
> Not really, other than the obvious: (a) Find a reproducible way of 
> making emacs-nox crash.  (b) Catch the crash in gdb by setting a 
> suitable break point.
I've had no luck with (a), but the latest version of gdb forwards 
signals properly (thanks cgf!), so I've got it watching in the 
background for anything to go wrong. If it's really a memory overwrite, 
though, the stack trace is unlikely to give much insight into root causes.

Ryan


--
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: 64-bit emacs crashes a lot

[Ken Brown]

On 8/5/2013 11:29 AM, Ryan Johnson wrote:
> On 05/08/2013 11:00 AM, Ken Brown wrote:
>> On 8/3/2013 3:05 PM, Ryan Johnson wrote:
>>> On 02/08/2013 8:07 AM, Ryan Johnson wrote:
>>>> On 02/08/2013 7:04 AM, Ken Brown wrote:
>>>>> On 8/2/2013 4:02 AM, Corinna Vinschen wrote:
>>>>>> On Aug  1 22:46, Ryan Johnson wrote:
>>>>>>> Here's a new one... I started a compilation, but before it actually
>>>>>>> invoked the command it started pegging the CPU. After ^G^G^G, it
>>>>>>> crashed with the following:
>>>>>>>> Auto-save? (y or n) y
>>>>>>>>       0 [main] emacs 5076 C:\cygwin64\bin\emacs-nox.exe: *** fatal
>>>>>>>> error - Internal error: TP_NUM_W_BUFS too small 2268032 >= 10.
>>>>>>
>>>>>> That looks like a memory overwrite.  2268032 is 0x229b80, which looks
>>>>>> suspiciously like a stack address.  And the overwritten value is
>>>>>> on the
>>>>>> stack, too, well within the cygwin TLS area.  If *this* value gets
>>>>>> overwritten, the TLS is probbaly totally hosed at this point. There's
>>>>>> just no way to infer the culprit from this limited info.
>>>>>
>>>>> Could this be BLODA?  Ryan, I noticed that you wrote in a different
>>>>> thread, "I recently migrated to 64-bit cygwin...and so far have not
>>>>> had to disable Windows Defender; the latter was a recurring source of
>>>>> trouble for my previous 32-bit cygwin install on Win7/64."
>>>> This would be a whole new level of nasty from a BLODA... I thought
>>>> they only interfered with fork()?
>>>>
>>>> However, this *is* Windows Defender we're talking about... service
>>>> disabled and all cygwin processes restarted. I'll let you know in a
>>>> day or so if the crashes go away.
>>> Rats. I just had another crash, the "Fatal error 6" variety. Windows
>>> Defender has not turned itself back on (it's been known to do that), and
>>> a scan of the BLODA list didn't match anything else on my system.
>>>
>>> So I don't think it's BLODA...
>>>
>>> Ideas?
>>
>> Not really, other than the obvious: (a) Find a reproducible way of
>> making emacs-nox crash.  (b) Catch the crash in gdb by setting a
>> suitable break point.
> I've had no luck with (a), but the latest version of gdb forwards
> signals properly (thanks cgf!), so I've got it watching in the
> background for anything to go wrong. If it's really a memory overwrite,
> though, the stack trace is unlikely to give much insight into root causes.

I had a couple of additional thoughts.  First, have you tried `emacs -Q' 
to make sure there's nothing in your .emacs that triggers the bug?  In 
the same vein, you might try not using the mouse, in case the bug has 
something to do with the way emacs/mintty handle mouse movements when 
emacs is running in non-GUI mode.

Second, would you be willing to try emacs-w32 and/or emacs-X11 to see if 
you have the same problem?  It might help narrow down the search if we 
knew that the bug only occurs with emacs-nox.

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: 64-bit emacs crashes a lot

[Ryan Johnson]

On 08/08/2013 1:42 PM, Ken Brown wrote:
> On 8/5/2013 11:29 AM, Ryan Johnson wrote:
>> On 05/08/2013 11:00 AM, Ken Brown wrote:
>>> On 8/3/2013 3:05 PM, Ryan Johnson wrote:
>>>> On 02/08/2013 8:07 AM, Ryan Johnson wrote:
>>>>> On 02/08/2013 7:04 AM, Ken Brown wrote:
>>>>>> On 8/2/2013 4:02 AM, Corinna Vinschen wrote:
>>>>>>> On Aug  1 22:46, Ryan Johnson wrote:
>>>>>>>> Here's a new one... I started a compilation, but before it 
>>>>>>>> actually
>>>>>>>> invoked the command it started pegging the CPU. After ^G^G^G, it
>>>>>>>> crashed with the following:
>>>>>>>>> Auto-save? (y or n) y
>>>>>>>>>       0 [main] emacs 5076 C:\cygwin64\bin\emacs-nox.exe: *** 
>>>>>>>>> fatal
>>>>>>>>> error - Internal error: TP_NUM_W_BUFS too small 2268032 >= 10.
>>>>>>>
>>>>>>> That looks like a memory overwrite.  2268032 is 0x229b80, which 
>>>>>>> looks
>>>>>>> suspiciously like a stack address.  And the overwritten value is
>>>>>>> on the
>>>>>>> stack, too, well within the cygwin TLS area.  If *this* value gets
>>>>>>> overwritten, the TLS is probbaly totally hosed at this point. 
>>>>>>> There's
>>>>>>> just no way to infer the culprit from this limited info.
>>>>>>
>>>>>> Could this be BLODA?  Ryan, I noticed that you wrote in a different
>>>>>> thread, "I recently migrated to 64-bit cygwin...and so far have not
>>>>>> had to disable Windows Defender; the latter was a recurring 
>>>>>> source of
>>>>>> trouble for my previous 32-bit cygwin install on Win7/64."
>>>>> This would be a whole new level of nasty from a BLODA... I thought
>>>>> they only interfered with fork()?
>>>>>
>>>>> However, this *is* Windows Defender we're talking about... service
>>>>> disabled and all cygwin processes restarted. I'll let you know in a
>>>>> day or so if the crashes go away.
>>>> Rats. I just had another crash, the "Fatal error 6" variety. Windows
>>>> Defender has not turned itself back on (it's been known to do 
>>>> that), and
>>>> a scan of the BLODA list didn't match anything else on my system.
>>>>
>>>> So I don't think it's BLODA...
>>>>
>>>> Ideas?
>>>
>>> Not really, other than the obvious: (a) Find a reproducible way of
>>> making emacs-nox crash.  (b) Catch the crash in gdb by setting a
>>> suitable break point.
>> I've had no luck with (a), but the latest version of gdb forwards
>> signals properly (thanks cgf!), so I've got it watching in the
>> background for anything to go wrong. If it's really a memory overwrite,
>> though, the stack trace is unlikely to give much insight into root 
>> causes.
>
> I had a couple of additional thoughts.  First, have you tried `emacs 
> -Q' to make sure there's nothing in your .emacs that triggers the 
> bug?  In the same vein, you might try not using the mouse, in case the 
> bug has something to do with the way emacs/mintty handle mouse 
> movements when emacs is running in non-GUI mode.
>
> Second, would you be willing to try emacs-w32 and/or emacs-X11 to see 
> if you have the same problem?  It might help narrow down the search if 
> we knew that the bug only occurs with emacs-nox.
The crashes are definitely less common now that Windows Defender is 
gone, which is both good and bad. Good because I can get work done, bad 
because it's harder to repro now. Makes me suspect that WinDef was 
tickling the bug rather than causing it. Crashes rare enough at this 
point that moving away from nox will only be helpful if I get lucky and 
w32/x11 crashes.

I imagine gdb will eventually catch this elusive call to abort(), let's 
see what the stack trace has to say and go from there. So far its 
presence seems to make a really effective talisman against the crashes: 
I've only had one crash in the last couple of days, and naturally it was 
an emacs session I forgot to attach a gdb to.

Ryan


--
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: 64-bit emacs crashes a lot

[Ryan Johnson]

On 08/08/2013 2:00 PM, Ryan Johnson wrote:
> On 08/08/2013 1:42 PM, Ken Brown wrote:
>> On 8/5/2013 11:29 AM, Ryan Johnson wrote:
>>> On 05/08/2013 11:00 AM, Ken Brown wrote:
>>>> On 8/3/2013 3:05 PM, Ryan Johnson wrote:
>>>>> On 02/08/2013 8:07 AM, Ryan Johnson wrote:
>>>>>> On 02/08/2013 7:04 AM, Ken Brown wrote:
>>>>>>> On 8/2/2013 4:02 AM, Corinna Vinschen wrote:
>>>>>>>> On Aug  1 22:46, Ryan Johnson wrote:
>>>>>>>>> Here's a new one... I started a compilation, but before it 
>>>>>>>>> actually
>>>>>>>>> invoked the command it started pegging the CPU. After ^G^G^G, it
>>>>>>>>> crashed with the following:
>>>>>>>>>> Auto-save? (y or n) y
>>>>>>>>>>       0 [main] emacs 5076 C:\cygwin64\bin\emacs-nox.exe: *** 
>>>>>>>>>> fatal
>>>>>>>>>> error - Internal error: TP_NUM_W_BUFS too small 2268032 >= 10.
>>>>>>>>
>>>>>>>> That looks like a memory overwrite.  2268032 is 0x229b80, which 
>>>>>>>> looks
>>>>>>>> suspiciously like a stack address.  And the overwritten value is
>>>>>>>> on the
>>>>>>>> stack, too, well within the cygwin TLS area.  If *this* value gets
>>>>>>>> overwritten, the TLS is probbaly totally hosed at this point. 
>>>>>>>> There's
>>>>>>>> just no way to infer the culprit from this limited info.
>>>>>>>
>>>>>>> Could this be BLODA?  Ryan, I noticed that you wrote in a different
>>>>>>> thread, "I recently migrated to 64-bit cygwin...and so far have not
>>>>>>> had to disable Windows Defender; the latter was a recurring 
>>>>>>> source of
>>>>>>> trouble for my previous 32-bit cygwin install on Win7/64."
>>>>>> This would be a whole new level of nasty from a BLODA... I thought
>>>>>> they only interfered with fork()?
>>>>>>
>>>>>> However, this *is* Windows Defender we're talking about... service
>>>>>> disabled and all cygwin processes restarted. I'll let you know in a
>>>>>> day or so if the crashes go away.
>>>>> Rats. I just had another crash, the "Fatal error 6" variety. Windows
>>>>> Defender has not turned itself back on (it's been known to do 
>>>>> that), and
>>>>> a scan of the BLODA list didn't match anything else on my system.
>>>>>
>>>>> So I don't think it's BLODA...
>>>>>
>>>>> Ideas?
>>>>
>>>> Not really, other than the obvious: (a) Find a reproducible way of
>>>> making emacs-nox crash.  (b) Catch the crash in gdb by setting a
>>>> suitable break point.
Got one! Looks like a stack overflow somewhere in the garbage collector:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 5316.0x1af4]
0x00000001004df44a in mark_object (arg=<optimized out>)
     at /usr/src/debug/emacs-24.3-4/src/alloc.c:5903
5903            if (CONS_MARKED_P (ptr))
(gdb) bt
#0  0x00000001004df44a in mark_object (arg=<optimized out>)
     at /usr/src/debug/emacs-24.3-4/src/alloc.c:5903
#1  0x00000001004df66e in mark_object (arg=<optimized out>)
     at /usr/src/debug/emacs-24.3-4/src/alloc.c:5914
#2  0x00000001004df593 in mark_object (arg=<optimized out>)
     at /usr/src/debug/emacs-24.3-4/src/alloc.c:5809
#3  0x00000001004df66e in mark_object (arg=<optimized out>)
     at /usr/src/debug/emacs-24.3-4/src/alloc.c:5914
#4  0x00000001004df66e in mark_object (arg=<optimized out>)
     at /usr/src/debug/emacs-24.3-4/src/alloc.c:5914
#5  0x00000001004df585 in mark_object (arg=<optimized out>)
     at /usr/src/debug/emacs-24.3-4/src/alloc.c:5808
#6  0x00000001004dfa4e in mark_vectorlike (
     ptr=0x100f66f28 <bss_sbrk_buffer+6955080>)
     at /usr/src/debug/emacs-24.3-4/src/alloc.c:5501
... snip ...
#2606 0x00000001004dfaf4 in mark_buffer (buffer=<optimized out>)
     at /usr/src/debug/emacs-24.3-4/src/alloc.c:5552
#2607 0x00000001004dff2c in Fgarbage_collect ()
     at /usr/src/debug/emacs-24.3-4/src/alloc.c:5181
#2608 0x0000000000000000 in ?? ()

I have the full backtrace saved to file, let me know if that would be 
useful (there wasn't anything obvious that I could see, just more of the 
same). Meanwhile, I verified that none of the addresses printed is 
repeated, so it doesn't seem to be due to an obvious cycle in the object 
graph.

The crash happened when I foregrounded a stopped emacs. I tried playing 
around with various breakpoints while repeatedly sending ^Z, but no luck 
repeating the "feat" yet.

Ideas?
Ryan

--
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: 64-bit emacs crashes a lot

[Ken Brown]

On 8/9/2013 11:28 PM, Ryan Johnson wrote:
> On 08/08/2013 2:00 PM, Ryan Johnson wrote:
>> On 08/08/2013 1:42 PM, Ken Brown wrote:
>>> On 8/5/2013 11:29 AM, Ryan Johnson wrote:
>>>> On 05/08/2013 11:00 AM, Ken Brown wrote:
>>>>> On 8/3/2013 3:05 PM, Ryan Johnson wrote:
>>>>>> On 02/08/2013 8:07 AM, Ryan Johnson wrote:
>>>>>>> On 02/08/2013 7:04 AM, Ken Brown wrote:
>>>>>>>> On 8/2/2013 4:02 AM, Corinna Vinschen wrote:
>>>>>>>>> On Aug  1 22:46, Ryan Johnson wrote:
>>>>>>>>>> Here's a new one... I started a compilation, but before it
>>>>>>>>>> actually
>>>>>>>>>> invoked the command it started pegging the CPU. After ^G^G^G, it
>>>>>>>>>> crashed with the following:
>>>>>>>>>>> Auto-save? (y or n) y
>>>>>>>>>>>       0 [main] emacs 5076 C:\cygwin64\bin\emacs-nox.exe: ***
>>>>>>>>>>> fatal
>>>>>>>>>>> error - Internal error: TP_NUM_W_BUFS too small 2268032 >= 10.
>>>>>>>>>
>>>>>>>>> That looks like a memory overwrite.  2268032 is 0x229b80, which
>>>>>>>>> looks
>>>>>>>>> suspiciously like a stack address.  And the overwritten value is
>>>>>>>>> on the
>>>>>>>>> stack, too, well within the cygwin TLS area.  If *this* value gets
>>>>>>>>> overwritten, the TLS is probbaly totally hosed at this point.
>>>>>>>>> There's
>>>>>>>>> just no way to infer the culprit from this limited info.
>>>>>>>>
>>>>>>>> Could this be BLODA?  Ryan, I noticed that you wrote in a different
>>>>>>>> thread, "I recently migrated to 64-bit cygwin...and so far have not
>>>>>>>> had to disable Windows Defender; the latter was a recurring
>>>>>>>> source of
>>>>>>>> trouble for my previous 32-bit cygwin install on Win7/64."
>>>>>>> This would be a whole new level of nasty from a BLODA... I thought
>>>>>>> they only interfered with fork()?
>>>>>>>
>>>>>>> However, this *is* Windows Defender we're talking about... service
>>>>>>> disabled and all cygwin processes restarted. I'll let you know in a
>>>>>>> day or so if the crashes go away.
>>>>>> Rats. I just had another crash, the "Fatal error 6" variety. Windows
>>>>>> Defender has not turned itself back on (it's been known to do
>>>>>> that), and
>>>>>> a scan of the BLODA list didn't match anything else on my system.
>>>>>>
>>>>>> So I don't think it's BLODA...
>>>>>>
>>>>>> Ideas?
>>>>>
>>>>> Not really, other than the obvious: (a) Find a reproducible way of
>>>>> making emacs-nox crash.  (b) Catch the crash in gdb by setting a
>>>>> suitable break point.
> Got one! Looks like a stack overflow somewhere in the garbage collector:
>
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 5316.0x1af4]
> 0x00000001004df44a in mark_object (arg=<optimized out>)
>      at /usr/src/debug/emacs-24.3-4/src/alloc.c:5903
> 5903            if (CONS_MARKED_P (ptr))
> (gdb) bt
> #0  0x00000001004df44a in mark_object (arg=<optimized out>)
>      at /usr/src/debug/emacs-24.3-4/src/alloc.c:5903
> #1  0x00000001004df66e in mark_object (arg=<optimized out>)
>      at /usr/src/debug/emacs-24.3-4/src/alloc.c:5914
> #2  0x00000001004df593 in mark_object (arg=<optimized out>)
>      at /usr/src/debug/emacs-24.3-4/src/alloc.c:5809
> #3  0x00000001004df66e in mark_object (arg=<optimized out>)
>      at /usr/src/debug/emacs-24.3-4/src/alloc.c:5914
> #4  0x00000001004df66e in mark_object (arg=<optimized out>)
>      at /usr/src/debug/emacs-24.3-4/src/alloc.c:5914
> #5  0x00000001004df585 in mark_object (arg=<optimized out>)
>      at /usr/src/debug/emacs-24.3-4/src/alloc.c:5808
> #6  0x00000001004dfa4e in mark_vectorlike (
>      ptr=0x100f66f28 <bss_sbrk_buffer+6955080>)
>      at /usr/src/debug/emacs-24.3-4/src/alloc.c:5501
> ... snip ...
> #2606 0x00000001004dfaf4 in mark_buffer (buffer=<optimized out>)
>      at /usr/src/debug/emacs-24.3-4/src/alloc.c:5552
> #2607 0x00000001004dff2c in Fgarbage_collect ()
>      at /usr/src/debug/emacs-24.3-4/src/alloc.c:5181
> #2608 0x0000000000000000 in ?? ()

I don't know whether 2608 stack frames is unusual or not.  Is this 
enough to cause a stack overflow?

> I have the full backtrace saved to file, let me know if that would be
> useful (there wasn't anything obvious that I could see, just more of the
> same). Meanwhile, I verified that none of the addresses printed is
> repeated, so it doesn't seem to be due to an obvious cycle in the object
> graph.

 From what you've shown, it appears that most of the addresses have been 
optimized out.  I think you would need an unoptimized build in order to 
check that, wouldn't you?

> The crash happened when I foregrounded a stopped emacs. I tried playing
> around with various breakpoints while repeatedly sending ^Z, but no luck
> repeating the "feat" yet.
>
> Ideas?

Can you trigger the bug by calling garbage collection manually (M-x 
garbage-collect)?  What happens if you put a breakpoint at 
Fgarbage_collect and step through it?  (Again, you might need an 
unoptimized build before that will be useful.)

There are lots of lisp variables that can be used to control garbage 
collection and get information about it.  See the section on garbage 
collection in the elisp manual.  For example, you could try customizing 
garbage-collection-messages.  Or you could play with gc-cons-threshold.

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: 64-bit emacs crashes a lot

[Ryan Johnson]

On 10/08/2013 9:59 AM, Ken Brown wrote:
> On 8/9/2013 11:28 PM, Ryan Johnson wrote:
>> On 08/08/2013 2:00 PM, Ryan Johnson wrote:
>>> On 08/08/2013 1:42 PM, Ken Brown wrote:
>>>> On 8/5/2013 11:29 AM, Ryan Johnson wrote:
>>>>> On 05/08/2013 11:00 AM, Ken Brown wrote:
>>>>>> On 8/3/2013 3:05 PM, Ryan Johnson wrote:
>>>>>>> On 02/08/2013 8:07 AM, Ryan Johnson wrote:
>>>>>>>> On 02/08/2013 7:04 AM, Ken Brown wrote:
>>>>>>>>> On 8/2/2013 4:02 AM, Corinna Vinschen wrote:
>>>>>>>>>> On Aug  1 22:46, Ryan Johnson wrote:
>>>>>>>>>>> Here's a new one... I started a compilation, but before it
>>>>>>>>>>> actually
>>>>>>>>>>> invoked the command it started pegging the CPU. After 
>>>>>>>>>>> ^G^G^G, it
>>>>>>>>>>> crashed with the following:
>>>>>>>>>>>> Auto-save? (y or n) y
>>>>>>>>>>>>       0 [main] emacs 5076 C:\cygwin64\bin\emacs-nox.exe: ***
>>>>>>>>>>>> fatal
>>>>>>>>>>>> error - Internal error: TP_NUM_W_BUFS too small 2268032 >= 10.
>>>>>>>>>>
>>>>>>>>>> That looks like a memory overwrite.  2268032 is 0x229b80, which
>>>>>>>>>> looks
>>>>>>>>>> suspiciously like a stack address.  And the overwritten value is
>>>>>>>>>> on the
>>>>>>>>>> stack, too, well within the cygwin TLS area.  If *this* value 
>>>>>>>>>> gets
>>>>>>>>>> overwritten, the TLS is probbaly totally hosed at this point.
>>>>>>>>>> There's
>>>>>>>>>> just no way to infer the culprit from this limited info.
>>>>>>>>>
>>>>>>>>> Could this be BLODA?  Ryan, I noticed that you wrote in a 
>>>>>>>>> different
>>>>>>>>> thread, "I recently migrated to 64-bit cygwin...and so far 
>>>>>>>>> have not
>>>>>>>>> had to disable Windows Defender; the latter was a recurring
>>>>>>>>> source of
>>>>>>>>> trouble for my previous 32-bit cygwin install on Win7/64."
>>>>>>>> This would be a whole new level of nasty from a BLODA... I thought
>>>>>>>> they only interfered with fork()?
>>>>>>>>
>>>>>>>> However, this *is* Windows Defender we're talking about... service
>>>>>>>> disabled and all cygwin processes restarted. I'll let you know 
>>>>>>>> in a
>>>>>>>> day or so if the crashes go away.
>>>>>>> Rats. I just had another crash, the "Fatal error 6" variety. 
>>>>>>> Windows
>>>>>>> Defender has not turned itself back on (it's been known to do
>>>>>>> that), and
>>>>>>> a scan of the BLODA list didn't match anything else on my system.
>>>>>>>
>>>>>>> So I don't think it's BLODA...
>>>>>>>
>>>>>>> Ideas?
>>>>>>
>>>>>> Not really, other than the obvious: (a) Find a reproducible way of
>>>>>> making emacs-nox crash.  (b) Catch the crash in gdb by setting a
>>>>>> suitable break point.
>> Got one! Looks like a stack overflow somewhere in the garbage collector:
>>
>> Program received signal SIGSEGV, Segmentation fault.
>> [Switching to Thread 5316.0x1af4]
>> 0x00000001004df44a in mark_object (arg=<optimized out>)
>>      at /usr/src/debug/emacs-24.3-4/src/alloc.c:5903
>> 5903            if (CONS_MARKED_P (ptr))
>> (gdb) bt
>> #0  0x00000001004df44a in mark_object (arg=<optimized out>)
>>      at /usr/src/debug/emacs-24.3-4/src/alloc.c:5903
>> #1  0x00000001004df66e in mark_object (arg=<optimized out>)
>>      at /usr/src/debug/emacs-24.3-4/src/alloc.c:5914
>> #2  0x00000001004df593 in mark_object (arg=<optimized out>)
>>      at /usr/src/debug/emacs-24.3-4/src/alloc.c:5809
>> #3  0x00000001004df66e in mark_object (arg=<optimized out>)
>>      at /usr/src/debug/emacs-24.3-4/src/alloc.c:5914
>> #4  0x00000001004df66e in mark_object (arg=<optimized out>)
>>      at /usr/src/debug/emacs-24.3-4/src/alloc.c:5914
>> #5  0x00000001004df585 in mark_object (arg=<optimized out>)
>>      at /usr/src/debug/emacs-24.3-4/src/alloc.c:5808
>> #6  0x00000001004dfa4e in mark_vectorlike (
>>      ptr=0x100f66f28 <bss_sbrk_buffer+6955080>)
>>      at /usr/src/debug/emacs-24.3-4/src/alloc.c:5501
>> ... snip ...
>> #2606 0x00000001004dfaf4 in mark_buffer (buffer=<optimized out>)
>>      at /usr/src/debug/emacs-24.3-4/src/alloc.c:5552
>> #2607 0x00000001004dff2c in Fgarbage_collect ()
>>      at /usr/src/debug/emacs-24.3-4/src/alloc.c:5181
>> #2608 0x0000000000000000 in ?? ()
>
> I don't know whether 2608 stack frames is unusual or not.  Is this 
> enough to cause a stack overflow?
I don't know the answer to that for emacs, but in general that's an 
exceedingly deep stack that would normally indicate some sort of 
infinite recursion. Would you actually expect an object tree in emacs to 
be 2000+ pointers deep? No plausible non-bug scenarios leap to mind 
right off...

>
>> I have the full backtrace saved to file, let me know if that would be
>> useful (there wasn't anything obvious that I could see, just more of the
>> same). Meanwhile, I verified that none of the addresses printed is
>> repeated, so it doesn't seem to be due to an obvious cycle in the object
>> graph.
>
> From what you've shown, it appears that most of the addresses have 
> been optimized out.  I think you would need an unoptimized build in 
> order to check that, wouldn't you?
Probably, yes. That's why I said no "obvious" cycles -- at least the 400 
pointers that are shown don't show a problem.

>
>> The crash happened when I foregrounded a stopped emacs. I tried playing
>> around with various breakpoints while repeatedly sending ^Z, but no luck
>> repeating the "feat" yet.
>>
>> Ideas?
>
> Can you trigger the bug by calling garbage collection manually (M-x 
> garbage-collect)?  What happens if you put a breakpoint at 
> Fgarbage_collect and step through it?  (Again, you might need an 
> unoptimized build before that will be useful.)
I tried breaking on Fgarbage_collect and hitting ^Z no love. I also 
tried setting a breakpoint on one of those other internal functions, 
with an ignore count intended to trigger it deep in a GC cycle. It 
triggered some tens of frames deep and ^Z there didn't cause trouble 
either. I wonder if the GC cycle just happened to coincide with 
reactivating emacs (perhaps triggered by some internal timeout that 
elapsed while it was stopped?)

>
> There are lots of lisp variables that can be used to control garbage 
> collection and get information about it.  See the section on garbage 
> collection in the elisp manual.  For example, you could try 
> customizing garbage-collection-messages.  Or you could play with 
> gc-cons-threshold.
I didn't see anything glaringly useful there... the messages just 
announce a GC run, which gdb can catch just fine. There doesn't seem to 
be any way of tracking how deep an object tree emacs traversed, or how 
many objects were freed.

Did you have something in particular in mind?

Ryan

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


--
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: 64-bit emacs crashes a lot

[Ken Brown]

On 8/10/2013 11:24 AM, Ryan Johnson wrote:
> On 10/08/2013 9:59 AM, Ken Brown wrote:
>> On 8/9/2013 11:28 PM, Ryan Johnson wrote:
>>> On 08/08/2013 2:00 PM, Ryan Johnson wrote:
>>>> On 08/08/2013 1:42 PM, Ken Brown wrote:
>>>>> On 8/5/2013 11:29 AM, Ryan Johnson wrote:
>>>>>> On 05/08/2013 11:00 AM, Ken Brown wrote:
>>>>>>> On 8/3/2013 3:05 PM, Ryan Johnson wrote:
>>>>>>>> On 02/08/2013 8:07 AM, Ryan Johnson wrote:
>>>>>>>>> On 02/08/2013 7:04 AM, Ken Brown wrote:
>>>>>>>>>> On 8/2/2013 4:02 AM, Corinna Vinschen wrote:
>>>>>>>>>>> On Aug  1 22:46, Ryan Johnson wrote:
>>>>>>>>>>>> Here's a new one... I started a compilation, but before it
>>>>>>>>>>>> actually
>>>>>>>>>>>> invoked the command it started pegging the CPU. After
>>>>>>>>>>>> ^G^G^G, it
>>>>>>>>>>>> crashed with the following:
>>>>>>>>>>>>> Auto-save? (y or n) y
>>>>>>>>>>>>>       0 [main] emacs 5076 C:\cygwin64\bin\emacs-nox.exe: ***
>>>>>>>>>>>>> fatal
>>>>>>>>>>>>> error - Internal error: TP_NUM_W_BUFS too small 2268032 >= 10.
>>>>>>>>>>>
>>>>>>>>>>> That looks like a memory overwrite.  2268032 is 0x229b80, which
>>>>>>>>>>> looks
>>>>>>>>>>> suspiciously like a stack address.  And the overwritten value is
>>>>>>>>>>> on the
>>>>>>>>>>> stack, too, well within the cygwin TLS area.  If *this* value
>>>>>>>>>>> gets
>>>>>>>>>>> overwritten, the TLS is probbaly totally hosed at this point.
>>>>>>>>>>> There's
>>>>>>>>>>> just no way to infer the culprit from this limited info.
>>>>>>>>>>
>>>>>>>>>> Could this be BLODA?  Ryan, I noticed that you wrote in a
>>>>>>>>>> different
>>>>>>>>>> thread, "I recently migrated to 64-bit cygwin...and so far
>>>>>>>>>> have not
>>>>>>>>>> had to disable Windows Defender; the latter was a recurring
>>>>>>>>>> source of
>>>>>>>>>> trouble for my previous 32-bit cygwin install on Win7/64."
>>>>>>>>> This would be a whole new level of nasty from a BLODA... I thought
>>>>>>>>> they only interfered with fork()?
>>>>>>>>>
>>>>>>>>> However, this *is* Windows Defender we're talking about... service
>>>>>>>>> disabled and all cygwin processes restarted. I'll let you know
>>>>>>>>> in a
>>>>>>>>> day or so if the crashes go away.
>>>>>>>> Rats. I just had another crash, the "Fatal error 6" variety.
>>>>>>>> Windows
>>>>>>>> Defender has not turned itself back on (it's been known to do
>>>>>>>> that), and
>>>>>>>> a scan of the BLODA list didn't match anything else on my system.
>>>>>>>>
>>>>>>>> So I don't think it's BLODA...
>>>>>>>>
>>>>>>>> Ideas?
>>>>>>>
>>>>>>> Not really, other than the obvious: (a) Find a reproducible way of
>>>>>>> making emacs-nox crash.  (b) Catch the crash in gdb by setting a
>>>>>>> suitable break point.
>>> Got one! Looks like a stack overflow somewhere in the garbage collector:
>>>
>>> Program received signal SIGSEGV, Segmentation fault.
>>> [Switching to Thread 5316.0x1af4]
>>> 0x00000001004df44a in mark_object (arg=<optimized out>)
>>>      at /usr/src/debug/emacs-24.3-4/src/alloc.c:5903
>>> 5903            if (CONS_MARKED_P (ptr))
>>> (gdb) bt
>>> #0  0x00000001004df44a in mark_object (arg=<optimized out>)
>>>      at /usr/src/debug/emacs-24.3-4/src/alloc.c:5903
>>> #1  0x00000001004df66e in mark_object (arg=<optimized out>)
>>>      at /usr/src/debug/emacs-24.3-4/src/alloc.c:5914
>>> #2  0x00000001004df593 in mark_object (arg=<optimized out>)
>>>      at /usr/src/debug/emacs-24.3-4/src/alloc.c:5809
>>> #3  0x00000001004df66e in mark_object (arg=<optimized out>)
>>>      at /usr/src/debug/emacs-24.3-4/src/alloc.c:5914
>>> #4  0x00000001004df66e in mark_object (arg=<optimized out>)
>>>      at /usr/src/debug/emacs-24.3-4/src/alloc.c:5914
>>> #5  0x00000001004df585 in mark_object (arg=<optimized out>)
>>>      at /usr/src/debug/emacs-24.3-4/src/alloc.c:5808
>>> #6  0x00000001004dfa4e in mark_vectorlike (
>>>      ptr=0x100f66f28 <bss_sbrk_buffer+6955080>)
>>>      at /usr/src/debug/emacs-24.3-4/src/alloc.c:5501
>>> ... snip ...
>>> #2606 0x00000001004dfaf4 in mark_buffer (buffer=<optimized out>)
>>>      at /usr/src/debug/emacs-24.3-4/src/alloc.c:5552
>>> #2607 0x00000001004dff2c in Fgarbage_collect ()
>>>      at /usr/src/debug/emacs-24.3-4/src/alloc.c:5181
>>> #2608 0x0000000000000000 in ?? ()
>>
>> I don't know whether 2608 stack frames is unusual or not.  Is this
>> enough to cause a stack overflow?
> I don't know the answer to that for emacs, but in general that's an
> exceedingly deep stack that would normally indicate some sort of
> infinite recursion. Would you actually expect an object tree in emacs to
> be 2000+ pointers deep? No plausible non-bug scenarios leap to mind
> right off...

I'd be very surprised if there were a bug in the garbage collection 
routine that's causing this.  If there were, I'd expect to see lots of 
people reporting this.  Could there be some memory corruption that 
creeps in when you suspend/resume emacs?  You did say that the crashes 
are less frequent since you deactivated Windows Defender, so I'm not 
sure you can rule out BLODA.

By the way, are your crashes always related to suspending and resuming 
emacs?  I don't recall that you said that before, but you keep 
mentioning ^Z.  Do you still get crashes if you never suspend emacs? 
You could also try one of the GUI versions of emacs to see if you get 
crashes.  "Suspending" in that case simply iconifies the frame.

>>
>>> I have the full backtrace saved to file, let me know if that would be
>>> useful (there wasn't anything obvious that I could see, just more of the
>>> same). Meanwhile, I verified that none of the addresses printed is
>>> repeated, so it doesn't seem to be due to an obvious cycle in the object
>>> graph.
>>
>> From what you've shown, it appears that most of the addresses have
>> been optimized out.  I think you would need an unoptimized build in
>> order to check that, wouldn't you?
> Probably, yes. That's why I said no "obvious" cycles -- at least the 400
> pointers that are shown don't show a problem.
>
>>
>>> The crash happened when I foregrounded a stopped emacs. I tried playing
>>> around with various breakpoints while repeatedly sending ^Z, but no luck
>>> repeating the "feat" yet.
>>>
>>> Ideas?
>>
>> Can you trigger the bug by calling garbage collection manually (M-x
>> garbage-collect)?  What happens if you put a breakpoint at
>> Fgarbage_collect and step through it?  (Again, you might need an
>> unoptimized build before that will be useful.)
> I tried breaking on Fgarbage_collect and hitting ^Z no love. I also
> tried setting a breakpoint on one of those other internal functions,
> with an ignore count intended to trigger it deep in a GC cycle. It
> triggered some tens of frames deep and ^Z there didn't cause trouble
> either. I wonder if the GC cycle just happened to coincide with
> reactivating emacs (perhaps triggered by some internal timeout that
> elapsed while it was stopped?)
>
>>
>> There are lots of lisp variables that can be used to control garbage
>> collection and get information about it.  See the section on garbage
>> collection in the elisp manual.  For example, you could try
>> customizing garbage-collection-messages.  Or you could play with
>> gc-cons-threshold.
> I didn't see anything glaringly useful there... the messages just
> announce a GC run, which gdb can catch just fine. There doesn't seem to
> be any way of tracking how deep an object tree emacs traversed, or how
> many objects were freed.

Sorry, I misread what the message would be.  I should have said that you 
could look directly at the output from garbage-collect, which you can 
see if you evaluate (garbage-collect) in the *scratch* buffer.  But, as 
I said above, I'm not sure that garbage collection is the underlying 
problem here.

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: 64-bit emacs crashes a lot

[Eli Zaretskii]

> > #2606 0x00000001004dfaf4 in mark_buffer (buffer=<optimized out>)
> >      at /usr/src/debug/emacs-24.3-4/src/alloc.c:5552
> > #2607 0x00000001004dff2c in Fgarbage_collect ()
> >      at /usr/src/debug/emacs-24.3-4/src/alloc.c:5181
> > #2608 0x0000000000000000 in ?? ()
> 
> I don't know whether 2608 stack frames is unusual or not.

It isn't.  I've seen perfectly good GCs that take many tens of
thousands of stack frames.  2608 doesn't even scratch the limit.

--
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: 64-bit emacs crashes a lot

[Ryan Johnson]

On 10/08/2013 2:01 PM, Ken Brown wrote:
> On 8/10/2013 11:24 AM, Ryan Johnson wrote:
>> On 10/08/2013 9:59 AM, Ken Brown wrote:
>>> On 8/9/2013 11:28 PM, Ryan Johnson wrote:
>>>> On 08/08/2013 2:00 PM, Ryan Johnson wrote:
>>>>> On 08/08/2013 1:42 PM, Ken Brown wrote:
>>>>>> On 8/5/2013 11:29 AM, Ryan Johnson wrote:
>>>>>>> On 05/08/2013 11:00 AM, Ken Brown wrote:
>>>>>>>> On 8/3/2013 3:05 PM, Ryan Johnson wrote:
>>>>>>>>> On 02/08/2013 8:07 AM, Ryan Johnson wrote:
>>>>>>>>>> On 02/08/2013 7:04 AM, Ken Brown wrote:
>>>>>>>>>>> On 8/2/2013 4:02 AM, Corinna Vinschen wrote:
>>>>>>>>>>>> On Aug  1 22:46, Ryan Johnson wrote:
>>>>>>>>>>>>> Here's a new one... I started a compilation, but before it
>>>>>>>>>>>>> actually
>>>>>>>>>>>>> invoked the command it started pegging the CPU. After
>>>>>>>>>>>>> ^G^G^G, it
>>>>>>>>>>>>> crashed with the following:
>>>>>>>>>>>>>> Auto-save? (y or n) y
>>>>>>>>>>>>>>       0 [main] emacs 5076 C:\cygwin64\bin\emacs-nox.exe: ***
>>>>>>>>>>>>>> fatal
>>>>>>>>>>>>>> error - Internal error: TP_NUM_W_BUFS too small 2268032 
>>>>>>>>>>>>>> >= 10.
>>>>>>>>>>>>
>>>>>>>>>>>> That looks like a memory overwrite.  2268032 is 0x229b80, 
>>>>>>>>>>>> which
>>>>>>>>>>>> looks
>>>>>>>>>>>> suspiciously like a stack address.  And the overwritten 
>>>>>>>>>>>> value is
>>>>>>>>>>>> on the
>>>>>>>>>>>> stack, too, well within the cygwin TLS area.  If *this* value
>>>>>>>>>>>> gets
>>>>>>>>>>>> overwritten, the TLS is probbaly totally hosed at this point.
>>>>>>>>>>>> There's
>>>>>>>>>>>> just no way to infer the culprit from this limited info.
>>>>>>>>>>>
>>>>>>>>>>> Could this be BLODA?  Ryan, I noticed that you wrote in a
>>>>>>>>>>> different
>>>>>>>>>>> thread, "I recently migrated to 64-bit cygwin...and so far
>>>>>>>>>>> have not
>>>>>>>>>>> had to disable Windows Defender; the latter was a recurring
>>>>>>>>>>> source of
>>>>>>>>>>> trouble for my previous 32-bit cygwin install on Win7/64."
>>>>>>>>>> This would be a whole new level of nasty from a BLODA... I 
>>>>>>>>>> thought
>>>>>>>>>> they only interfered with fork()?
>>>>>>>>>>
>>>>>>>>>> However, this *is* Windows Defender we're talking about... 
>>>>>>>>>> service
>>>>>>>>>> disabled and all cygwin processes restarted. I'll let you know
>>>>>>>>>> in a
>>>>>>>>>> day or so if the crashes go away.
>>>>>>>>> Rats. I just had another crash, the "Fatal error 6" variety.
>>>>>>>>> Windows
>>>>>>>>> Defender has not turned itself back on (it's been known to do
>>>>>>>>> that), and
>>>>>>>>> a scan of the BLODA list didn't match anything else on my system.
>>>>>>>>>
>>>>>>>>> So I don't think it's BLODA...
>>>>>>>>>
>>>>>>>>> Ideas?
>>>>>>>>
>>>>>>>> Not really, other than the obvious: (a) Find a reproducible way of
>>>>>>>> making emacs-nox crash.  (b) Catch the crash in gdb by setting a
>>>>>>>> suitable break point.
>>>> Got one! Looks like a stack overflow somewhere in the garbage 
>>>> collector:
>>>>
>>>> Program received signal SIGSEGV, Segmentation fault.
>>>> [Switching to Thread 5316.0x1af4]
>>>> 0x00000001004df44a in mark_object (arg=<optimized out>)
>>>>      at /usr/src/debug/emacs-24.3-4/src/alloc.c:5903
>>>> 5903            if (CONS_MARKED_P (ptr))
>>>> (gdb) bt
>>>> #0  0x00000001004df44a in mark_object (arg=<optimized out>)
>>>>      at /usr/src/debug/emacs-24.3-4/src/alloc.c:5903
>>>> #1  0x00000001004df66e in mark_object (arg=<optimized out>)
>>>>      at /usr/src/debug/emacs-24.3-4/src/alloc.c:5914
>>>> #2  0x00000001004df593 in mark_object (arg=<optimized out>)
>>>>      at /usr/src/debug/emacs-24.3-4/src/alloc.c:5809
>>>> #3  0x00000001004df66e in mark_object (arg=<optimized out>)
>>>>      at /usr/src/debug/emacs-24.3-4/src/alloc.c:5914
>>>> #4  0x00000001004df66e in mark_object (arg=<optimized out>)
>>>>      at /usr/src/debug/emacs-24.3-4/src/alloc.c:5914
>>>> #5  0x00000001004df585 in mark_object (arg=<optimized out>)
>>>>      at /usr/src/debug/emacs-24.3-4/src/alloc.c:5808
>>>> #6  0x00000001004dfa4e in mark_vectorlike (
>>>>      ptr=0x100f66f28 <bss_sbrk_buffer+6955080>)
>>>>      at /usr/src/debug/emacs-24.3-4/src/alloc.c:5501
>>>> ... snip ...
>>>> #2606 0x00000001004dfaf4 in mark_buffer (buffer=<optimized out>)
>>>>      at /usr/src/debug/emacs-24.3-4/src/alloc.c:5552
>>>> #2607 0x00000001004dff2c in Fgarbage_collect ()
>>>>      at /usr/src/debug/emacs-24.3-4/src/alloc.c:5181
>>>> #2608 0x0000000000000000 in ?? ()
>>>
>>> I don't know whether 2608 stack frames is unusual or not.  Is this
>>> enough to cause a stack overflow?
>> I don't know the answer to that for emacs, but in general that's an
>> exceedingly deep stack that would normally indicate some sort of
>> infinite recursion. Would you actually expect an object tree in emacs to
>> be 2000+ pointers deep? No plausible non-bug scenarios leap to mind
>> right off...
>
> I'd be very surprised if there were a bug in the garbage collection 
> routine that's causing this.  If there were, I'd expect to see lots of 
> people reporting this.  Could there be some memory corruption that 
> creeps in when you suspend/resume emacs?  You did say that the crashes 
> are less frequent since you deactivated Windows Defender, so I'm not 
> sure you can rule out BLODA.
>
> By the way, are your crashes always related to suspending and resuming 
> emacs?  I don't recall that you said that before, but you keep 
> mentioning ^Z.  Do you still get crashes if you never suspend emacs? 
> You could also try one of the GUI versions of emacs to see if you get 
> crashes.  "Suspending" in that case simply iconifies the frame.
>
>>>
>>>> I have the full backtrace saved to file, let me know if that would be
>>>> useful (there wasn't anything obvious that I could see, just more 
>>>> of the
>>>> same). Meanwhile, I verified that none of the addresses printed is
>>>> repeated, so it doesn't seem to be due to an obvious cycle in the 
>>>> object
>>>> graph.
>>>
>>> From what you've shown, it appears that most of the addresses have
>>> been optimized out.  I think you would need an unoptimized build in
>>> order to check that, wouldn't you?
>> Probably, yes. That's why I said no "obvious" cycles -- at least the 400
>> pointers that are shown don't show a problem.
>>
>>>
>>>> The crash happened when I foregrounded a stopped emacs. I tried 
>>>> playing
>>>> around with various breakpoints while repeatedly sending ^Z, but no 
>>>> luck
>>>> repeating the "feat" yet.
>>>>
>>>> Ideas?
>>>
>>> Can you trigger the bug by calling garbage collection manually (M-x
>>> garbage-collect)?  What happens if you put a breakpoint at
>>> Fgarbage_collect and step through it?  (Again, you might need an
>>> unoptimized build before that will be useful.)
>> I tried breaking on Fgarbage_collect and hitting ^Z no love. I also
>> tried setting a breakpoint on one of those other internal functions,
>> with an ignore count intended to trigger it deep in a GC cycle. It
>> triggered some tens of frames deep and ^Z there didn't cause trouble
>> either. I wonder if the GC cycle just happened to coincide with
>> reactivating emacs (perhaps triggered by some internal timeout that
>> elapsed while it was stopped?)
>>
>>>
>>> There are lots of lisp variables that can be used to control garbage
>>> collection and get information about it.  See the section on garbage
>>> collection in the elisp manual.  For example, you could try
>>> customizing garbage-collection-messages.  Or you could play with
>>> gc-cons-threshold.
>> I didn't see anything glaringly useful there... the messages just
>> announce a GC run, which gdb can catch just fine. There doesn't seem to
>> be any way of tracking how deep an object tree emacs traversed, or how
>> many objects were freed.
>
> Sorry, I misread what the message would be.  I should have said that 
> you could look directly at the output from garbage-collect, which you 
> can see if you evaluate (garbage-collect) in the *scratch* buffer.  
> But, as I said above, I'm not sure that garbage collection is the 
> underlying problem here.
Agree it's probably not GC... GC would just tend to trip over any bad 
pointers that were lurking around...

After a rash of crashes where I either forgot to attach gdb or forgot to 
set appropriate breakpoints, I finally managed to catch the stack trace 
below. It occurred during M-x compile, while emacs parsed the 
compilation's rather copious output, which is by far the most common 
type of crash I've been getting lately. I have no idea how to interpret 
the backtrace, though.

What should I try next? I assume I'll need a debug-compiled emacs so the 
backtrace isn't garbage? If so, (a) what is the most straightforward way 
to compile emacs-nox that way and (b) what would I be looking for if I 
encountered the below stack trace in a debug build?

Thanks,
Ryan

Breakpoint 2, 0x000000010055d190 in kill ()
(gdb) bt
#0  0x000000010055d190 in kill ()
#1  0x000000010053702e in process_send_signal 
(process=process@entry=25781889629, signo=signo@entry=2, 
current_group=<optimized out>, nomsg=nomsg@entry=0) at 
/usr/src/debug/emacs-24.3-4/src/process.c:5948
#2  0x0000000100537198 in Finterrupt_process (process=25781889629, 
current_group=<optimized out>) at 
/usr/src/debug/emacs-24.3-4/src/process.c:5966
#3  0x00000001004f7761 in Ffuncall (nargs=<optimized out>, 
args=<optimized out>) at /usr/src/debug/emacs-24.3-4/src/eval.c:2781
#4  0x000000010052b5ed in exec_byte_code (bytestr=4294962344, 
vector=2268896, maxdepth=2, args_template=4303595040, nargs=4304157760, 
args=0x100902032 <bss_sbrk_buffer+250194>)
     at /usr/src/debug/emacs-24.3-4/src/bytecode.c:900
#5  0x00000001004f7293 in funcall_lambda (fun=25778101277, 
nargs=nargs@entry=0, arg_vector=arg_vector@entry=0x22a188) at 
/usr/src/debug/emacs-24.3-4/src/eval.c:3010
#6  0x00000001004f75cb in Ffuncall (nargs=nargs@entry=1, 
args=args@entry=0x22a180) at /usr/src/debug/emacs-24.3-4/src/eval.c:2839
#7  0x00000001004f8bef in apply1 (fn=25778613730, fn@entry=4304161216, 
arg=arg@entry=4304412722) at /usr/src/debug/emacs-24.3-4/src/eval.c:2539
#8  0x00000001004f3567 in Fcall_interactively (function=4304161216, 
record_flag=4304412722, keys=4299711881) at 
/usr/src/debug/emacs-24.3-4/src/callint.c:377
#9  0x00000001004f7752 in Ffuncall (nargs=nargs@entry=4, 
args=args@entry=0x22a3b0) at /usr/src/debug/emacs-24.3-4/src/eval.c:2785
#10 0x00000001004f91b7 in call3 (fn=<optimized out>, arg1=<optimized 
out>, arg2=<optimized out>, arg3=<optimized out>) at 
/usr/src/debug/emacs-24.3-4/src/eval.c:2603
#11 0x00000001004883cd in Fcommand_execute (cmd=<optimized out>, 
record_flag=<optimized out>, keys=<optimized out>, special=<optimized 
out>) at /usr/src/debug/emacs-24.3-4/src/keyboard.c:10241
#12 0x0000000100494ae8 in command_loop_1 () at 
/usr/src/debug/emacs-24.3-4/src/keyboard.c:1587
#13 0x00000001004f5c2e in internal_condition_case 
(bfun=bfun@entry=0x100494740 <command_loop_1>, handlers=4304470642, 
hfun=hfun@entry=0x10048ae40 <cmd_error>) at 
/usr/src/debug/emacs-24.3-4/src/eval.c:1289
#14 0x000000010048630a in command_loop_2 
(ignore=ignore@entry=4304412722) at 
/usr/src/debug/emacs-24.3-4/src/keyboard.c:1168
#15 0x00000001004f5aef in internal_catch (tag=<optimized out>, 
func=func@entry=0x1004862e0 <command_loop_2>, arg=4304412722) at 
/usr/src/debug/emacs-24.3-4/src/eval.c:1060
#16 0x000000010048a914 in command_loop () at 
/usr/src/debug/emacs-24.3-4/src/keyboard.c:1147
#17 recursive_edit_1 () at /usr/src/debug/emacs-24.3-4/src/keyboard.c:779
#18 0x000000010048ac47 in Frecursive_edit () at 
/usr/src/debug/emacs-24.3-4/src/keyboard.c:843
#19 0x000000010055e8ef in main (argc=<optimized out>, argv=<optimized 
out>) at /usr/src/debug/emacs-24.3-4/src/emacs.c:1537


--
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: 64-bit emacs crashes a lot

[Ryan Johnson]

On 14/08/2013 10:04 AM, Ryan Johnson wrote:
> After a rash of crashes where I either forgot to attach gdb or forgot 
> to set appropriate breakpoints, I finally managed to catch the stack 
> trace below. It occurred during M-x compile, while emacs parsed the 
> compilation's rather copious output, which is by far the most common 
> type of crash I've been getting lately. I have no idea how to 
> interpret the backtrace, though.
False alarm... that backtrace was triggered by me attempting to 
terminate the compile with C-c C-k, which emacs handled fine once gdb 
let it continue.

Ryan


--
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: 64-bit emacs crashes a lot

[Ryan Johnson]

On 14/08/2013 10:04 AM, Ryan Johnson wrote:
> On 10/08/2013 2:01 PM, Ken Brown wrote:
>> I'm not sure that garbage collection is the underlying problem here.
> Agree it's probably not GC... GC would just tend to trip over any bad 
> pointers that were lurking around...
>
> After a rash of crashes where I either forgot to attach gdb or forgot 
> to set appropriate breakpoints, I finally managed to catch the stack 
> trace below. It occurred during M-x compile, while emacs parsed the 
> compilation's rather copious output, which is by far the most common 
> type of crash I've been getting lately.
>
This time I really caught one, again during a compile (aside: the crash 
is usually right at the beginning of a compile, not partway through as 
my previous comment suggested). The short version is that I seem to have 
tickled a latent bug in emacs' character handling at character.c:189, 
where processing an 8-bit char could result in a return value larger 
than CHAR_MAX (which later triggers an abort). New stack trace and 
analysis follow.

A quick peek at the backtrace and some source diving suggests something 
went wrong in bidi_fetch_char (bidi.c:928)... which unfortunately has 
about a dozen different ways of coming up with a character. There are 
only two major flavors that look like they can possibly fail, though: 
via STRING_CHAR_AND_LENGTH or UNIBYTE_TO_CHAR. Both are macros in 
character.h. The latter calls BYTE8_TO_CHAR, which simply returns 
byte+0x3fff00 (and can only take values between 0x3ffe80 and 0x3fff7f 
regardless of whether "byte" is signed or unsigned, though I think it's 
unsigned). The former is a pretty large macro (lots of ?:) that usually 
ends up fetching a char from p[], but has a test for sign bit to prevent 
unwanted sign extension (but again, I'm pretty sure they use unsigned 
bytes, so that shouldn't be an issue). However, the macro bottoms out by 
calling string_char (character.c:170), which includes the following 
expression:

((p)[1] & 0x3F) << 18

That expression can return values significantly larger than CHAR_MAX 
(0x3FFFFF), the largest such being 0xFC0000.

I suspect this is a bug in emacs (typo), and that the mask should really 
be 0xF: that would keep the value in bounds, and would also mirror a 
different branch of the if/else that differs only in the index passed to 
p[] and in using 0xF for the leading byte instead of 0x3F.

On the other hand, the offending code seems to be trying to decode a 
5-byte unicode sequence. If so, then the bug is not the mask 0x3F, but 
(a) forgetting to actually fetch the most significant two bits of the 
code point from p[0], and (b) having CHAR_MAX smaller than a valid 
5-byte code point. Interestingly, CHAR_MAX is 0x3FFFFF---five F---while 
the largest valid 5-byte code point is 0x3FFFFFF---six F---and the 
largest 4-byte is 0x1FFFFF, not 0x3FFFFF (though perhaps the latter is 
intentional, to give emacs some out-of-band values to work with?). 
Meanwhile, 5- and 6-byte utf-8 sequences were banished in 2003 
(according to the Wikipedia entry on UTF-8), so it seems like this code 
path shouldn't even exist.

I don't quite grok what sequence of input bytes it would take to tickle 
the above code path. I suspect that the input byte is invalid (= illegal 
unicode), due to the same memory corruption that made GC seg fault in a 
past crash, and just happens to tickle this latent bug. However, this 
charset bug should probably be sorted out and fixed, regardless of 
whether it's the cause of the troubles or merely the symptom of 
something deeper.

Thoughts?
Ryan

Breakpoint 2, 0x000000010055d190 in kill ()
(gdb) bt
#0  0x000000010055d190 in kill ()
#1  0x000000010053702e in process_send_signal (process=<optimized out>, 
signo=signo@entry=1, current_group=<optimized out>, nomsg=nomsg@entry=1) 
at /usr/src/debug/emacs-24.3-4/src/process.c:5948
#2  0x0000000100537ae0 in kill_buffer_processes (buffer=4304412722) at 
/usr/src/debug/emacs-24.3-4/src/process.c:7157
#3  0x0000000100485cb0 in shut_down_emacs (sig=sig@entry=6, 
stuff=4304412722) at /usr/src/debug/emacs-24.3-4/src/emacs.c:1915
#4  0x0000000100485ea7 in terminate_due_to_signal (sig=6, 
backtrace_limit=10) at /usr/src/debug/emacs-24.3-4/src/emacs.c:329
#5  0x00000001004a0363 in emacs_abort () at 
/usr/src/debug/emacs-24.3-4/src/sysdep.c:2152
#6  0x000000010046d365 in bidi_get_type (ch=<optimized out>, 
override=override@entry=NEUTRAL_DIR) at 
/usr/src/debug/emacs-24.3-4/src/bidi.c:107
#7  0x000000010046d527 in bidi_get_type (override=NEUTRAL_DIR, 
ch=<optimized out>) at /usr/src/debug/emacs-24.3-4/src/bidi.c:104
#8  bidi_resolve_explicit_1 (bidi_it=bidi_it@entry=0x225d18) at 
/usr/src/debug/emacs-24.3-4/src/bidi.c:1411
#9  0x000000010046d8b5 in bidi_resolve_explicit 
(bidi_it=bidi_it@entry=0x225d18) at 
/usr/src/debug/emacs-24.3-4/src/bidi.c:1540
#10 0x000000010046db0a in bidi_resolve_weak 
(bidi_it=bidi_it@entry=0x225d18) at 
/usr/src/debug/emacs-24.3-4/src/bidi.c:1625
#11 0x000000010046e3c1 in bidi_resolve_neutral 
(bidi_it=bidi_it@entry=0x225d18) at 
/usr/src/debug/emacs-24.3-4/src/bidi.c:1861
#12 0x000000010046e7a0 in bidi_type_of_next_char (bidi_it=0x225d18) at 
/usr/src/debug/emacs-24.3-4/src/bidi.c:2032
#13 bidi_level_of_next_char (bidi_it=bidi_it@entry=0x225d18) at 
/usr/src/debug/emacs-24.3-4/src/bidi.c:2145
#14 0x000000010046faba in bidi_move_to_visually_next 
(bidi_it=bidi_it@entry=0x225d18) at 
/usr/src/debug/emacs-24.3-4/src/bidi.c:2355
#15 0x000000010041c44f in set_iterator_to_next (it=it@entry=0x225370, 
reseat_p=reseat_p@entry=1) at /usr/src/debug/emacs-24.3-4/src/xdisp.c:7109
#16 0x000000010042477a in display_line (it=it@entry=0x225370) at 
/usr/src/debug/emacs-24.3-4/src/xdisp.c:19864
#17 0x0000000100426cd8 in try_window (window=window@entry=25782575869, 
pos=..., flags=flags@entry=1) at 
/usr/src/debug/emacs-24.3-4/src/xdisp.c:16353
#18 0x000000010042c45a in redisplay_window 
(window=window@entry=25782575869, 
just_this_one_p=just_this_one_p@entry=0) at 
/usr/src/debug/emacs-24.3-4/src/xdisp.c:15879
#19 0x000000010042e2b6 in redisplay_window_0 
(window=window@entry=25782575869) at 
/usr/src/debug/emacs-24.3-4/src/xdisp.c:13934
#20 0x00000001004f5d9c in internal_condition_case_1 
(bfun=bfun@entry=0x10042e290 <redisplay_window_0>, arg=25782575869, 
handlers=4304384246, hfun=hfun@entry=0x10040fe90 <redisplay_window_error>)
     at /usr/src/debug/emacs-24.3-4/src/eval.c:1327
#21 0x000000010041458a in redisplay_windows (window=25782575869) at 
/usr/src/debug/emacs-24.3-4/src/xdisp.c:13914
#22 0x00000001004145a8 in redisplay_windows (window=25780199573) at 
/usr/src/debug/emacs-24.3-4/src/xdisp.c:13908
#23 0x000000010042f449 in redisplay_internal () at 
/usr/src/debug/emacs-24.3-4/src/xdisp.c:13493
#24 0x0000000100430f95 in redisplay_preserve_echo_area 
(from_where=<optimized out>) at 
/usr/src/debug/emacs-24.3-4/src/xdisp.c:13754
#25 0x0000000100535faa in wait_reading_process_output 
(time_limit=<optimized out>, nsecs=0, read_kbd=read_kbd@entry=-1, 
do_display=do_display@entry=true, wait_for_cell=4304412722, 
wait_proc=wait_proc@entry=0x0,
     just_wait_proc=just_wait_proc@entry=0) at 
/usr/src/debug/emacs-24.3-4/src/process.c:4862
#26 0x00000001004098da in sit_for (timeout=<optimized out>, 
reading=reading@entry=true, display_option=display_option@entry=1) at 
/usr/src/debug/emacs-24.3-4/src/dispnew.c:5978
#27 0x0000000100491920 in read_char (commandflag=1, nmaps=2, 
maps=0x22a200, prev_event=4304412722, used_mouse_menu=0x22a327, 
end_time=end_time@entry=0x0) at 
/usr/src/debug/emacs-24.3-4/src/keyboard.c:2669
#28 0x00000001004926a3 in read_key_sequence 
(keybuf=keybuf@entry=0x22a470, prompt=<optimized out>, 
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-4/src/keyboard.c:9231
#29 0x000000010049495e in command_loop_1 () at 
/usr/src/debug/emacs-24.3-4/src/keyboard.c:1459
#30 0x00000001004f5c2e in internal_condition_case 
(bfun=bfun@entry=0x100494740 <command_loop_1>, handlers=4304470642, 
hfun=hfun@entry=0x10048ae40 <cmd_error>) at 
/usr/src/debug/emacs-24.3-4/src/eval.c:1289
#31 0x000000010048630a in command_loop_2 
(ignore=ignore@entry=4304412722) at 
/usr/src/debug/emacs-24.3-4/src/keyboard.c:1168
#32 0x00000001004f5aef in internal_catch (tag=<optimized out>, 
func=func@entry=0x1004862e0 <command_loop_2>, arg=4304412722) at 
/usr/src/debug/emacs-24.3-4/src/eval.c:1060
#33 0x000000010048a914 in command_loop () at 
/usr/src/debug/emacs-24.3-4/src/keyboard.c:1147
#34 recursive_edit_1 () at /usr/src/debug/emacs-24.3-4/src/keyboard.c:779
#35 0x000000010048ac47 in Frecursive_edit () at 
/usr/src/debug/emacs-24.3-4/src/keyboard.c:843
#36 0x000000010055e8ef in main (argc=<optimized out>, argv=<optimized 
out>) at /usr/src/debug/emacs-24.3-4/src/emacs.c:1537

>
> Thanks,
> Ryan
>
> Breakpoint 2, 0x000000010055d190 in kill ()
> (gdb) bt
> #0  0x000000010055d190 in kill ()
> #1  0x000000010053702e in process_send_signal 
> (process=process@entry=25781889629, signo=signo@entry=2, 
> current_group=<optimized out>, nomsg=nomsg@entry=0) at 
> /usr/src/debug/emacs-24.3-4/src/process.c:5948
> #2  0x0000000100537198 in Finterrupt_process (process=25781889629, 
> current_group=<optimized out>) at 
> /usr/src/debug/emacs-24.3-4/src/process.c:5966
> #3  0x00000001004f7761 in Ffuncall (nargs=<optimized out>, 
> args=<optimized out>) at /usr/src/debug/emacs-24.3-4/src/eval.c:2781
> #4  0x000000010052b5ed in exec_byte_code (bytestr=4294962344, 
> vector=2268896, maxdepth=2, args_template=4303595040, 
> nargs=4304157760, args=0x100902032 <bss_sbrk_buffer+250194>)
>     at /usr/src/debug/emacs-24.3-4/src/bytecode.c:900
> #5  0x00000001004f7293 in funcall_lambda (fun=25778101277, 
> nargs=nargs@entry=0, arg_vector=arg_vector@entry=0x22a188) at 
> /usr/src/debug/emacs-24.3-4/src/eval.c:3010
> #6  0x00000001004f75cb in Ffuncall (nargs=nargs@entry=1, 
> args=args@entry=0x22a180) at /usr/src/debug/emacs-24.3-4/src/eval.c:2839
> #7  0x00000001004f8bef in apply1 (fn=25778613730, fn@entry=4304161216, 
> arg=arg@entry=4304412722) at /usr/src/debug/emacs-24.3-4/src/eval.c:2539
> #8  0x00000001004f3567 in Fcall_interactively (function=4304161216, 
> record_flag=4304412722, keys=4299711881) at 
> /usr/src/debug/emacs-24.3-4/src/callint.c:377
> #9  0x00000001004f7752 in Ffuncall (nargs=nargs@entry=4, 
> args=args@entry=0x22a3b0) at /usr/src/debug/emacs-24.3-4/src/eval.c:2785
> #10 0x00000001004f91b7 in call3 (fn=<optimized out>, arg1=<optimized 
> out>, arg2=<optimized out>, arg3=<optimized out>) at 
> /usr/src/debug/emacs-24.3-4/src/eval.c:2603
> #11 0x00000001004883cd in Fcommand_execute (cmd=<optimized out>, 
> record_flag=<optimized out>, keys=<optimized out>, special=<optimized 
> out>) at /usr/src/debug/emacs-24.3-4/src/keyboard.c:10241
> #12 0x0000000100494ae8 in command_loop_1 () at 
> /usr/src/debug/emacs-24.3-4/src/keyboard.c:1587
> #13 0x00000001004f5c2e in internal_condition_case 
> (bfun=bfun@entry=0x100494740 <command_loop_1>, handlers=4304470642, 
> hfun=hfun@entry=0x10048ae40 <cmd_error>) at 
> /usr/src/debug/emacs-24.3-4/src/eval.c:1289
> #14 0x000000010048630a in command_loop_2 
> (ignore=ignore@entry=4304412722) at 
> /usr/src/debug/emacs-24.3-4/src/keyboard.c:1168
> #15 0x00000001004f5aef in internal_catch (tag=<optimized out>, 
> func=func@entry=0x1004862e0 <command_loop_2>, arg=4304412722) at 
> /usr/src/debug/emacs-24.3-4/src/eval.c:1060
> #16 0x000000010048a914 in command_loop () at 
> /usr/src/debug/emacs-24.3-4/src/keyboard.c:1147
> #17 recursive_edit_1 () at /usr/src/debug/emacs-24.3-4/src/keyboard.c:779
> #18 0x000000010048ac47 in Frecursive_edit () at 
> /usr/src/debug/emacs-24.3-4/src/keyboard.c:843
> #19 0x000000010055e8ef in main (argc=<optimized out>, argv=<optimized 
> out>) at /usr/src/debug/emacs-24.3-4/src/emacs.c:1537
>
>
> -- 
> 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
>


--
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: 64-bit emacs crashes a lot

[Ken Brown]

On 8/15/2013 8:32 AM, Ryan Johnson wrote:
> On 14/08/2013 10:04 AM, Ryan Johnson wrote:
>> On 10/08/2013 2:01 PM, Ken Brown wrote:
>>> I'm not sure that garbage collection is the underlying problem here.
>> Agree it's probably not GC... GC would just tend to trip over any bad
>> pointers that were lurking around...
>>
>> After a rash of crashes where I either forgot to attach gdb or forgot
>> to set appropriate breakpoints, I finally managed to catch the stack
>> trace below. It occurred during M-x compile, while emacs parsed the
>> compilation's rather copious output, which is by far the most common
>> type of crash I've been getting lately.
>>
> This time I really caught one, again during a compile (aside: the crash
> is usually right at the beginning of a compile, not partway through as
> my previous comment suggested). The short version is that I seem to have
> tickled a latent bug in emacs' character handling at character.c:189,
> where processing an 8-bit char could result in a return value larger
> than CHAR_MAX (which later triggers an abort). New stack trace and
> analysis follow.
>
> A quick peek at the backtrace and some source diving suggests something
> went wrong in bidi_fetch_char (bidi.c:928)... which unfortunately has
> about a dozen different ways of coming up with a character. There are
> only two major flavors that look like they can possibly fail, though:
> via STRING_CHAR_AND_LENGTH or UNIBYTE_TO_CHAR. Both are macros in
> character.h. The latter calls BYTE8_TO_CHAR, which simply returns
> byte+0x3fff00 (and can only take values between 0x3ffe80 and 0x3fff7f
> regardless of whether "byte" is signed or unsigned, though I think it's
> unsigned). The former is a pretty large macro (lots of ?:) that usually
> ends up fetching a char from p[], but has a test for sign bit to prevent
> unwanted sign extension (but again, I'm pretty sure they use unsigned
> bytes, so that shouldn't be an issue). However, the macro bottoms out by
> calling string_char (character.c:170), which includes the following
> expression:
>
> ((p)[1] & 0x3F) << 18
>
> That expression can return values significantly larger than CHAR_MAX
> (0x3FFFFF), the largest such being 0xFC0000.
>
> I suspect this is a bug in emacs (typo), and that the mask should really
> be 0xF: that would keep the value in bounds, and would also mirror a
> different branch of the if/else that differs only in the index passed to
> p[] and in using 0xF for the leading byte instead of 0x3F.
>
> On the other hand, the offending code seems to be trying to decode a
> 5-byte unicode sequence. If so, then the bug is not the mask 0x3F, but
> (a) forgetting to actually fetch the most significant two bits of the
> code point from p[0], and (b) having CHAR_MAX smaller than a valid
> 5-byte code point. Interestingly, CHAR_MAX is 0x3FFFFF---five F---while
> the largest valid 5-byte code point is 0x3FFFFFF---six F---and the
> largest 4-byte is 0x1FFFFF, not 0x3FFFFF (though perhaps the latter is
> intentional, to give emacs some out-of-band values to work with?).
> Meanwhile, 5- and 6-byte utf-8 sequences were banished in 2003
> (according to the Wikipedia entry on UTF-8), so it seems like this code
> path shouldn't even exist.
>
> I don't quite grok what sequence of input bytes it would take to tickle
> the above code path. I suspect that the input byte is invalid (= illegal
> unicode), due to the same memory corruption that made GC seg fault in a
> past crash, and just happens to tickle this latent bug. However, this
> charset bug should probably be sorted out and fixed, regardless of
> whether it's the cause of the troubles or merely the symptom of
> something deeper.
>
> Thoughts?
> Ryan

Eli is the expert on bidi.c (he wrote it).  He can probably tell you 
whether you've really bumped into an emacs bug here.

> Breakpoint 2, 0x000000010055d190 in kill ()
> (gdb) bt
> #0  0x000000010055d190 in kill ()
> #1  0x000000010053702e in process_send_signal (process=<optimized out>,
> signo=signo@entry=1, current_group=<optimized out>, nomsg=nomsg@entry=1)
> at /usr/src/debug/emacs-24.3-4/src/process.c:5948
> #2  0x0000000100537ae0 in kill_buffer_processes (buffer=4304412722) at
> /usr/src/debug/emacs-24.3-4/src/process.c:7157
> #3  0x0000000100485cb0 in shut_down_emacs (sig=sig@entry=6,
> stuff=4304412722) at /usr/src/debug/emacs-24.3-4/src/emacs.c:1915
> #4  0x0000000100485ea7 in terminate_due_to_signal (sig=6,
> backtrace_limit=10) at /usr/src/debug/emacs-24.3-4/src/emacs.c:329
> #5  0x00000001004a0363 in emacs_abort () at
> /usr/src/debug/emacs-24.3-4/src/sysdep.c:2152
> #6  0x000000010046d365 in bidi_get_type (ch=<optimized out>,
> override=override@entry=NEUTRAL_DIR) at
> /usr/src/debug/emacs-24.3-4/src/bidi.c:107
> #7  0x000000010046d527 in bidi_get_type (override=NEUTRAL_DIR,
> ch=<optimized out>) at /usr/src/debug/emacs-24.3-4/src/bidi.c:104
> #8  bidi_resolve_explicit_1 (bidi_it=bidi_it@entry=0x225d18) at
> /usr/src/debug/emacs-24.3-4/src/bidi.c:1411
> #9  0x000000010046d8b5 in bidi_resolve_explicit
> (bidi_it=bidi_it@entry=0x225d18) at
> /usr/src/debug/emacs-24.3-4/src/bidi.c:1540
> #10 0x000000010046db0a in bidi_resolve_weak
> (bidi_it=bidi_it@entry=0x225d18) at
> /usr/src/debug/emacs-24.3-4/src/bidi.c:1625
> #11 0x000000010046e3c1 in bidi_resolve_neutral
> (bidi_it=bidi_it@entry=0x225d18) at
> /usr/src/debug/emacs-24.3-4/src/bidi.c:1861
> #12 0x000000010046e7a0 in bidi_type_of_next_char (bidi_it=0x225d18) at
> /usr/src/debug/emacs-24.3-4/src/bidi.c:2032
> #13 bidi_level_of_next_char (bidi_it=bidi_it@entry=0x225d18) at
> /usr/src/debug/emacs-24.3-4/src/bidi.c:2145
> #14 0x000000010046faba in bidi_move_to_visually_next
> (bidi_it=bidi_it@entry=0x225d18) at
> /usr/src/debug/emacs-24.3-4/src/bidi.c:2355
> #15 0x000000010041c44f in set_iterator_to_next (it=it@entry=0x225370,
> reseat_p=reseat_p@entry=1) at /usr/src/debug/emacs-24.3-4/src/xdisp.c:7109
> #16 0x000000010042477a in display_line (it=it@entry=0x225370) at
> /usr/src/debug/emacs-24.3-4/src/xdisp.c:19864
> #17 0x0000000100426cd8 in try_window (window=window@entry=25782575869,
> pos=..., flags=flags@entry=1) at
> /usr/src/debug/emacs-24.3-4/src/xdisp.c:16353
> #18 0x000000010042c45a in redisplay_window
> (window=window@entry=25782575869,
> just_this_one_p=just_this_one_p@entry=0) at
> /usr/src/debug/emacs-24.3-4/src/xdisp.c:15879
> #19 0x000000010042e2b6 in redisplay_window_0
> (window=window@entry=25782575869) at
> /usr/src/debug/emacs-24.3-4/src/xdisp.c:13934
> #20 0x00000001004f5d9c in internal_condition_case_1
> (bfun=bfun@entry=0x10042e290 <redisplay_window_0>, arg=25782575869,
> handlers=4304384246, hfun=hfun@entry=0x10040fe90 <redisplay_window_error>)
>      at /usr/src/debug/emacs-24.3-4/src/eval.c:1327
> #21 0x000000010041458a in redisplay_windows (window=25782575869) at
> /usr/src/debug/emacs-24.3-4/src/xdisp.c:13914
> #22 0x00000001004145a8 in redisplay_windows (window=25780199573) at
> /usr/src/debug/emacs-24.3-4/src/xdisp.c:13908
> #23 0x000000010042f449 in redisplay_internal () at
> /usr/src/debug/emacs-24.3-4/src/xdisp.c:13493
> #24 0x0000000100430f95 in redisplay_preserve_echo_area
> (from_where=<optimized out>) at
> /usr/src/debug/emacs-24.3-4/src/xdisp.c:13754
> #25 0x0000000100535faa in wait_reading_process_output
> (time_limit=<optimized out>, nsecs=0, read_kbd=read_kbd@entry=-1,
> do_display=do_display@entry=true, wait_for_cell=4304412722,
> wait_proc=wait_proc@entry=0x0,
>      just_wait_proc=just_wait_proc@entry=0) at
> /usr/src/debug/emacs-24.3-4/src/process.c:4862
> #26 0x00000001004098da in sit_for (timeout=<optimized out>,
> reading=reading@entry=true, display_option=display_option@entry=1) at
> /usr/src/debug/emacs-24.3-4/src/dispnew.c:5978
> #27 0x0000000100491920 in read_char (commandflag=1, nmaps=2,
> maps=0x22a200, prev_event=4304412722, used_mouse_menu=0x22a327,
> end_time=end_time@entry=0x0) at
> /usr/src/debug/emacs-24.3-4/src/keyboard.c:2669
> #28 0x00000001004926a3 in read_key_sequence
> (keybuf=keybuf@entry=0x22a470, prompt=<optimized out>,
> 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-4/src/keyboard.c:9231
> #29 0x000000010049495e in command_loop_1 () at
> /usr/src/debug/emacs-24.3-4/src/keyboard.c:1459
> #30 0x00000001004f5c2e in internal_condition_case
> (bfun=bfun@entry=0x100494740 <command_loop_1>, handlers=4304470642,
> hfun=hfun@entry=0x10048ae40 <cmd_error>) at
> /usr/src/debug/emacs-24.3-4/src/eval.c:1289
> #31 0x000000010048630a in command_loop_2
> (ignore=ignore@entry=4304412722) at
> /usr/src/debug/emacs-24.3-4/src/keyboard.c:1168
> #32 0x00000001004f5aef in internal_catch (tag=<optimized out>,
> func=func@entry=0x1004862e0 <command_loop_2>, arg=4304412722) at
> /usr/src/debug/emacs-24.3-4/src/eval.c:1060
> #33 0x000000010048a914 in command_loop () at
> /usr/src/debug/emacs-24.3-4/src/keyboard.c:1147
> #34 recursive_edit_1 () at /usr/src/debug/emacs-24.3-4/src/keyboard.c:779
> #35 0x000000010048ac47 in Frecursive_edit () at
> /usr/src/debug/emacs-24.3-4/src/keyboard.c:843
> #36 0x000000010055e8ef in main (argc=<optimized out>, argv=<optimized
> out>) at /usr/src/debug/emacs-24.3-4/src/emacs.c:1537
>
>>
>> Thanks,
>> Ryan
>>
>> Breakpoint 2, 0x000000010055d190 in kill ()
>> (gdb) bt
>> #0  0x000000010055d190 in kill ()
>> #1  0x000000010053702e in process_send_signal
>> (process=process@entry=25781889629, signo=signo@entry=2,
>> current_group=<optimized out>, nomsg=nomsg@entry=0) at
>> /usr/src/debug/emacs-24.3-4/src/process.c:5948
>> #2  0x0000000100537198 in Finterrupt_process (process=25781889629,
>> current_group=<optimized out>) at
>> /usr/src/debug/emacs-24.3-4/src/process.c:5966
>> #3  0x00000001004f7761 in Ffuncall (nargs=<optimized out>,
>> args=<optimized out>) at /usr/src/debug/emacs-24.3-4/src/eval.c:2781
>> #4  0x000000010052b5ed in exec_byte_code (bytestr=4294962344,
>> vector=2268896, maxdepth=2, args_template=4303595040,
>> nargs=4304157760, args=0x100902032 <bss_sbrk_buffer+250194>)
>>     at /usr/src/debug/emacs-24.3-4/src/bytecode.c:900
>> #5  0x00000001004f7293 in funcall_lambda (fun=25778101277,
>> nargs=nargs@entry=0, arg_vector=arg_vector@entry=0x22a188) at
>> /usr/src/debug/emacs-24.3-4/src/eval.c:3010
>> #6  0x00000001004f75cb in Ffuncall (nargs=nargs@entry=1,
>> args=args@entry=0x22a180) at /usr/src/debug/emacs-24.3-4/src/eval.c:2839
>> #7  0x00000001004f8bef in apply1 (fn=25778613730, fn@entry=4304161216,
>> arg=arg@entry=4304412722) at /usr/src/debug/emacs-24.3-4/src/eval.c:2539
>> #8  0x00000001004f3567 in Fcall_interactively (function=4304161216,
>> record_flag=4304412722, keys=4299711881) at
>> /usr/src/debug/emacs-24.3-4/src/callint.c:377
>> #9  0x00000001004f7752 in Ffuncall (nargs=nargs@entry=4,
>> args=args@entry=0x22a3b0) at /usr/src/debug/emacs-24.3-4/src/eval.c:2785
>> #10 0x00000001004f91b7 in call3 (fn=<optimized out>, arg1=<optimized
>> out>, arg2=<optimized out>, arg3=<optimized out>) at
>> /usr/src/debug/emacs-24.3-4/src/eval.c:2603
>> #11 0x00000001004883cd in Fcommand_execute (cmd=<optimized out>,
>> record_flag=<optimized out>, keys=<optimized out>, special=<optimized
>> out>) at /usr/src/debug/emacs-24.3-4/src/keyboard.c:10241
>> #12 0x0000000100494ae8 in command_loop_1 () at
>> /usr/src/debug/emacs-24.3-4/src/keyboard.c:1587
>> #13 0x00000001004f5c2e in internal_condition_case
>> (bfun=bfun@entry=0x100494740 <command_loop_1>, handlers=4304470642,
>> hfun=hfun@entry=0x10048ae40 <cmd_error>) at
>> /usr/src/debug/emacs-24.3-4/src/eval.c:1289
>> #14 0x000000010048630a in command_loop_2
>> (ignore=ignore@entry=4304412722) at
>> /usr/src/debug/emacs-24.3-4/src/keyboard.c:1168
>> #15 0x00000001004f5aef in internal_catch (tag=<optimized out>,
>> func=func@entry=0x1004862e0 <command_loop_2>, arg=4304412722) at
>> /usr/src/debug/emacs-24.3-4/src/eval.c:1060
>> #16 0x000000010048a914 in command_loop () at
>> /usr/src/debug/emacs-24.3-4/src/keyboard.c:1147
>> #17 recursive_edit_1 () at /usr/src/debug/emacs-24.3-4/src/keyboard.c:779
>> #18 0x000000010048ac47 in Frecursive_edit () at
>> /usr/src/debug/emacs-24.3-4/src/keyboard.c:843
>> #19 0x000000010055e8ef in main (argc=<optimized out>, argv=<optimized
>> out>) at /usr/src/debug/emacs-24.3-4/src/emacs.c:1537



--
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: 64-bit emacs crashes a lot

[Eli Zaretskii]

> Date: Thu, 15 Aug 2013 12:58:02 -0400
> From: Ken Brown <kbrown@cornell.edu>
> CC: Eli Zaretskii <eliz@gnu.org>
> 
> Eli is the expert on bidi.c (he wrote it).  He can probably tell you 
> whether you've really bumped into an emacs bug here.

There's nothing wrong with bidi.c here, it just aborts because it is
handed an invalid character codepoint.  It would have been useful to
see the value of that character.

Anyway, I generally agree that this is probably some memory
corruption, as I'm guessing that the text in the window was all ASCII
in this case, so any character codepoint beyond 127 is not to be
expected.

--
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: 64-bit emacs crashes a lot

[Ryan Johnson]

On 15/08/2013 1:10 PM, Eli Zaretskii wrote:
>> Date: Thu, 15 Aug 2013 12:58:02 -0400
>> From: Ken Brown <kbrown@cornell.edu>
>> CC: Eli Zaretskii <eliz@gnu.org>
>>
>> Eli is the expert on bidi.c (he wrote it).  He can probably tell you
>> whether you've really bumped into an emacs bug here.
> There's nothing wrong with bidi.c here, it just aborts because it is
> handed an invalid character codepoint.  It would have been useful to
> see the value of that character.
I guess I would just consider crashing to be overkill for a bad byte on 
the input stream... and in any case, if 5-byte UTF-8 is illegal, and 
worth dying for, wouldn't it make sense to die right away rather than 
processing it so something else can croak down the road? However...

> Anyway, I generally agree that this is probably some memory
> corruption, as I'm guessing that the text in the window was all ASCII
> in this case, so any character codepoint beyond 127 is not to be
> expected.
I set a breakpoint there, since I thought it was guaranteed to lead to a 
crash if it ever ran, but it turns out that's not true. Invoking M-x 
compile triggers the breakpoint twice in a row with the following 
(valid!) 5-byte UTF-8:

111110XX 10XXXXXX 10XXXXXX 10XXXXXX 10XXXXXX
11111000 10001111 10111111 10111101 10111111

The value is always the same, and corresponds to the code point 
U+3FFF7F, FWIW. The backtrace seems to involve loading a file (maybe the 
.elc contains 'compile or 'compilation-mode?), and the breakpoint does 
not recur in subsequent compilations, presumably because they don't 
re-load the file. Emacs continues normally from there, because the 
leading bits are zero and the resulting code point doesn't pass the 
0x3FFFFF limit.

At this point I'm pretty confident it's memory corruption of some kind. 
Consider the following semi-STC:
1. Invoke: emacs-nox -Q; echo -e "att $(jobs -p)\nc" > /dev/clipboard; fg
2. ^Z
3. (switch to window running gdb and hit [shift]+[insert] to paste from 
clipboard)
5. (switch to window running emacs): M-x compile C-a C-k ls [ret]
6. C-x o (to switch to the compilation output window)
7. Hit 'g' to keep repeating the "compilation" until gdb picks up a crash.

For its part, gdb needs the following to do its job effectively:
1. handle {SIGINT,SIGTSTP,SIGCONT} pass nostop noprint
2. b abort
3. b kill
4. b raise
5. b character.c:189 -if p[1] & 0x30 (catches the bad UTF-8 sequence as 
it happens)
6. b regex.c:6256 (catches a failure/abort inside re_match_2_internal)
7. b data.c:854 (catches an abort inside do_symval_forwarding)
8. b bidi.c:107 (catches the bidi abort even when the character.c 
breakpoint doesn't trigger)

It may take anywhere from five to fifty compilations to trigger the 
crash; I repeated the process about 20 times (see below). There are 
definitely some patterns, but in general it's all over the map. The only 
thing in common is that all crashes have hit after emacs echoes the 
command but before any of the command's output arrives. Oddly, the one 
time the bidi.c crash returned, the breakpoint in character.c had not 
triggered, so the culprit must have been elsewhere. Can anybody else 
repro any of this?

I don't have any installed software fro the BLODA list, and antivirus 
scans come up clean. I've posted the list of loaded dlls that gdb knew 
about below, along with a taste of the crashes that were occurring.

Thoughts?
Ryan

/cygdrive/c/Windows/system32/apphelp.dll
/cygdrive/c/Windows/system32/DNSAPI.dll
/cygdrive/c/Windows/System32/fwpuclnt.dll
/cygdrive/c/Windows/system32/GDI32.dll
/cygdrive/c/Windows/system32/IMM32.DLL
/cygdrive/c/Windows/system32/IPHLPAPI.DLL
/cygdrive/c/Windows/system32/kernel32.dll
/cygdrive/c/Windows/system32/KERNELBASE.dll
/cygdrive/c/Windows/system32/LPK.dll
/cygdrive/c/Windows/system32/MSCTF.dll
/cygdrive/c/Windows/system32/msvcrt.dll
/cygdrive/c/Windows/System32/mswsock.dll
/cygdrive/c/Windows/system32/napinsp.dll
/cygdrive/c/Windows/system32/NLAapi.dll
/cygdrive/c/Windows/system32/NSI.dll
/cygdrive/c/Windows/SYSTEM32/ntdll.dll
/cygdrive/c/Windows/system32/pnrpnsp.dll
/cygdrive/c/Windows/system32/rasadhlp.dll
/cygdrive/c/Windows/system32/RPCRT4.dll
/cygdrive/c/Windows/SYSTEM32/sechost.dll
/cygdrive/c/Windows/system32/user32.dll
/cygdrive/c/Windows/system32/USP10.dll
/cygdrive/c/Windows/system32/WINNSI.DLL
/cygdrive/c/Windows/System32/winrnr.dll
/cygdrive/c/Windows/system32/ws2_32.dll
/cygdrive/c/Windows/System32/wship6.dll
/cygdrive/c/Windows/System32/wshtcpip.dll
/usr/bin/cygdbus-1-3.dll
/usr/bin/cygffi-6.dll
/usr/bin/cyggmp-10.dll
/usr/bin/cyggnutls-28.dll
/usr/bin/cyghogweed-2.dll
/usr/bin/cygiconv-2.dll
/usr/bin/cygintl-8.dll
/usr/bin/cyglzma-5.dll
/usr/bin/cygncursesw-10.dll
/usr/bin/cygnettle-4.dll
/usr/bin/cygp11-kit-0.dll
/usr/bin/cygtasn1-6.dll
/usr/bin/cygwin1.dll
/usr/bin/cygxml2-2.dll
/usr/bin/cygz.dll

Breakpoint 6, re_match_2_internal (bufp=bufp@entry=0x1008bab40 
<searchbufs+1472>, string1=0x100000000 <Address 0x100000000 out of bounds>,
     string1@entry=0x6fffff00028 "-*- mode: compilation; 
default-directory: \"~/projects/shore-compiler/\" -*-\nCompilation 
started at Thu Aug 15 16:12:01\n\nls\n#bug-last.i#\t\t schema.py\t\t  
sql_schema.h\n#sql_shore.cpp.rej#\t schema_impl.cpp\t"..., size1=0, 
size1@entry=379, string2=0x2214bc "\001", string2@entry=0x6fffff00973 
"", size2=370, size2@entry=0, pos=<optimized out>, pos@entry=138, 
regs=<optimized out>,
     regs@entry=0x1008ba560 <search_regs>, stop=<optimized out>, 
stop@entry=370) at /usr/src/debug/emacs-24.3-4/src/regex.c:6256
6256                  abort ();
(9x)

Breakpoint 7, do_symval_forwarding (valcontents=0x1008536a0 
<o_fwd.20653>) at /usr/src/debug/emacs-24.3-4/src/data.c:854
854         default: emacs_abort ();
(4x)

#5  0x00000001004a0363 in emacs_abort () at 
/usr/src/debug/emacs-24.3-4/src/sysdep.c:2152
#6  0x00000001004117af in produce_special_glyphs (it=it@entry=0x225380, 
what=IT_COMPOSITION, what@entry=IT_CONTINUATION) at 
/usr/src/debug/emacs-24.3-4/src/xdisp.c:24365
#7  0x000000010041b637 in init_iterator (it=it@entry=0x225380, 
w=w@entry=0x100d37ca0 <bss_sbrk_buffer+4664768>, 
charpos=charpos@entry=1, bytepos=bytepos@entry=1, row=0x6002d4000,
(2x)

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 3120.0x360]
allocate_string_data (s=s@entry=0x60024e9e0, nchars=nchars@entry=57, 
nbytes=nbytes@entry=57) at /usr/src/debug/emacs-24.3-4/src/alloc.c:1743
1743          SDATA_NBYTES (old_data) = old_nbytes;
(gdb) bt
#0  allocate_string_data (s=s@entry=0x60024e9e0, nchars=nchars@entry=57, 
nbytes=nbytes@entry=57) at /usr/src/debug/emacs-24.3-4/src/alloc.c:1743
#1  0x00000001004dd3d6 in make_uninit_multibyte_string (nchars=57, 
nbytes=57) at /usr/src/debug/emacs-24.3-4/src/alloc.c:2186
#2  0x00000001004dd62c in make_uninit_string (length=<optimized out>) at 
/usr/src/debug/emacs-24.3-4/src/alloc.c:2164
(2x)

#0  0x000000010055d520 in abort ()
#1  0x00000001004d49c5 in re_iswctype (ch=ch@entry=24, 
cc=cc@entry=RECC_SPACE) at /usr/src/debug/emacs-24.3-4/src/regex.c:2087
(1x)

#6  0x000000010046d365 in bidi_get_type (ch=<optimized out>, 
override=override@entry=NEUTRAL_DIR) at 
/usr/src/debug/emacs-24.3-4/src/bidi.c:107
(1x)

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 2500.0x9dc]
0x000000010054da4f in record_backtrace (log=0x10090202d 
<bss_sbrk_buffer+250189>, count=count@entry=80) at 
/usr/src/debug/emacs-24.3-4/src/profiler.c:149
149       backtrace = HASH_KEY (log, index);
(gdb) bt
#0  0x000000010054da4f in record_backtrace (log=0x10090202d 
<bss_sbrk_buffer+250189>, count=count@entry=80) at 
/usr/src/debug/emacs-24.3-4/src/profiler.c:149
#1  0x000000010054de04 in malloc_probe (size=size@entry=80) at 
/usr/src/debug/emacs-24.3-4/src/profiler.c:516
#2  0x00000001004dca9b in xmalloc (size=size@entry=80) at 
/usr/src/debug/emacs-24.3-4/src/alloc.c:673
(1x)

Program received signal SIGSEGV, Segmentation fault.
___chkstk_ms () at 
/usr/src/debug/gcc-4.8.1-1/libgcc/config/i386/cygwin.S:146
146     /usr/src/debug/gcc-4.8.1-1/libgcc/config/i386/cygwin.S: No such 
file or directory.
(gdb) bt
#0  ___chkstk_ms () at 
/usr/src/debug/gcc-4.8.1-1/libgcc/config/i386/cygwin.S:146
#1  0x00000001004cefdd in re_match_2_internal (bufp=0x0, 
bufp@entry=0x1008bbef0 <searchbufs+6512>, string1=0x100000000 <Address 
0x100000000 out of bounds>,
     string1@entry=0x6fffff00028 "-*- mode: compilation; 
default-directory: \"~/projects/shore-compiler/\" -*-\nCompilation 
started at Thu Aug 15 16:00:09\n\nls\n#bug-last.i#\t\t schema.py\t\t  
sql_schema.h\n#sql_shore.cpp.rej#\t schema_impl.cpp\t"..., 
size1=size1@entry=379, string2=string2@entry=0x6fffff00a01 "", 
size2=<optimized out>, size2@entry=0, pos=pos@entry=178, 
regs=regs@entry=0x1008ba560 <search_regs>,
     stop=stop@entry=370) at /usr/src/debug/emacs-24.3-4/src/regex.c:5055
#2  0x00000001004d5000 in re_search_2 (bufp=bufp@entry=0x1004ccf66 
<search_command+310>,
     str1=0x6fffff00028 "-*- mode: compilation; default-directory: 
\"~/projects/shore-compiler/\" -*-\nCompilation started at Thu Aug 15 
16:00:09\n\nls\n#bug-last.i#\t\t schema.py\t\t 
sql_schema.h\n#sql_shore.cpp.rej#\t schema_impl.cpp\t"..., 
str1@entry=0x2e903e <Address 0x2e903e out of bounds>, 
size1=size1@entry=4304161216, str2=0x6fffff00a01 "", 
str2@entry=0x100902032 <bss_sbrk_buffer+250194> "", size2=0,
     size2@entry=4304161216, startpos=178, startpos@entry=122, 
range=192, regs=0x1008ba560 <search_regs>, stop=370) at 
/usr/src/debug/emacs-24.3-4/src/regex.c:4458
(1x)


--
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: 64-bit emacs crashes a lot

[Ken Brown]

On 8/15/2013 4:55 PM, Ryan Johnson wrote:
> Program received signal SIGSEGV, Segmentation fault.
> ___chkstk_ms () at
> /usr/src/debug/gcc-4.8.1-1/libgcc/config/i386/cygwin.S:146

You're not using the latest gcc, which is 4.8.1-3.  Any chance that 
that's your problem?

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: 64-bit emacs crashes a lot

[Ryan Johnson]

On 15/08/2013 5:14 PM, Ken Brown wrote:
> On 8/15/2013 4:55 PM, Ryan Johnson wrote:
>> Program received signal SIGSEGV, Segmentation fault.
>> ___chkstk_ms () at
>> /usr/src/debug/gcc-4.8.1-1/libgcc/config/i386/cygwin.S:146
>
> You're not using the latest gcc, which is 4.8.1-3.  Any chance that 
> that's your problem?
Heh. I actually do have the latest gcc, but somehow the upgrade didn't 
pick up the debug package (which showed as not installed in setup.exe). 
I have manually upgraded it now.

BTW, how do you compile emacs from the sources given? I tried untarring 
and patching, but I get the message:
> configure: error: Emacs hasn't been ported to `x86_64-unknown-cygwin' 
> systems.
> Check `etc/MACHINES' for recognized configuration names.

My goal is to get a build compiled with "-g -0g -fsanitize=address" and 
see what that turns up...

Ryan


--
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: 64-bit emacs crashes a lot

[Ken Brown]

On 8/15/2013 5:24 PM, Ryan Johnson wrote:
> On 15/08/2013 5:14 PM, Ken Brown wrote:
>> On 8/15/2013 4:55 PM, Ryan Johnson wrote:
>>> Program received signal SIGSEGV, Segmentation fault.
>>> ___chkstk_ms () at
>>> /usr/src/debug/gcc-4.8.1-1/libgcc/config/i386/cygwin.S:146
>>
>> You're not using the latest gcc, which is 4.8.1-3.  Any chance that
>> that's your problem?
> Heh. I actually do have the latest gcc, but somehow the upgrade didn't
> pick up the debug package (which showed as not installed in setup.exe).
> I have manually upgraded it now.

OK.  But doesn't the above show that the crash is occurring in gcc, not 
emacs?

> BTW, how do you compile emacs from the sources given? I tried untarring
> and patching, but I get the message:
>> configure: error: Emacs hasn't been ported to `x86_64-unknown-cygwin'
>> systems.
>> Check `etc/MACHINES' for recognized configuration names.

One of the patches changes configure.ac, so you have to run autoreconf 
after applying 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

Re: 64-bit emacs crashes a lot

[Ken Brown]

On 8/15/2013 5:58 PM, Ken Brown wrote:
> On 8/15/2013 5:24 PM, Ryan Johnson wrote:
>> On 15/08/2013 5:14 PM, Ken Brown wrote:
>>> On 8/15/2013 4:55 PM, Ryan Johnson wrote:
>>>> Program received signal SIGSEGV, Segmentation fault.
>>>> ___chkstk_ms () at
>>>> /usr/src/debug/gcc-4.8.1-1/libgcc/config/i386/cygwin.S:146
>>>
>>> You're not using the latest gcc, which is 4.8.1-3.  Any chance that
>>> that's your problem?
>> Heh. I actually do have the latest gcc, but somehow the upgrade didn't
>> pick up the debug package (which showed as not installed in setup.exe).
>> I have manually upgraded it now.
>
> OK.  But doesn't the above show that the crash is occurring in gcc, not
> emacs?
>
>> BTW, how do you compile emacs from the sources given? I tried untarring
>> and patching, but I get the message:
>>> configure: error: Emacs hasn't been ported to `x86_64-unknown-cygwin'
>>> systems.
>>> Check `etc/MACHINES' for recognized configuration names.
>
> One of the patches changes configure.ac, so you have to run autoreconf
> after applying it.

Or it might be 'autoreconf -I m4'.

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: 64-bit emacs crashes a lot

[Ryan Johnson]

On 15/08/2013 5:58 PM, Ken Brown wrote:
> On 8/15/2013 5:24 PM, Ryan Johnson wrote:
>> On 15/08/2013 5:14 PM, Ken Brown wrote:
>>> On 8/15/2013 4:55 PM, Ryan Johnson wrote:
>>>> Program received signal SIGSEGV, Segmentation fault.
>>>> ___chkstk_ms () at
>>>> /usr/src/debug/gcc-4.8.1-1/libgcc/config/i386/cygwin.S:146
>>>
>>> You're not using the latest gcc, which is 4.8.1-3.  Any chance that
>>> that's your problem?
>> Heh. I actually do have the latest gcc, but somehow the upgrade didn't
>> pick up the debug package (which showed as not installed in setup.exe).
>> I have manually upgraded it now.
>
> OK.  But doesn't the above show that the crash is occurring in gcc, 
> not emacs?
It's trying to grow the stack for alloca and something went wrong, I 
believe (though I didn't see where re_match_2_internal calls alloca)

>
>> BTW, how do you compile emacs from the sources given? I tried untarring
>> and patching, but I get the message:
>>> configure: error: Emacs hasn't been ported to `x86_64-unknown-cygwin'
>>> systems.
>>> Check `etc/MACHINES' for recognized configuration names.
>
> One of the patches changes configure.ac, so you have to run autoreconf 
> after applying it.
Hmm...

$ autoreconf -if
lib/gnulib.mk:42: GL_GENERATE_ALLOCA_H does not appear in AM_CONDITIONAL
lib/Makefile.am:10:   `lib/gnulib.mk' included from here
lib/gnulib.mk:121: gl_GNULIB_ENABLED_dosname does not appear in 
AM_CONDITIONAL
lib/Makefile.am:10:   `lib/gnulib.mk' included from here
lib/gnulib.mk:159: GL_GENERATE_EXECINFO_H does not appear in AM_CONDITIONAL
lib/Makefile.am:10:   `lib/gnulib.mk' included from here
lib/gnulib.mk:224: gl_GNULIB_ENABLED_be453cec5eecf5731a274f2de7f2db36 
does not appear in AM_CONDITIONAL
lib/Makefile.am:10:   `lib/gnulib.mk' included from here
lib/gnulib.mk:323: gl_GNULIB_ENABLED_pathmax does not appear in 
AM_CONDITIONAL
lib/Makefile.am:10:   `lib/gnulib.mk' included from here
lib/gnulib.mk:482: gl_GNULIB_ENABLED_stat does not appear in AM_CONDITIONAL
lib/Makefile.am:10:   `lib/gnulib.mk' included from here
lib/gnulib.mk:505: GL_GENERATE_STDALIGN_H does not appear in AM_CONDITIONAL
lib/Makefile.am:10:   `lib/gnulib.mk' included from here
lib/gnulib.mk:528: GL_GENERATE_STDARG_H does not appear in AM_CONDITIONAL
lib/Makefile.am:10:   `lib/gnulib.mk' included from here
lib/gnulib.mk:556: GL_GENERATE_STDBOOL_H does not appear in AM_CONDITIONAL
lib/Makefile.am:10:   `lib/gnulib.mk' included from here
lib/gnulib.mk:579: GL_GENERATE_STDDEF_H does not appear in AM_CONDITIONAL
lib/Makefile.am:10:   `lib/gnulib.mk' included from here
lib/gnulib.mk:609: GL_GENERATE_STDINT_H does not appear in AM_CONDITIONAL
lib/Makefile.am:10:   `lib/gnulib.mk' included from here
lib/gnulib.mk:901: gl_GNULIB_ENABLED_strtoll does not appear in 
AM_CONDITIONAL
lib/Makefile.am:10:   `lib/gnulib.mk' included from here
lib/gnulib.mk:912: gl_GNULIB_ENABLED_strtoull does not appear in 
AM_CONDITIONAL
lib/Makefile.am:10:   `lib/gnulib.mk' included from here
lib/gnulib.mk:1308: gl_GNULIB_ENABLED_verify does not appear in 
AM_CONDITIONAL
lib/Makefile.am:10:   `lib/gnulib.mk' included from here
lib/Makefile.am:5: library used but `RANLIB' is undefined
lib/Makefile.am:5:   The usual way to define `RANLIB' is to add 
`AC_PROG_RANLIB'
lib/Makefile.am:5:   to `configure.ac' and run `autoconf' again.
autoreconf-2.69: automake failed with exit status: 1

Did I miss something?

Ryan


--
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: 64-bit emacs crashes a lot

[Ryan Johnson]

On 15/08/2013 6:02 PM, Ken Brown wrote:
> On 8/15/2013 5:58 PM, Ken Brown wrote:
>> On 8/15/2013 5:24 PM, Ryan Johnson wrote:
>>> On 15/08/2013 5:14 PM, Ken Brown wrote:
>>>> On 8/15/2013 4:55 PM, Ryan Johnson wrote:
>>>>> Program received signal SIGSEGV, Segmentation fault.
>>>>> ___chkstk_ms () at
>>>>> /usr/src/debug/gcc-4.8.1-1/libgcc/config/i386/cygwin.S:146
>>>>
>>>> You're not using the latest gcc, which is 4.8.1-3.  Any chance that
>>>> that's your problem?
>>> Heh. I actually do have the latest gcc, but somehow the upgrade didn't
>>> pick up the debug package (which showed as not installed in setup.exe).
>>> I have manually upgraded it now.
>>
>> OK.  But doesn't the above show that the crash is occurring in gcc, not
>> emacs?
>>
>>> BTW, how do you compile emacs from the sources given? I tried untarring
>>> and patching, but I get the message:
>>>> configure: error: Emacs hasn't been ported to `x86_64-unknown-cygwin'
>>>> systems.
>>>> Check `etc/MACHINES' for recognized configuration names.
>>
>> One of the patches changes configure.ac, so you have to run autoreconf
>> after applying it.
>
> Or it might be 'autoreconf -I m4'.

Something is still wrong:

$ cd /scratch
$ tar xaf /usr/src/emacs-24.3.tar.xz
$ patch -p1 </usr/src/emacs-24.3-5.cygwin.patch
patching file emacs-24.3/CYGWIN-PATCHES/emacs-X11.postinstall
patching file emacs-24.3/CYGWIN-PATCHES/emacs-X11.preremove
patching file emacs-24.3/CYGWIN-PATCHES/emacs-w32.postinstall
patching file emacs-24.3/CYGWIN-PATCHES/emacs-w32.preremove
patching file emacs-24.3/CYGWIN-PATCHES/emacs.postinstall
patching file emacs-24.3/CYGWIN-PATCHES/emacs.preremove
$ cd emacs-24.3
$ autoreconf -I m4
$ ./configure CFLAGS='-g -0g -fsanitize=address' 
LDFLAGS='-fsanitize=address' --without-all
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /usr/bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking build system type... x86_64-unknown-cygwin
checking host system type... x86_64-unknown-cygwin
configure: error: Emacs hasn't been ported to `x86_64-unknown-cygwin' 
systems.
Check `etc/MACHINES' for recognized configuration names.

In particular, it doesn't look like the patch actually patches any emacs 
files at all... do I need to pull all past versions of the source 
package as well or something?

Ryan


--
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: 64-bit emacs crashes a lot

[Ken Brown]

On 8/15/2013 6:39 PM, Ryan Johnson wrote:
> On 15/08/2013 5:58 PM, Ken Brown wrote:
>> On 8/15/2013 5:24 PM, Ryan Johnson wrote:
>>> On 15/08/2013 5:14 PM, Ken Brown wrote:
>>>> On 8/15/2013 4:55 PM, Ryan Johnson wrote:
>>>>> Program received signal SIGSEGV, Segmentation fault.
>>>>> ___chkstk_ms () at
>>>>> /usr/src/debug/gcc-4.8.1-1/libgcc/config/i386/cygwin.S:146
>>>>
>>>> You're not using the latest gcc, which is 4.8.1-3.  Any chance that
>>>> that's your problem?
>>> Heh. I actually do have the latest gcc, but somehow the upgrade didn't
>>> pick up the debug package (which showed as not installed in setup.exe).
>>> I have manually upgraded it now.
>>
>> OK.  But doesn't the above show that the crash is occurring in gcc,
>> not emacs?
> It's trying to grow the stack for alloca and something went wrong, I
> believe (though I didn't see where re_match_2_internal calls alloca)
>
>>
>>> BTW, how do you compile emacs from the sources given? I tried untarring
>>> and patching, but I get the message:
>>>> configure: error: Emacs hasn't been ported to `x86_64-unknown-cygwin'
>>>> systems.
>>>> Check `etc/MACHINES' for recognized configuration names.
>>
>> One of the patches changes configure.ac, so you have to run autoreconf
>> after applying it.
> Hmm...
>
> $ autoreconf -if
> lib/gnulib.mk:42: GL_GENERATE_ALLOCA_H does not appear in AM_CONDITIONAL
> lib/Makefile.am:10:   `lib/gnulib.mk' included from here
> lib/gnulib.mk:121: gl_GNULIB_ENABLED_dosname does not appear in
> AM_CONDITIONAL
> lib/Makefile.am:10:   `lib/gnulib.mk' included from here
> lib/gnulib.mk:159: GL_GENERATE_EXECINFO_H does not appear in AM_CONDITIONAL
> lib/Makefile.am:10:   `lib/gnulib.mk' included from here
> lib/gnulib.mk:224: gl_GNULIB_ENABLED_be453cec5eecf5731a274f2de7f2db36
> does not appear in AM_CONDITIONAL
> lib/Makefile.am:10:   `lib/gnulib.mk' included from here
> lib/gnulib.mk:323: gl_GNULIB_ENABLED_pathmax does not appear in
> AM_CONDITIONAL
> lib/Makefile.am:10:   `lib/gnulib.mk' included from here
> lib/gnulib.mk:482: gl_GNULIB_ENABLED_stat does not appear in AM_CONDITIONAL
> lib/Makefile.am:10:   `lib/gnulib.mk' included from here
> lib/gnulib.mk:505: GL_GENERATE_STDALIGN_H does not appear in AM_CONDITIONAL
> lib/Makefile.am:10:   `lib/gnulib.mk' included from here
> lib/gnulib.mk:528: GL_GENERATE_STDARG_H does not appear in AM_CONDITIONAL
> lib/Makefile.am:10:   `lib/gnulib.mk' included from here
> lib/gnulib.mk:556: GL_GENERATE_STDBOOL_H does not appear in AM_CONDITIONAL
> lib/Makefile.am:10:   `lib/gnulib.mk' included from here
> lib/gnulib.mk:579: GL_GENERATE_STDDEF_H does not appear in AM_CONDITIONAL
> lib/Makefile.am:10:   `lib/gnulib.mk' included from here
> lib/gnulib.mk:609: GL_GENERATE_STDINT_H does not appear in AM_CONDITIONAL
> lib/Makefile.am:10:   `lib/gnulib.mk' included from here
> lib/gnulib.mk:901: gl_GNULIB_ENABLED_strtoll does not appear in
> AM_CONDITIONAL
> lib/Makefile.am:10:   `lib/gnulib.mk' included from here
> lib/gnulib.mk:912: gl_GNULIB_ENABLED_strtoull does not appear in
> AM_CONDITIONAL
> lib/Makefile.am:10:   `lib/gnulib.mk' included from here
> lib/gnulib.mk:1308: gl_GNULIB_ENABLED_verify does not appear in
> AM_CONDITIONAL
> lib/Makefile.am:10:   `lib/gnulib.mk' included from here
> lib/Makefile.am:5: library used but `RANLIB' is undefined
> lib/Makefile.am:5:   The usual way to define `RANLIB' is to add
> `AC_PROG_RANLIB'
> lib/Makefile.am:5:   to `configure.ac' and run `autoconf' again.
> autoreconf-2.69: automake failed with exit status: 1
>
> Did I miss something?

http://cygwin.com/ml/cygwin/2013-08/msg00250.html

--
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: 64-bit emacs crashes a lot

[Ken Brown]

On 8/15/2013 6:48 PM, Ryan Johnson wrote:
> On 15/08/2013 6:02 PM, Ken Brown wrote:
>> On 8/15/2013 5:58 PM, Ken Brown wrote:
>>> On 8/15/2013 5:24 PM, Ryan Johnson wrote:
>>>> On 15/08/2013 5:14 PM, Ken Brown wrote:
>>>>> On 8/15/2013 4:55 PM, Ryan Johnson wrote:
>>>>>> Program received signal SIGSEGV, Segmentation fault.
>>>>>> ___chkstk_ms () at
>>>>>> /usr/src/debug/gcc-4.8.1-1/libgcc/config/i386/cygwin.S:146
>>>>>
>>>>> You're not using the latest gcc, which is 4.8.1-3.  Any chance that
>>>>> that's your problem?
>>>> Heh. I actually do have the latest gcc, but somehow the upgrade didn't
>>>> pick up the debug package (which showed as not installed in setup.exe).
>>>> I have manually upgraded it now.
>>>
>>> OK.  But doesn't the above show that the crash is occurring in gcc, not
>>> emacs?
>>>
>>>> BTW, how do you compile emacs from the sources given? I tried untarring
>>>> and patching, but I get the message:
>>>>> configure: error: Emacs hasn't been ported to `x86_64-unknown-cygwin'
>>>>> systems.
>>>>> Check `etc/MACHINES' for recognized configuration names.
>>>
>>> One of the patches changes configure.ac, so you have to run autoreconf
>>> after applying it.
>>
>> Or it might be 'autoreconf -I m4'.
>
> Something is still wrong:
>
> $ cd /scratch
> $ tar xaf /usr/src/emacs-24.3.tar.xz
> $ patch -p1 </usr/src/emacs-24.3-5.cygwin.patch
> patching file emacs-24.3/CYGWIN-PATCHES/emacs-X11.postinstall
> patching file emacs-24.3/CYGWIN-PATCHES/emacs-X11.preremove
> patching file emacs-24.3/CYGWIN-PATCHES/emacs-w32.postinstall
> patching file emacs-24.3/CYGWIN-PATCHES/emacs-w32.preremove
> patching file emacs-24.3/CYGWIN-PATCHES/emacs.postinstall
> patching file emacs-24.3/CYGWIN-PATCHES/emacs.preremove
> $ cd emacs-24.3
> $ autoreconf -I m4
> $ ./configure CFLAGS='-g -0g -fsanitize=address'
> LDFLAGS='-fsanitize=address' --without-all
> checking for a BSD-compatible install... /usr/bin/install -c
> checking whether build environment is sane... yes
> checking for a thread-safe mkdir -p... /usr/bin/mkdir -p
> checking for gawk... gawk
> checking whether make sets $(MAKE)... yes
> checking build system type... x86_64-unknown-cygwin
> checking host system type... x86_64-unknown-cygwin
> configure: error: Emacs hasn't been ported to `x86_64-unknown-cygwin'
> systems.
> Check `etc/MACHINES' for recognized configuration names.
>
> In particular, it doesn't look like the patch actually patches any emacs
> files at all... do I need to pull all past versions of the source
> package as well or something?

The source package for emacs-24.3-5 contains lots of patches that you 
didn't apply:

	nox_mouse.patch
	w32_encoding.patch
	configure.ac.patch
	syms_of_cygw32.patch
	image_background.patch
	w32term.w32_init.patch
	unexcw.patch
	memory_warnings.patch
	24.3-4_nt_icon.patch
	nonbootstrap_static_heap.patch
	24.3_memalign.patch

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: 64-bit emacs crashes a lot

[Ryan Johnson]

On 15/08/2013 6:48 PM, Ryan Johnson wrote:
> On 15/08/2013 6:02 PM, Ken Brown wrote:
>> On 8/15/2013 5:58 PM, Ken Brown wrote:
>>> On 8/15/2013 5:24 PM, Ryan Johnson wrote:
>>>> On 15/08/2013 5:14 PM, Ken Brown wrote:
>>>>> On 8/15/2013 4:55 PM, Ryan Johnson wrote:
>>>>>> Program received signal SIGSEGV, Segmentation fault.
>>>>>> ___chkstk_ms () at
>>>>>> /usr/src/debug/gcc-4.8.1-1/libgcc/config/i386/cygwin.S:146
>>>>>
>>>>> You're not using the latest gcc, which is 4.8.1-3.  Any chance that
>>>>> that's your problem?
>>>> Heh. I actually do have the latest gcc, but somehow the upgrade didn't
>>>> pick up the debug package (which showed as not installed in 
>>>> setup.exe).
>>>> I have manually upgraded it now.
>>>
>>> OK.  But doesn't the above show that the crash is occurring in gcc, not
>>> emacs?
>>>
>>>> BTW, how do you compile emacs from the sources given? I tried 
>>>> untarring
>>>> and patching, but I get the message:
>>>>> configure: error: Emacs hasn't been ported to `x86_64-unknown-cygwin'
>>>>> systems.
>>>>> Check `etc/MACHINES' for recognized configuration names.
>>>
>>> One of the patches changes configure.ac, so you have to run autoreconf
>>> after applying it.
>>
>> Or it might be 'autoreconf -I m4'.
>
> Something is still wrong:
>
> $ cd /scratch
> $ tar xaf /usr/src/emacs-24.3.tar.xz
> $ patch -p1 </usr/src/emacs-24.3-5.cygwin.patch
> patching file emacs-24.3/CYGWIN-PATCHES/emacs-X11.postinstall
> patching file emacs-24.3/CYGWIN-PATCHES/emacs-X11.preremove
> patching file emacs-24.3/CYGWIN-PATCHES/emacs-w32.postinstall
> patching file emacs-24.3/CYGWIN-PATCHES/emacs-w32.preremove
> patching file emacs-24.3/CYGWIN-PATCHES/emacs.postinstall
> patching file emacs-24.3/CYGWIN-PATCHES/emacs.preremove
Ah, it seems there's a /usr/src/configure.ac.patch that happens to 
belong to emacs...

... but unfortunately it seems that -fsanitize is only supported on 
Linux and Darwin right now, so there's little reason to build emacs 
unless you could use some particular information that a debug build 
provides. Rats.

Ryan


--
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: 64-bit emacs crashes a lot

[Ken Brown]

On 8/15/2013 7:14 PM, Ryan Johnson wrote:
> On 15/08/2013 6:48 PM, Ryan Johnson wrote:
>> On 15/08/2013 6:02 PM, Ken Brown wrote:
>>> On 8/15/2013 5:58 PM, Ken Brown wrote:
>>>> On 8/15/2013 5:24 PM, Ryan Johnson wrote:
>>>>> On 15/08/2013 5:14 PM, Ken Brown wrote:
>>>>>> On 8/15/2013 4:55 PM, Ryan Johnson wrote:
>>>>>>> Program received signal SIGSEGV, Segmentation fault.
>>>>>>> ___chkstk_ms () at
>>>>>>> /usr/src/debug/gcc-4.8.1-1/libgcc/config/i386/cygwin.S:146
>>>>>>
>>>>>> You're not using the latest gcc, which is 4.8.1-3.  Any chance that
>>>>>> that's your problem?
>>>>> Heh. I actually do have the latest gcc, but somehow the upgrade didn't
>>>>> pick up the debug package (which showed as not installed in
>>>>> setup.exe).
>>>>> I have manually upgraded it now.
>>>>
>>>> OK.  But doesn't the above show that the crash is occurring in gcc, not
>>>> emacs?
>>>>
>>>>> BTW, how do you compile emacs from the sources given? I tried
>>>>> untarring
>>>>> and patching, but I get the message:
>>>>>> configure: error: Emacs hasn't been ported to `x86_64-unknown-cygwin'
>>>>>> systems.
>>>>>> Check `etc/MACHINES' for recognized configuration names.
>>>>
>>>> One of the patches changes configure.ac, so you have to run autoreconf
>>>> after applying it.
>>>
>>> Or it might be 'autoreconf -I m4'.
>>
>> Something is still wrong:
>>
>> $ cd /scratch
>> $ tar xaf /usr/src/emacs-24.3.tar.xz
>> $ patch -p1 </usr/src/emacs-24.3-5.cygwin.patch
>> patching file emacs-24.3/CYGWIN-PATCHES/emacs-X11.postinstall
>> patching file emacs-24.3/CYGWIN-PATCHES/emacs-X11.preremove
>> patching file emacs-24.3/CYGWIN-PATCHES/emacs-w32.postinstall
>> patching file emacs-24.3/CYGWIN-PATCHES/emacs-w32.preremove
>> patching file emacs-24.3/CYGWIN-PATCHES/emacs.postinstall
>> patching file emacs-24.3/CYGWIN-PATCHES/emacs.preremove
> Ah, it seems there's a /usr/src/configure.ac.patch that happens to
> belong to emacs...
>
> ... but unfortunately it seems that -fsanitize is only supported on
> Linux and Darwin right now, so there's little reason to build emacs
> unless you could use some particular information that a debug build
> provides. Rats.

But a build without optimization would make your backtraces more useful.

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: 64-bit emacs crashes a lot

[Ryan Johnson]

On 15/08/2013 7:07 PM, Ken Brown wrote:
> On 8/15/2013 6:48 PM, Ryan Johnson wrote:
>> On 15/08/2013 6:02 PM, Ken Brown wrote:
>>> On 8/15/2013 5:58 PM, Ken Brown wrote:
>>>> On 8/15/2013 5:24 PM, Ryan Johnson wrote:
>>>>> On 15/08/2013 5:14 PM, Ken Brown wrote:
>>>>>> On 8/15/2013 4:55 PM, Ryan Johnson wrote:
>>>>>>> Program received signal SIGSEGV, Segmentation fault.
>>>>>>> ___chkstk_ms () at
>>>>>>> /usr/src/debug/gcc-4.8.1-1/libgcc/config/i386/cygwin.S:146
>>>>>>
>>>>>> You're not using the latest gcc, which is 4.8.1-3.  Any chance that
>>>>>> that's your problem?
>>>>> Heh. I actually do have the latest gcc, but somehow the upgrade 
>>>>> didn't
>>>>> pick up the debug package (which showed as not installed in 
>>>>> setup.exe).
>>>>> I have manually upgraded it now.
>>>>
>>>> OK.  But doesn't the above show that the crash is occurring in gcc, 
>>>> not
>>>> emacs?
>>>>
>>>>> BTW, how do you compile emacs from the sources given? I tried 
>>>>> untarring
>>>>> and patching, but I get the message:
>>>>>> configure: error: Emacs hasn't been ported to 
>>>>>> `x86_64-unknown-cygwin'
>>>>>> systems.
>>>>>> Check `etc/MACHINES' for recognized configuration names.
>>>>
>>>> One of the patches changes configure.ac, so you have to run autoreconf
>>>> after applying it.
>>>
>>> Or it might be 'autoreconf -I m4'.
>>
>> Something is still wrong:
>>
>> $ cd /scratch
>> $ tar xaf /usr/src/emacs-24.3.tar.xz
>> $ patch -p1 </usr/src/emacs-24.3-5.cygwin.patch
>> patching file emacs-24.3/CYGWIN-PATCHES/emacs-X11.postinstall
>> patching file emacs-24.3/CYGWIN-PATCHES/emacs-X11.preremove
>> patching file emacs-24.3/CYGWIN-PATCHES/emacs-w32.postinstall
>> patching file emacs-24.3/CYGWIN-PATCHES/emacs-w32.preremove
>> patching file emacs-24.3/CYGWIN-PATCHES/emacs.postinstall
>> patching file emacs-24.3/CYGWIN-PATCHES/emacs.preremove
>> $ cd emacs-24.3
>> $ autoreconf -I m4
>> $ ./configure CFLAGS='-g -0g -fsanitize=address'
>> LDFLAGS='-fsanitize=address' --without-all
>> checking for a BSD-compatible install... /usr/bin/install -c
>> checking whether build environment is sane... yes
>> checking for a thread-safe mkdir -p... /usr/bin/mkdir -p
>> checking for gawk... gawk
>> checking whether make sets $(MAKE)... yes
>> checking build system type... x86_64-unknown-cygwin
>> checking host system type... x86_64-unknown-cygwin
>> configure: error: Emacs hasn't been ported to `x86_64-unknown-cygwin'
>> systems.
>> Check `etc/MACHINES' for recognized configuration names.
>>
>> In particular, it doesn't look like the patch actually patches any emacs
>> files at all... do I need to pull all past versions of the source
>> package as well or something?
>
> The source package for emacs-24.3-5 contains lots of patches that you 
> didn't apply:
>
>     nox_mouse.patch
>     w32_encoding.patch
>     configure.ac.patch
>     syms_of_cygw32.patch
>     image_background.patch
>     w32term.w32_init.patch
>     unexcw.patch
>     memory_warnings.patch
>     24.3-4_nt_icon.patch
>     nonbootstrap_static_heap.patch
>     24.3_memalign.patch
I see... that would explain it.

For future reference, though, how does one go about discovering which 
patches to apply? Most of those file names don't associate them with 
emacs in any obvious way, and `cygcheck -f' claims that none of them 
belong to any package... do you have to go dig up the source package's 
package file and look inside?

Ryan


--
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: 64-bit emacs crashes a lot

[Ryan Johnson]

On 15/08/2013 7:40 PM, Ken Brown wrote:
> On 8/15/2013 7:14 PM, Ryan Johnson wrote:
>> On 15/08/2013 6:48 PM, Ryan Johnson wrote:
>>> On 15/08/2013 6:02 PM, Ken Brown wrote:
>>>> On 8/15/2013 5:58 PM, Ken Brown wrote:
>>>>> On 8/15/2013 5:24 PM, Ryan Johnson wrote:
>>>>>> On 15/08/2013 5:14 PM, Ken Brown wrote:
>>>>>>> On 8/15/2013 4:55 PM, Ryan Johnson wrote:
>>>>>>>> Program received signal SIGSEGV, Segmentation fault.
>>>>>>>> ___chkstk_ms () at
>>>>>>>> /usr/src/debug/gcc-4.8.1-1/libgcc/config/i386/cygwin.S:146
>>>>>>>
>>>>>>> You're not using the latest gcc, which is 4.8.1-3. Any chance that
>>>>>>> that's your problem?
>>>>>> Heh. I actually do have the latest gcc, but somehow the upgrade 
>>>>>> didn't
>>>>>> pick up the debug package (which showed as not installed in
>>>>>> setup.exe).
>>>>>> I have manually upgraded it now.
>>>>>
>>>>> OK.  But doesn't the above show that the crash is occurring in 
>>>>> gcc, not
>>>>> emacs?
>>>>>
>>>>>> BTW, how do you compile emacs from the sources given? I tried
>>>>>> untarring
>>>>>> and patching, but I get the message:
>>>>>>> configure: error: Emacs hasn't been ported to 
>>>>>>> `x86_64-unknown-cygwin'
>>>>>>> systems.
>>>>>>> Check `etc/MACHINES' for recognized configuration names.
>>>>>
>>>>> One of the patches changes configure.ac, so you have to run 
>>>>> autoreconf
>>>>> after applying it.
>>>>
>>>> Or it might be 'autoreconf -I m4'.
>>>
>>> Something is still wrong:
>>>
>>> $ cd /scratch
>>> $ tar xaf /usr/src/emacs-24.3.tar.xz
>>> $ patch -p1 </usr/src/emacs-24.3-5.cygwin.patch
>>> patching file emacs-24.3/CYGWIN-PATCHES/emacs-X11.postinstall
>>> patching file emacs-24.3/CYGWIN-PATCHES/emacs-X11.preremove
>>> patching file emacs-24.3/CYGWIN-PATCHES/emacs-w32.postinstall
>>> patching file emacs-24.3/CYGWIN-PATCHES/emacs-w32.preremove
>>> patching file emacs-24.3/CYGWIN-PATCHES/emacs.postinstall
>>> patching file emacs-24.3/CYGWIN-PATCHES/emacs.preremove
>> Ah, it seems there's a /usr/src/configure.ac.patch that happens to
>> belong to emacs...
>>
>> ... but unfortunately it seems that -fsanitize is only supported on
>> Linux and Darwin right now, so there's little reason to build emacs
>> unless you could use some particular information that a debug build
>> provides. Rats.
>
> But a build without optimization would make your backtraces more useful.
I'm not sure even a perfect stack trace will be very useful if memory 
corruption is the culprit, though. All it will do is give us even 
clearer detail about exactly what got clobbered, but with little 
additional info about what did the clobbering.

That said, I'm game if you have anything in particular you'd like more 
detail on; just let me know what you'd like to see and I'll do my best 
to dig it up. Meanwhile, I'll fire off the debug build.

Ryan


--
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: 64-bit emacs crashes a lot

[Ken Brown]

On 8/15/2013 8:58 PM, Ryan Johnson wrote:
> On 15/08/2013 7:07 PM, Ken Brown wrote:
>> On 8/15/2013 6:48 PM, Ryan Johnson wrote:
>>> On 15/08/2013 6:02 PM, Ken Brown wrote:
>>>> On 8/15/2013 5:58 PM, Ken Brown wrote:
>>>>> On 8/15/2013 5:24 PM, Ryan Johnson wrote:
>>>>>> On 15/08/2013 5:14 PM, Ken Brown wrote:
>>>>>>> On 8/15/2013 4:55 PM, Ryan Johnson wrote:
>>>>>>>> Program received signal SIGSEGV, Segmentation fault.
>>>>>>>> ___chkstk_ms () at
>>>>>>>> /usr/src/debug/gcc-4.8.1-1/libgcc/config/i386/cygwin.S:146
>>>>>>>
>>>>>>> You're not using the latest gcc, which is 4.8.1-3.  Any chance that
>>>>>>> that's your problem?
>>>>>> Heh. I actually do have the latest gcc, but somehow the upgrade
>>>>>> didn't
>>>>>> pick up the debug package (which showed as not installed in
>>>>>> setup.exe).
>>>>>> I have manually upgraded it now.
>>>>>
>>>>> OK.  But doesn't the above show that the crash is occurring in gcc,
>>>>> not
>>>>> emacs?
>>>>>
>>>>>> BTW, how do you compile emacs from the sources given? I tried
>>>>>> untarring
>>>>>> and patching, but I get the message:
>>>>>>> configure: error: Emacs hasn't been ported to
>>>>>>> `x86_64-unknown-cygwin'
>>>>>>> systems.
>>>>>>> Check `etc/MACHINES' for recognized configuration names.
>>>>>
>>>>> One of the patches changes configure.ac, so you have to run autoreconf
>>>>> after applying it.
>>>>
>>>> Or it might be 'autoreconf -I m4'.
>>>
>>> Something is still wrong:
>>>
>>> $ cd /scratch
>>> $ tar xaf /usr/src/emacs-24.3.tar.xz
>>> $ patch -p1 </usr/src/emacs-24.3-5.cygwin.patch
>>> patching file emacs-24.3/CYGWIN-PATCHES/emacs-X11.postinstall
>>> patching file emacs-24.3/CYGWIN-PATCHES/emacs-X11.preremove
>>> patching file emacs-24.3/CYGWIN-PATCHES/emacs-w32.postinstall
>>> patching file emacs-24.3/CYGWIN-PATCHES/emacs-w32.preremove
>>> patching file emacs-24.3/CYGWIN-PATCHES/emacs.postinstall
>>> patching file emacs-24.3/CYGWIN-PATCHES/emacs.preremove
>>> $ cd emacs-24.3
>>> $ autoreconf -I m4
>>> $ ./configure CFLAGS='-g -0g -fsanitize=address'
>>> LDFLAGS='-fsanitize=address' --without-all
>>> checking for a BSD-compatible install... /usr/bin/install -c
>>> checking whether build environment is sane... yes
>>> checking for a thread-safe mkdir -p... /usr/bin/mkdir -p
>>> checking for gawk... gawk
>>> checking whether make sets $(MAKE)... yes
>>> checking build system type... x86_64-unknown-cygwin
>>> checking host system type... x86_64-unknown-cygwin
>>> configure: error: Emacs hasn't been ported to `x86_64-unknown-cygwin'
>>> systems.
>>> Check `etc/MACHINES' for recognized configuration names.
>>>
>>> In particular, it doesn't look like the patch actually patches any emacs
>>> files at all... do I need to pull all past versions of the source
>>> package as well or something?
>>
>> The source package for emacs-24.3-5 contains lots of patches that you
>> didn't apply:
>>
>>     nox_mouse.patch
>>     w32_encoding.patch
>>     configure.ac.patch
>>     syms_of_cygw32.patch
>>     image_background.patch
>>     w32term.w32_init.patch
>>     unexcw.patch
>>     memory_warnings.patch
>>     24.3-4_nt_icon.patch
>>     nonbootstrap_static_heap.patch
>>     24.3_memalign.patch
> I see... that would explain it.
>
> For future reference, though, how does one go about discovering which
> patches to apply? Most of those file names don't associate them with
> emacs in any obvious way, and `cygcheck -f' claims that none of them
> belong to any package... do you have to go dig up the source package's
> package file and look inside?

Take a look at emacs.cygport.  It shows you exactly how the package was 
built, including patches.

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: 64-bit emacs crashes a lot

[Ken Brown]

On 8/15/2013 4:55 PM, Ryan Johnson wrote:
> At this point I'm pretty confident it's memory corruption of some kind.
> Consider the following semi-STC:
> 1. Invoke: emacs-nox -Q; echo -e "att $(jobs -p)\nc" > /dev/clipboard; fg
> 2. ^Z
> 3. (switch to window running gdb and hit [shift]+[insert] to paste from
> clipboard)
> 5. (switch to window running emacs): M-x compile C-a C-k ls [ret]
> 6. C-x o (to switch to the compilation output window)
> 7. Hit 'g' to keep repeating the "compilation" until gdb picks up a crash.

I tried a simpler version of this (without gdb and without 
suspending/resuming):

1. Invoke 'emacs-nox -Q' in mintty.

2. M-x compile C-a C-k ls RET

3. C-x o

4. Hit 'g' repeatedly.

I got it to abort with Fatal error 6 after slightly over 100 repetitions.

I then tried the same thing with emacs-X11 (running under X, not in 
mintty).  I hit 'g' 200 times without a problem.  I repeated this with 
emacs-w32, again 200 times without a problem.

So there's a bug somewhere.  But if it's an emacs bug, it's strange that 
it only occurs with emacs-nox and not with either of the GUI versions of 
emacs.

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: 64-bit emacs crashes a lot

[Ryan Johnson]

On 15/08/2013 10:35 PM, Ken Brown wrote:
> On 8/15/2013 4:55 PM, Ryan Johnson wrote:
>> At this point I'm pretty confident it's memory corruption of some kind.
>> Consider the following semi-STC:
>> 1. Invoke: emacs-nox -Q; echo -e "att $(jobs -p)\nc" > 
>> /dev/clipboard; fg
>> 2. ^Z
>> 3. (switch to window running gdb and hit [shift]+[insert] to paste from
>> clipboard)
>> 5. (switch to window running emacs): M-x compile C-a C-k ls [ret]
>> 6. C-x o (to switch to the compilation output window)
>> 7. Hit 'g' to keep repeating the "compilation" until gdb picks up a 
>> crash.
>
> I tried a simpler version of this (without gdb and without 
> suspending/resuming):
>
> 1. Invoke 'emacs-nox -Q' in mintty.
>
> 2. M-x compile C-a C-k ls RET
>
> 3. C-x o
>
> 4. Hit 'g' repeatedly.
>
> I got it to abort with Fatal error 6 after slightly over 100 repetitions.
>
> I then tried the same thing with emacs-X11 (running under X, not in 
> mintty).  I hit 'g' 200 times without a problem.  I repeated this with 
> emacs-w32, again 200 times without a problem.
>
> So there's a bug somewhere.  But if it's an emacs bug, it's strange 
> that it only occurs with emacs-nox and not with either of the GUI 
> versions of emacs.
Well, at least I'm not (necessarily) crazy or BLODA-infested... out of 
curiosity, can you repro with 32-bit emacs-nox? I don't remember 32-bit 
being so crash-happy, which makes me wonder if something about 64-bit 
cygwin interacts poorly with emacs.

Ryan


--
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: 64-bit emacs crashes a lot

[Ryan Johnson]

On 16/08/2013 12:34 AM, Ryan Johnson wrote:
> On 15/08/2013 10:35 PM, Ken Brown wrote:
>> On 8/15/2013 4:55 PM, Ryan Johnson wrote:
>>> At this point I'm pretty confident it's memory corruption of some kind.
>>> Consider the following semi-STC:
>>> 1. Invoke: emacs-nox -Q; echo -e "att $(jobs -p)\nc" > 
>>> /dev/clipboard; fg
>>> 2. ^Z
>>> 3. (switch to window running gdb and hit [shift]+[insert] to paste from
>>> clipboard)
>>> 5. (switch to window running emacs): M-x compile C-a C-k ls [ret]
>>> 6. C-x o (to switch to the compilation output window)
>>> 7. Hit 'g' to keep repeating the "compilation" until gdb picks up a 
>>> crash.
>>
>> I tried a simpler version of this (without gdb and without 
>> suspending/resuming):
>>
>> 1. Invoke 'emacs-nox -Q' in mintty.
>>
>> 2. M-x compile C-a C-k ls RET
>>
>> 3. C-x o
>>
>> 4. Hit 'g' repeatedly.
>>
>> I got it to abort with Fatal error 6 after slightly over 100 
>> repetitions.
>>
>> I then tried the same thing with emacs-X11 (running under X, not in 
>> mintty).  I hit 'g' 200 times without a problem.  I repeated this 
>> with emacs-w32, again 200 times without a problem.
>>
>> So there's a bug somewhere.  But if it's an emacs bug, it's strange 
>> that it only occurs with emacs-nox and not with either of the GUI 
>> versions of emacs.
> Well, at least I'm not (necessarily) crazy or BLODA-infested... out of 
> curiosity, can you repro with 32-bit emacs-nox? I don't remember 
> 32-bit being so crash-happy, which makes me wonder if something about 
> 64-bit cygwin interacts poorly with emacs.

This is really weird... I got a crash in emacs compiled with `-g -O0', 
but it makes no sense:
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 7160.0xf70]
> 0x0000000100535d0f in regex_compile (pattern=0x6000ac580 "\\(?:^\\|::  
> \\|\\S ( \\)\\(/[^ \n\t()]+\\)(\\([0-9]+\\))\\(?:: 
> \\(warning:\\)?\\|$\\| ),\\)", size=75, syntax=3408388, 
> bufp=0x10095dc30 <searchbufs+6512>) at regex.c:3627
> 3627                  || pending_exact + *pending_exact + 1 != b
> bt
> #0  0x0000000100535d0f in regex_compile (pattern=0x6000ac580 
> "\\(?:^\\|::  \\|\\S ( \\)\\(/[^ \n\t()]+\\)(\\([0-9]+\\))\\(?:: 
> \\(warning:\\)?\\|$\\| ),\\)", size=75, syntax=3408388, 
> bufp=0x10095dc30 <searchbufs+651\
> 2>) at regex.c:3627

The variable pending_exact has value 0x0, which would be a Bad Thing... 
except that the code looks like this:
>           if (!pending_exact
>
>               /* If last exactn not at current position.  */
> =>            || pending_exact + *pending_exact + 1 != b
>
... with corresponding assembly code looking very reasonable:
>    0x0000000100535cfa <regex_compile+34482>:    cmpq   $0x0,0x3f8(%rbp)
>    0x0000000100535d02 <regex_compile+34490>:    je 0x100535eca 
> <regex_compile+34946>
>    0x0000000100535d08 <regex_compile+34496>:    mov 0x3f8(%rbp),%rax
> => 0x0000000100535d0f <regex_compile+34503>:    movzbl (%rax),%eax
>    0x0000000100535d12 <regex_compile+34506>:    movzbl %al,%eax
>    0x0000000100535d15 <regex_compile+34509>:    lea 0x1(%rax),%rdx
>    0x0000000100535d19 <regex_compile+34513>:    mov 0x3f8(%rbp),%rax
>    0x0000000100535d20 <regex_compile+34520>:    add %rdx,%rax
>    0x0000000100535d23 <regex_compile+34523>:    cmp %rbx,%rax
>    0x0000000100535d26 <regex_compile+34526>:    jne 0x100535eca 
> <regex_compile+34946>

Something apparently set 0x3f8(%rbp) to NULL during the very small 
window between the cmpq and the mov two instructions later.

A second crash hit here:
> #1  0x000000010052d589 in re_iswctype (ch=80, cc=RECC_ALPHA) at 
> regex.c:2087 

The default branch was taken even though cc should have matched the 
RECC_ALPHA case:
>   switch (cc)
>     {
>     case RECC_ALNUM: return ISALNUM (ch) != 0;
>     case RECC_ALPHA: return ISALPHA (ch) != 0;
>     case RECC_BLANK: return ISBLANK (ch) != 0;
>     ....
>     case RECC_ERROR: return false;
>     default:
> =>    abort ();
>     }

This time there's a jump table involved at machine code level, so I 
couldn't easily go deeper into why the wrong jump target was chosen.

A third crash:
> #1  0x0000000100541930 in re_match_2_internal (bufp=0x10095ce20 
> <searchbufs+2912>, string1=0x0, size1=0, string2=0x6fffff00028 "-*- 
> mode: compilation; default-directory: \"~/\" -*-\nCompilation started 
> at Fri Aug 16 01:32:19\n\nls\n#message-20130808-090732#\t 
> emacs-crash.txt\t\tmusic\n6b8ob06a.default.tar.xz\t\t 
> emacs-nox.exe."..., size2=355, pos=254, regs=0x10095def0 
> <search_regs>, stop=317) at regex.c:6217
> 6217              abort ();
This time, p (the subject of the case statement) points to 0x76b3b6c7, 
which is the middle of a function (ntdll!RtlFillMemory, though the 
memory map places that address smack in the middle of kernel32.dll 
instead). This time it makes perfect sense that the switch statement 
should fail, but how did p go so wrong?

Even more strangely, it seems to be deterministic: a second crash there 
had exactly the same address as before.

The fifth crash was a repeat of the NULL pending_exact scenario that 
came first.

One last observation, or perhaps just superstition: if gdb reports a 
single thread being created at some point during the compile-fest, a 
crash usually follows soon after. If no threads are created after gdb 
attaches and continues, or if two threads are created in quick 
succession , the crash never comes (where "never" = 300+ successful 
compiles). I have no idea why that would mean anything, though...

I'm officially stumped at this point... any ideas?

Ryan




--
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: 64-bit emacs crashes a lot

[Eli Zaretskii]

I'm not subscribed to this list, so if you want me to reply, please CC
me explicitly.  Besides, this discussion should be moved to
emacs-devel@gnu.org, since I don't see anything Cygwin specific here
at this point.

> Date: Thu, 15 Aug 2013 16:55:18 -0400
> From: Ryan Johnson <ryan.johnson@cs.utoronto.ca>
> 
> On 15/08/2013 1:10 PM, Eli Zaretskii wrote:
> >> Date: Thu, 15 Aug 2013 12:58:02 -0400
> >> From: Ken Brown <kbrown@cornell.edu>
> >> CC: Eli Zaretskii <eliz@gnu.org>
> >>
> >> Eli is the expert on bidi.c (he wrote it).  He can probably tell you
> >> whether you've really bumped into an emacs bug here.
> > There's nothing wrong with bidi.c here, it just aborts because it is
> > handed an invalid character codepoint.  It would have been useful to
> > see the value of that character.
> I guess I would just consider crashing to be overkill for a bad byte on 
> the input stream...

It's not a crash, it's a deliberate abort.  Any invalid codepoint at
such low level of the Emacs display engine means only one thing: a
bug, and a grave one at that.  Such bugs must be flagged prominently
and unequivocally, prompting users to report them.  We could in
principle "recover" by substituting some other character, but such
recovery would only sweep a grave problem under the carpet.  Since
Emacs isn't a safety-critical program, and auto-saves your edits
before it commits suicide, such recovery feature is deemed
inappropriate, and detrimental to the general quality of Emacs code in
the long run.

> and in any case, if 5-byte UTF-8 is illegal, and 
> worth dying for, wouldn't it make sense to die right away rather than 
> processing it so something else can croak down the road?

See above: yes, it's worth dying for, because I'm quite sure this is a
sign of a very serious trouble in the session anyway.  Why does it
matter for you, as a user, whether we abort here or "down the road"?
The principle is to die as soon as possible, because in many cases
this allows to identify the culprit faster and easier.  IOW, dying
sooner and faster helps the Emacs maintainers to find and fix problems
without any real effect on the users.

> > Anyway, I generally agree that this is probably some memory
> > corruption, as I'm guessing that the text in the window was all ASCII
> > in this case, so any character codepoint beyond 127 is not to be
> > expected.
> I set a breakpoint there, since I thought it was guaranteed to lead to a 
> crash if it ever ran, but it turns out that's not true. Invoking M-x 
> compile triggers the breakpoint twice in a row with the following 
> (valid!) 5-byte UTF-8:
> 
> 111110XX 10XXXXXX 10XXXXXX 10XXXXXX 10XXXXXX
> 11111000 10001111 10111111 10111101 10111111
> 
> The value is always the same, and corresponds to the code point 
> U+3FFF7F, FWIW.

If the value is positive and below 3FFFFF, then the abort could not
have happened.  Therefore, I believe that the optimized build lies to
GDB, and the actual value is not what you see in GDB.

Alternatively (and that is also a known effect of debugging an
optimized build), the abort happened not where you think, but rather a
few lines below:

  default_type = (bidi_type_t) XINT (CHAR_TABLE_REF (bidi_type_table, ch));
  /* Every valid character code, even those that are unassigned by the
     UCD, have some bidi-class property, according to
     DerivedBidiClass.txt file.  Therefore, if we ever get UNKNOWN_BT
     (= zero) code from CHAR_TABLE_REF, that's a bug.  */
  if (default_type == UNKNOWN_BT)
    emacs_abort (); <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

Optimized code frequently emits only one call to emacs_abort, and
converts the other calls to a jump to the locus of that single call.

I really suggest to get an unoptimized build and debug that instead.
Debugging optimized builds, even with GCC 4.8, is a hard and
frustrating task.  In particular, most of the backtraces you posted
don't make any sense at all -- a frequent problem in optimized builds.


--
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: 64-bit emacs crashes a lot

[Eli Zaretskii]

Again, please move this discussion to emacs-devel.

> Date: Thu, 15 Aug 2013 22:35:54 -0400
> From: Ken Brown <kbrown@cornell.edu>
> 
> 1. Invoke 'emacs-nox -Q' in mintty.
> 
> 2. M-x compile C-a C-k ls RET
> 
> 3. C-x o
> 
> 4. Hit 'g' repeatedly.
> 
> I got it to abort with Fatal error 6 after slightly over 100 repetitions.
> 
> I then tried the same thing with emacs-X11 (running under X, not in 
> mintty).  I hit 'g' 200 times without a problem.  I repeated this with 
> emacs-w32, again 200 times without a problem.
> 
> So there's a bug somewhere.  But if it's an emacs bug, it's strange that 
> it only occurs with emacs-nox and not with either of the GUI versions of 
> emacs.

I suspect that buffer relocation might be the reason.  Can you show a
backtrace from the fatal error in an unoptimized build, with the above
recipe?

--
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: 64-bit emacs crashes a lot

[Bengt Larsson]

Ryan Johnson wrote:
>I set a breakpoint there, since I thought it was guaranteed to lead to a 
>crash if it ever ran, but it turns out that's not true. Invoking M-x 
>compile triggers the breakpoint twice in a row with the following 
>(valid!) 5-byte UTF-8:
>
>111110XX 10XXXXXX 10XXXXXX 10XXXXXX 10XXXXXX
>11111000 10001111 10111111 10111101 10111111
>
>The value is always the same, and corresponds to the code point 
>U+3FFF7F, FWIW. The backtrace seems to involve loading a file (maybe the 
>.elc contains 'compile or 'compilation-mode?), and the breakpoint does 
>not recur in subsequent compilations, presumably because they don't 
>re-load the file. Emacs continues normally from there, because the 
>leading bits are zero and the resulting code point doesn't pass the 
>0x3FFFFF limit.

Modern Emacs uses an extended UTF-8 as internal representation.

http://www.gnu.org/software/emacs/manual/html_node/elisp/Text-Representations.html

--
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: 64-bit emacs crashes a lot

[Eli Zaretskii]

Please move this discussion to emacs-devel@gnu.org.

> Date: Fri, 16 Aug 2013 01:59:41 -0400
> From: Ryan Johnson <ryan.johnson@cs.utoronto.ca>
> 
> The variable pending_exact has value 0x0, which would be a Bad Thing... 
> except that the code looks like this:
> >           if (!pending_exact
> >
> >               /* If last exactn not at current position.  */
> > =>            || pending_exact + *pending_exact + 1 != b
> >
> ... with corresponding assembly code looking very reasonable:
> >    0x0000000100535cfa <regex_compile+34482>:    cmpq   $0x0,0x3f8(%rbp)
> >    0x0000000100535d02 <regex_compile+34490>:    je 0x100535eca 
> > <regex_compile+34946>
> >    0x0000000100535d08 <regex_compile+34496>:    mov 0x3f8(%rbp),%rax
> > => 0x0000000100535d0f <regex_compile+34503>:    movzbl (%rax),%eax
> >    0x0000000100535d12 <regex_compile+34506>:    movzbl %al,%eax
> >    0x0000000100535d15 <regex_compile+34509>:    lea 0x1(%rax),%rdx
> >    0x0000000100535d19 <regex_compile+34513>:    mov 0x3f8(%rbp),%rax
> >    0x0000000100535d20 <regex_compile+34520>:    add %rdx,%rax
> >    0x0000000100535d23 <regex_compile+34523>:    cmp %rbx,%rax
> >    0x0000000100535d26 <regex_compile+34526>:    jne 0x100535eca 
> > <regex_compile+34946>

What is the value in the RAX register at the point of the crash?  Is
it also zero?  Or maybe it is some other invalid pointer value?

> A third crash:
> > #1  0x0000000100541930 in re_match_2_internal (bufp=0x10095ce20 
> > <searchbufs+2912>, string1=0x0, size1=0, string2=0x6fffff00028 "-*- 
> > mode: compilation; default-directory: \"~/\" -*-\nCompilation started 
> > at Fri Aug 16 01:32:19\n\nls\n#message-20130808-090732#\t 
> > emacs-crash.txt\t\tmusic\n6b8ob06a.default.tar.xz\t\t 
> > emacs-nox.exe."..., size2=355, pos=254, regs=0x10095def0 
> > <search_regs>, stop=317) at regex.c:6217
> > 6217              abort ();
> This time, p (the subject of the case statement) points to 0x76b3b6c7, 
> which is the middle of a function (ntdll!RtlFillMemory, though the 
> memory map places that address smack in the middle of kernel32.dll 
> instead). This time it makes perfect sense that the switch statement 
> should fail, but how did p go so wrong?

What is bufp->buffer at this point, and what is its contents?

--
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: 64-bit emacs crashes a lot

[Ryan Johnson]

On 16/08/2013 5:13 AM, Eli Zaretskii wrote:
>> Date: Fri, 16 Aug 2013 01:59:41 -0400
>> From: Ryan Johnson <**snip**>
Please don't feed the spammers. I get enough as it is...


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