This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: 64-bit emacs crashes a lot


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]