> > I'm not sure how useful this will be. For Solaris we are using SIGSTKSZ
> > increased from 8000 to 16384. But recently we have seen few core dumps
> > like
> >
> >
> > 0000000ccfc42860 vim`mch_write+0x22()
> > 0000000ccfc42890 vim`ui_write+0x5b()
> > 0000000ccfc428b0 vim`stoptermcap+0xc6()
> > 0000000ccfc428c0 preserve_exit+0x32()
> > 0000000ccfc428d0 libc.so.1`__sighndlr+6()
> > 0000000ccfc42970 libc.so.1`call_user_handler+0x2f1()
> > 0000000ccfc429a0 libc.so.1`sigacthandler+0xde(1, 0, ccfc429c0)
> > 00007fd8658283e0 libc.so.1`__pollsys+0xa()
> > 00007fd865828470 libc.so.1`pselect+0x193()
> > 00007fd865828490 libc.so.1`select+0x6b()
> > 00007fd86582e4f0 vim`RealWaitForChar+0x147()
> > 00007fd865834550 vim`WaitForCharOrMouse+0x1fa()
> > 00007fd8658345a0 vim`ui_wait_for_chars_or_timer+0x13d()
> > 00007fd865834600 vim`mch_inchar+0x141()
> > 00007fd865834630 vim`ui_inchar+0xd0()
> > 00007fd865834710 inchar+0x1c6()
> > 00007fd8658347e0 vgetorpeek+0x1ce5()
> > 00007fd865834840 vgetc+0x8f()
> > 00007fd865834850 safe_vgetc+9()
> > 00007fd865834920 normal_cmd+0x134()
> > 00007fd865834a10 vim`main_loop+0x85e()
> > 00007fd865834a60 vim`vim_main2+0x9ec()
> > 00007fd865834ab0 vim`main+0x464()
> > 00007fd865834ac0 0x4b4244()
> >
> > Sadly I don't have reproducible case.
> >
> > It turns out that the signal stack is exhausted. Looking into the source
> > code, mch_write calls RealWaitForChar (in fact it is being inlined in
> > our case). And RealWaitForChar has
> >
> > fd_set rfds, wfds, efds;
> >
> > When compiled 64bit, fd_set is 8192 bytes. We have three of them, and
> > indeed the function tries to allocate roughly 3*8192 of stack. So I'm
> > planning on quadrupling the signal stack size to 65536.
> >
> > On the other hand, I guess that these three are the biggest thing on the
> > signal stack. Maybe pre-allocating or making them global variables would
> > be better solution.
>
> Since RealWaitForChar() is not used recursively, making them static
> variables is an easy change.
Right, one way to go. I can confirm that the stack went to 0x28. I have
given vim some testing, but as you can imagine, it's based on my using
it. No problem encountered.
> It's strange that RealWaitForChar() is inlined with mch_write() though.
> It's a large function and called from several other places.
Yes, somewhere in the past we have decided to use -O3. I am not a big
fan of that as it makes gcc to do weird things and I'm not convinced
that it's really faster to -Os or -O2. The function really is inlined
multiple times in our case.
> If you apply this change, I wonder if it would not run out of stack
> somewhere else:
>
>
> --- /home/mool/vim/git/vim81/src/os_unix.c 2018-09-30 21:43:17.307692512
> +0200
> +++ os_unix.c 2018-10-30 22:41:57.564967930 +0100
> @@ -6194,7 +6194,9 @@
>
> struct timeval tv;
> struct timeval *tvp;
> - fd_set rfds, wfds, efds;
> + // These are static because they can take 8 Kbyte each and cause the
> + // signal stack to run out.
> + static fd_set rfds, wfds, efds;
> int maxfd;
> long towait = msec;
I haven't seen that, but then again, I was not able to reproduce the
original issue too. It was reported internally by my colleague and
strangely it is happening right after the machine is rebooted.
The safest thing for me seems to be at the moment to keep both the
signal stack increased and make the fd_set variables static. RAM is
cheap in our case. As official fix probably only the static variables
are the way to go. IMO.
Many thanks Bram for your dedication to Vim, to me it's a life changer.
--
Vlad
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
