[mintty-discuss] Silent crash when editing /etc/fstab

19 views
Skip to first unread message

Chris Sutcliffe

unread,
May 17, 2010, 1:52:59 PM5/17/10
to mintty-...@googlegroups.com
Hi Andy,

I'm having an issue with mintty silently crashing when editing
/etc/fstab (via vim). What's making it very hard to diagnose it that
it only occurs if I run mintty compiled in 'release' mode (i.e. make
with no arguments). If I compile mintty in 'debug' mode (debug=1) it
works fine and if I spawn a 'release' mintty from a Cygwin console
window it also works fine.

I'm at a loss as to how to track down what may be causing the crash.
Any thoughts on where to start to diagnose the issue?

Thank you,

Chris

--
Chris Sutcliffe
http://emergedesktop.org
http://www.google.com/profiles/ir0nh34d

--
You received this message because you are subscribed to the Google Groups "mintty" group.
To post to this group, send email to mintty-...@googlegroups.com.
To unsubscribe from this group, send email to mintty-discus...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/mintty-discuss?hl=en.

Andy Koppe

unread,
May 17, 2010, 3:41:03 PM5/17/10
to mintty-...@googlegroups.com
On 17/05/2010, Chris Sutcliffe wrote:
> I'm having an issue with mintty silently crashing when editing
> /etc/fstab (via vim). What's making it very hard to diagnose it that
> it only occurs if I run mintty compiled in 'release' mode (i.e. make
> with no arguments). If I compile mintty in 'debug' mode (debug=1) it
> works fine and if I spawn a 'release' mintty from a Cygwin console
> window it also works fine.
>
> I'm at a loss as to how to track down what may be causing the crash.
> Any thoughts on where to start to diagnose the issue?

Is this on 0.7 only or can you reproduce it with 0.6.2? 'debug=1'
links with dmalloc, so you could try removing that from the makefile
to try and make it fail (and hence get a meaningful stackdump).
Otherwise, you need to enable heap debugging using the dmalloc
utility, which sets up an environment variable that controls what
checks are performed.

(I won't be able to look into this until next week.)

Andy

Chris Sutcliffe

unread,
May 18, 2010, 7:25:39 AM5/18/10
to mintty-...@googlegroups.com
On 17 May 2010 15:41, Andy Koppe wrote:
> Is this on 0.7 only or can you reproduce it with 0.6.2? 'debug=1'
> links with dmalloc, so you could try removing that from the makefile
> to try and make it fail (and hence get a meaningful stackdump).
> Otherwise, you need to enable heap debugging using the dmalloc
> utility, which sets up an environment variable that controls what
> checks are performed.

I can't recreate the issue with the 0.6 branch. Using trunk the issue
occurs only when run directly (i.e. not via a Cygwin console) and not
when compiled with debug enabled (even with dmalloc disabled). I've
attached the stackdump from the 0.7 build (mintty7.exe).

Playing with the optimizations, the crash seems to be related to
'-Os'. If I remove from cc_opts the issue goes away. Could this be
some bizarre optimization issue with the compiler?

If there is anything else I can do to help, please let me know.
mintty7.exe.stackdump

Andy Koppe

unread,
May 18, 2010, 2:46:54 PM5/18/10
to mintty-...@googlegroups.com

On 18 May 2010, at 14:25, Chris Sutcliffe wrote:

> On 17 May 2010 15:41, Andy Koppe wrote:
>> Is this on 0.7 only or can you reproduce it with 0.6.2? 'debug=1'
>> links with dmalloc, so you could try removing that from the makefile
>> to try and make it fail (and hence get a meaningful stackdump).
>> Otherwise, you need to enable heap debugging using the dmalloc
>> utility, which sets up an environment variable that controls what
>> checks are performed.
>
> I can't recreate the issue with the 0.6 branch. Using trunk the issue
> occurs only when run directly (i.e. not via a Cygwin console) and not
> when compiled with debug enabled (even with dmalloc disabled). I've
> attached the stackdump from the 0.7 build (mintty7.exe).

Thanks.

> Playing with the optimizations, the crash seems to be related to
> '-Os'. If I remove from cc_opts the issue goes away. Could this be
> some bizarre optimization issue with the compiler?

Unlikely. That sort of thing usually is a symptom of a bug in pointer
use.

> If there is anything else I can do to help, please let me know.

If you're really curious you could have a go at enabling dmalloc's
heap checking, but don't worry, I'll investigate when I get back.
Might need your minttyrc, vimrc and fstab to reproduce it. Does it
crash right away when opening fstab or after any particular operations?

Cheers,
Andy

Chris Sutcliffe

unread,
May 18, 2010, 10:49:55 PM5/18/10
to mintty-...@googlegroups.com
On 18 May 2010 14:46, Andy Koppe wrote:
> If you're really curious you could have a go at enabling dmalloc's heap
> checking, but don't worry, I'll investigate when I get back. Might need your
> minttyrc, vimrc and fstab to reproduce it. Does it crash right away when
> opening fstab or after any particular operations?

I'll gladly share whatever you need.

It crashes as soon as I press enter with 'vim /etc/fstab'.

Cheers!

Andy Koppe

unread,
Jun 1, 2010, 3:25:54 PM6/1/10
to mintty
On May 17, 6:52 pm, Chris Sutcliffe wrote:
> I'm having an issue with mintty silently crashing when editing
> /etc/fstab (via vim).  What's making it very hard to diagnose it that
> it only occurs if I run mintty compiled in 'release' mode (i.e. make
> with no arguments).  If I compile mintty in 'debug' mode (debug=1) it
> works fine and if I spawn a 'release' mintty from a Cygwin console
> window it also works fine.

A quick summary of private deliberations about this.

We've been here before:

http://groups.google.com/group/mintty-discuss/browse_thread/thread/a3946875b8bc6756

Same as back then, the issue shows up with gcc-4.3 and -Os only.
Fortunately that means that released versions, which are still
compiled with gcc-3, weren't affected.

r894 fixes it, but again, the change shouldn't actually make a
difference. The fact that it does suggests a stack corruption issue,
possibly caused by gcc, but we haven't been able to nail it down with
gdb. Let's see whether it can still be triggered with the soon-to-be-
released gcc-4.5.

Andy
Reply all
Reply to author
Forward
0 new messages