mintty windows silently closing
Chris Sutcliffe
mintty windows silent closing themselves and leaving bash processes
running. I've had this happen several times now. Unfortunately I
haven't been able to nail down exactly what's causing it, but I
figured I'd give you the heads up. I'll try and find a way to
reliably recreate the issue, if I figured it out, I'll let you know.
Chris
--
Chris Sutcliffe
http://emergedesktop.org
Andy Koppe
> mintty windows silent closing themselves and leaving bash processes
> running. I've had this happen several times now. Unfortunately I
> haven't been able to nail down exactly what's causing it, but I
> figured I'd give you the heads up. I'll try and find a way to
> reliably recreate the issue, if I figured it out, I'll let you know.
reproduce it as well? What sort of circumstances did it happen in?
Does it look like it's to do with scrolling?
Andy
Chris Sutcliffe
> reproduce it as well? What sort of circumstances did it happen in?
> Does it look like it's to do with scrolling?
It could be related to the scrolling, as I did enable it.
I've attached my .minttyrc for your reference. One thing I should
point out is that all open mintty windows close at the same time. I
typically have several (3 to 4) mintty windows open at any given
point, and when it occurs, all of them close, with the bash.exe
processes remaining intact.
Could it perhaps have something to do with the hidden console (I
believe one is created?) being killed by something, and as a result,
all the child process (I assume the mintty windows), dying as a
result? Pure conjecture on my part, having not looked at the code...
Cheers!
Andy Koppe
> It could be related to the scrolling, as I did enable it.
>
> I've attached my .minttyrc for your reference.
> One thing I should
> point out is that all open mintty windows close at the same time. I
> typically have several (3 to 4) mintty windows open at any given
> point, and when it occurs, all of them close, with the bash.exe
> processes remaining intact.
that's not supposed to happen, even if one of them crashes.
> Could it perhaps have something to do with the hidden console (I
> believe one is created?) being killed by something, and as a result,
> all the child process (I assume the mintty windows), dying as a
> result? Pure conjecture on my part, having not looked at the code...
exec call in mintty's child process, i.e. the main mintty process
shouldn't have one.
How do you invoke the minttys, and what OS are you on? And could you
go back to 0.4.4 for a bit to see whether it happens there too,
thereby conveniently pinning the blame on 1.7.0-60? :)
Andy
Chris Sutcliffe
>> point out is that all open mintty windows close at the same time. I
>> typically have several (3 to 4) mintty windows open at any given
>> point, and when it occurs, all of them close, with the bash.exe
>> processes remaining intact.
>
> Woah, that's weird. The minttys are all independent processes, so
> that's not supposed to happen, even if one of them crashes.
>
>> Could it perhaps have something to do with the hidden console (I
>> believe one is created?) being killed by something, and as a result,
>> all the child process (I assume the mintty windows), dying as a
>> result? Pure conjecture on my part, having not looked at the code...
>
> Could be. Although, the invisible console (if any) is created by the
> exec call in mintty's child process, i.e. the main mintty process
> shouldn't have one.
>
> How do you invoke the minttys, and what OS are you on? And could you
> go back to 0.4.4 for a bit to see whether it happens there too,
> thereby conveniently pinning the blame on 1.7.0-60? :)
I've not been able to recreate the issue today. I have since svn up'd
to 507 and rebooted. Perhaps the it was one of the age old,
fix-windows-by-rebooting type issues.
FWIW, I'm running Windows XP Pro Corporate - SP3. I invoke mintty with:
C:\cygwin\bin\mintty.exe -
If it happens again, I'll do my best to provide some useful information.
Chris Sutcliffe
> to 507 and rebooted. Perhaps the it was one of the age old,
> fix-windows-by-rebooting type issues.
I spoke to soon...
> If it happens again, I'll do my best to provide some useful information.
With more than one mintty window open:
cd /etc
vim fstab
or
vim /etc/fstab
All other mintty windows close except the window where vim is
executing (though sometimes it closes as well). The bash.exe and
vim.exe processes remain.
This happens for me all the time.
As previously mentioned, I'm using XP Corporate Edition with SP3
installed running Cygwin 1.7.0-60 and mintty svn trunk (507).
mintty.exe compiled out of the 0.4 branch does not display this
behaviour.
Let me know if there is something else you would like me to do.
Andy Koppe
> With more than one mintty window open:
>
> cd /etc
> vim fstab
>
> or
>
> vim /etc/fstab
>
> All other mintty windows close except the window where vim is
> executing (though sometimes it closes as well). The bash.exe and
> vim.exe processes remain.
>
> This happens for me all the time.
to pin down a few more variables:
- I assume you're using gcc-4 to compile it?
- Any custom compiler flags?
- Have you got any of LANG, LC_CTYPE or LC_ALL set?
- Are you running as administrator?
- Is run.exe involved when invoking mintty or vim?
- Does it happen with /etc/fstab only, or with an empty buffer or
other files as well?
- Does switching off scrollback on the alternate screen make a
difference?
- Does the issue happen with r501 as well? (That's alpha1 plus the fix
for the locale setting bug, but before messing about with the
scrolling.)
- Does it happen with latest mintty and cygwin-1.7.0-59?
Sorry for this scattergun approach, but I don't know a better way to
tackle this. Ideas welcome.
Thanks,
Andy
Chris Sutcliffe
>> executing (though sometimes it closes as well). The bash.exe and
>> vim.exe processes remain.
>>
>> This happens for me all the time.
Some more interesting stuff found during testing... If mintty is
started from a Cygwin console, it does not silently close like those
started via:
C:\cygwin\bin\mintty.exe -
Don't know if this indicating the hidden console thing again (since I
believe a hidden console is not created if started from an existing
console)?
> I'm still stumped, and haven't managed to reproduce it yet. Let's try
> to pin down a few more variables:
>
> - I assume you're using gcc-4 to compile it?
No, gcc-3, I don't specify any gcc...
> - Any custom compiler flags?
No, I simply call 'make' in trunk.
> - Have you got any of LANG, LC_CTYPE or LC_ALL set?
Yes, LANG=en_CA.UTF-8
> - Are you running as administrator?
Yes.
> - Is run.exe involved when invoking mintty or vim?
No.
> - Does it happen with /etc/fstab only, or with an empty buffer or
> other files as well?
simply running vim causes no problem, but running 'vim test' (where
test does not exist) will cause the same behaviour.
> - Does switching off scrollback on the alternate screen make a
> difference?
No, with it on or off makes no difference.
> - Does the issue happen with r501 as well? (That's alpha1 plus the fix
> for the locale setting bug, but before messing about with the
> scrolling.)
Yes.
> - Does it happen with latest mintty and cygwin-1.7.0-59?
Yes.
> Sorry for this scattergun approach, but I don't know a better way to
> tackle this. Ideas welcome.
No worries, issues like this are tricky to track down.
I tried compiling with debug symbols, but running via gdb from a
Cygwin console window didn't help due to what I mentioned at the start
of this post. If memory servers, isn't there a way to attach gdb to a
running process?
Cheers!
Chris Sutcliffe
>> - I assume you're using gcc-4 to compile it?
>
> No, gcc-3, I don't specify any gcc...
Compiling with gcc-4 corrects the issue, no idea why.
Andy Koppe
> *head -> desk *
>
> >> - I assume you're using gcc-4 to compile it?
>
> > No, gcc-3, I don't specify any gcc...
>
> Compiling with gcc-4 corrects the issue, no idea why.
Thanks for all the info. Still no luck trying to reproduce the issue
here though. Two more variables I can think of: your bash startup
files and vimrc (perhaps by PM?).
Anything else running that might be playing a role here?
Andy
Andy Koppe
> With more than one mintty window open:
>
> cd /etc
> vim fstab
>
> or
>
> vim /etc/fstab
>
> All other mintty windows close except the window where vim is
> executing (though sometimes it closes as well). The bash.exe and
> vim.exe processes remain.
>
> This happens for me all the time.
with fresh 1.7. It was fine on XP Home.
Off into MinTTY history trying to work out which change triggers
it ...
Andy
Andy Koppe
>
> > cd /etc
> > vim fstab
>
> > or
>
> > vim /etc/fstab
>
> > All other mintty windows close except the window where vim is
> > executing (though sometimes it closes as well). The bash.exe and
> > vim.exe processes remain.
>
> > This happens for me all the time.
>
> Yay, I've finally managed to reproduce the issue, on an XP Pro install
> with fresh 1.7. It was fine on XP Home.
- run mintty from start menu shortcut
- run rxvt from start menu shortcut
- run 'vim /etc/fstab' in *rxvt*
- press close button on rxvt
-> both rxvt and mintty close
Andy
Andy Koppe
Trouble is, the "fix" shouldn't make a difference, so it's probably
just masking the real issue. All it does is take the bool parameter
off cp_update_locale. The code in cp_update_locale is innocent,
because removing it didn't make the issue go away. Commenting out the
cp_update_locale call in main() did also "fix" the issue though. A
corrupted stack perhaps? Still no idea how vim, rxvt and consoles fit
into the picture.
Andy
Chris Sutcliffe
>> with fresh 1.7. It was fine on XP Home.
>>
>> Off into MinTTY history trying to work out which change triggers
>> it ...
>
> Tracked it down to r480. Gone in r513.
Unfortunately not for me.
> Trouble is, the "fix" shouldn't make a difference, so it's probably
> just masking the real issue. All it does is take the bool parameter
> off cp_update_locale. The code in cp_update_locale is innocent,
> because removing it didn't make the issue go away. Commenting out the
> cp_update_locale call in main() did also "fix" the issue though. A
> corrupted stack perhaps? Still no idea how vim, rxvt and consoles fit
> into the picture.
The corrupt stack sounds like a possibility. I assume gcc-3 and gcc-4
handle the stack differently (hence it working with gcc-4 and not
gcc-3)? I tried adding '-mms-bitfields' to see if it would make any
difference, but it didn't help.
The kicker is that anything I could use to do a trace (gdb, strace)
don't help because I don't experience the behaviour if mintty is
started from a Cygwin console.
As always, if there is anything I can do to help track down the issue,
please let me know.
Cheers!
Chris Sutcliffe
> don't help because I don't experience the behaviour if mintty is
> started from a Cygwin console.
I managed to connect to running mintty instance with gdb, and
unfortunately it didn't provide any helpful information. The other
windows silently closed, and the one I attached gdb to just went in to
a bad state where it didn't accept input and did not refresh /
repaint. There were no signals sent to gdb, and backtrace didn't
provide anything useful.
If there is anything else anyone can think of, I'd be happy to try it.
Andy Koppe
> >> Yay, I've finally managed to reproduce the issue, on an XP Pro install
> >> with fresh 1.7. It was fine on XP Home.
>
> >> Off into MinTTY history trying to work out which change triggers
> >> it ...
>
> > Tracked it down to r480. Gone in r513.
>
> Unfortunately not for me.
"fix" worked after taking it from r480 to r513.
> > Trouble is, the "fix" shouldn't make a difference, so it's probably
> > just masking the real issue. All it does is take the bool parameter
> > off cp_update_locale. The code in cp_update_locale is innocent,
> > because removing it didn't make the issue go away. Commenting out the
> > cp_update_locale call in main() did also "fix" the issue though. A
> > corrupted stack perhaps? Still no idea how vim, rxvt and consoles fit
> > into the picture.
>
> The corrupt stack sounds like a possibility. I assume gcc-3 and gcc-4
> handle the stack differently (hence it working with gcc-4 and not
> gcc-3)? I tried adding '-mms-bitfields' to see if it would make any
> difference, but it didn't help.
suspicion about a compiler problem, although of course most of the
time this sort of thing turns out to be a program bug being exposed
differently.
Thank you very much for the gdb/strace efforts.
As you noted as well, the issue appears to be triggered by accesses to
vim .swp files. A couple of times I had it occurring when just doing
tab completion in /etc while such a file exists? Do you happen to know
whether there's anything special about those files? Are they memory-
mapped?
Andy
Andy Koppe
> > >> with fresh 1.7. It was fine on XP Home.
>
> > >> Off into MinTTY history trying to work out which change triggers
> > >> it ...
>
> > > Tracked it down to r480. Gone in r513.
>
> > Unfortunately not for me.
>
> Confirmed. I must have done something wrong when checking that the
> "fix" worked after taking it from r480 to r513.
work.
I'd stuck a call to 'bla(bool)' where the call to update_locale(bool)
was in winmain.c@480, and tracked the issue further back to r444.
Further investigation needed.
Andy
Chris Sutcliffe
> suspicion about a compiler problem, although of course most of the
> time this sort of thing turns out to be a program bug being exposed
> differently.
It may well be a compiler issue.
> Thank you very much for the gdb/strace efforts.
No worries, I like to do what I can to help out!
> As you noted as well, the issue appears to be triggered by accesses to
> vim .swp files. A couple of times I had it occurring when just doing
> tab completion in /etc while such a file exists? Do you happen to know
> whether there's anything special about those files? Are they memory-
> mapped?
I'm not familiar with the internals of the .swp file I'm afraid.
Would you like me to pose the question on the vim-dev mailing list?
FWIW, r514 fixes the issue for me.