Sorry for no subject; HIGHLIGHT stops working around 144000th time
Pablo Contreras
You may think I'm crazy, why would you want to call HIGHLIGHT so many times??? Because I wrote a color scheme script that updates the highlight continuously. Each 'time' it calls HIGHLIGHT 40 times to update each major syntax element's name, and if as I did you increase the frequency did once per second, this script ends up calling HIGHLIGHT 40 x 60 x 60 times in one hour = 144000. Works perfectly, but... at around the hour, or around the 144000th call to HIGHLIGHT, HIGHLIGHT starts making the foreground color invisible. You can not read the text on the screen any more. If you do a ":" for command, the foreground colors appear but as soon as normal execution resumes and my script does more HIGHLIGHTs the ink becomes invisible again.
As a work around, I have to re-start Vim every hour or so.
Thanks guys,
Pablo.
Dominique Pellé
Hi Pablo
Could you send a minimalistic script which reproduces the problem.
Make sure the script sets all required options so it can be started
by something like "$ vim -u NONE -S bug.vim" to make sure it does
not depend on your ~/.vimrc or ~/.vim files.
Cheers
-- Dominique
PabloHot
Hi Dominique,
I have removed most of the junk and left the muscle of my script. The script gets called by the CursorHold time-out. On my _vimrc i set ut=950, so the script gets called about once per sec.
~ 40 HIGHLIGHT commands
time 60 calls per minute
time 60 minutes per hour
= around 144000 calls to HIGHLIGHT per hour.
I try running this with $ gvim -u NONE -S bug.vim and it seems to run without errors. Sorry for the flickering, not sure why this is happening. Have not tried running this for an hour yet.
I will let you know if I can make the 'bug' more reproducable(? spelling?)
Thanks a lot, guys!!
Pablo.
--
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
Ben Fritz
On Oct 9, 9:00 pm, Pablo Contreras <pabloecontreras2...@hotmail.com>
wrote:
> You may think I'm crazy, why would you want to call HIGHLIGHT
> so many times??? Because I wrote a color scheme script that updates the
> highlight continuously.
highlight definitions?
Pablo Contreras
> Date: Mon, 11 Oct 2010 08:09:41 -0700
> Subject: Re: Sorry for no subject; HIGHLIGHT stops working around 144000th time
I am still trying to find a case that makes the highlighting break that is clear to see.
Cheers, folks.
Pablo Contreras
I have written a very minimal vim script that reproduces the problem. It is a function that does EXECUTEs of many HIGHLIGHT commands, over all main groups, setting guifg and guibg. The outer loop calls this function 3000 times. On my system colors stop displaying correctly after ~2470, and I have to re-start vim. I have another computer and it does a similar thing, but curiously it does not produce any problem on my Asus-EeePC 701 laptop, which uses a non-NVidia chipset for what that's worth. The other two computers use NVidia. If you don't get the problem, you could try doubling the number of loops done by the while.
To run bug.vim, simply copy it to say: c:\ for arguments sake ( i use vim on windows xp )
On vim, do:
:cd c:\
:so bug.vim
The program will start iterating, and you will notice a counter whizzing up at the bottom of the screen. The editor's colors will turn a glaring yellow background, which is normal - not pretty but we're just testing here. Everything will look ok, apart from the glaring background yellow. Then, after a while you should notice that you can't read the text on the editor any more. This is what I'm talking about. All you will see is the glaring yellow background.
Hope this helps :)))
All the best,
Nazri Ramliy
<pabloecon...@hotmail.com> wrote:
> The program will start iterating, and you will notice a counter whizzing up
> at the bottom of the screen. The editor's colors will turn a glaring yellow
> background, which is normal - not pretty but we're just testing here.
> Everything will look ok, apart from the glaring background yellow. Then,
> after a while you should notice that you can't read the text on the editor
> any more. This is what I'm talking about. All you will see is the glaring
> yellow background.
My eyes! My eyes!
I tried you script and it works fine here (nvidia card).
$ gvim bug.vim
:so %<cr>
I ran the script twice, once with a maximized gvim (slow), and another
with a smaller sized gvim (faster).
Both works fine.
nazri.
Benjamin R. Haskell
Also fine here, using Gvim 7.3.14 under Gentoo Linux, after bumping the
number of iterations to 10,000.
But, running the test under Win7 showed the bug. There, under Vim 7.3e
beta, after approximately 2500 iterations, I started seeing:
E235: Unknown font: Fixedsys:h9:cDEFAULT
So, maybe some kind of font structure is getting allocated and not freed
when unused? (Possibly because there's no way to know it's unused?)
Either way, this script triggers the same error, but I'm not sure it's
the whole cause:
==> minimal.highlight.bug.vim <==
for i in range(50000)
highlight Normal guifg=#ffffff
endfor
=================================
Doesn't look nearly as dramatic. Adding the redraw at the end of the
loop is what causes the flashes.
Run via:
gvim.exe -u NONE -N +'syntax on' +'source %' /path/to/minimal.highlight.bug.vim
Or, if you want to see the message (since the GUI becomes unreadable
after the font goes missing -- though it seems to gradually return to
near-normal):
gvim.exe -u NONE -N +'syntax on' +'source %' +'redir! > ~/vim.error.msg' +'silent! messages' +'redir END' +'q!' /path/to/minimal.highlight.bug.vim
--
Best,
Ben
Christian Brabandt
> Also fine here, using Gvim 7.3.14 under Gentoo Linux, after bumping the
> number of iterations to 10,000.
>
> But, running the test under Win7 showed the bug. There, under Vim 7.3e
> beta, after approximately 2500 iterations, I started seeing:
>
> E235: Unknown font: Fixedsys:h9:cDEFAULT
I see that on Windows XP with Vim 7.2.284 after approximately 20000
iterations. But what is really weird is, that the whole gui is broken
afterwards. The window is not redrawn correctly afterwards and when typing
the letters appear in the root window (e.g. it looks like I am typing
on the Desktop of Windows itsself) and all different artifacts are drawn
on the screen. Even after quitting vim, I still see some artifacts.
Very weird.
>
> So, maybe some kind of font structure is getting allocated and not freed
> when unused? (Possibly because there's no way to know it's unused?)
>
> Either way, this script triggers the same error, but I'm not sure it's
> the whole cause:
>
> ==> minimal.highlight.bug.vim <==
> for i in range(50000)
> highlight Normal guifg=#ffffff
> endfor
That triggers the same bug, but does not error the message.
> =================================
>
> Doesn't look nearly as dramatic. Adding the redraw at the end of the
> loop is what causes the flashes.
>
> Run via:
>
> gvim.exe -u NONE -N +'syntax on' +'source %'
> /path/to/minimal.highlight.bug.vim
>
> Or, if you want to see the message (since the GUI becomes unreadable
> after the font goes missing -- though it seems to gradually return to
> near-normal):
>
> gvim.exe -u NONE -N +'syntax on' +'source %' +'redir! > ~/vim.error.msg'
> +'silent! messages' +'redir END' +'q!' /path/to/minimal.highlight.bug.vim
That triggers the same but, but I don't see the error message in the
redirected file.
regards,
Christian
Sergey Khorev
> I see that on Windows XP with Vim 7.2.284 after approximately 20000
> iterations. But what is really weird is, that the whole gui is broken
> afterwards. The window is not redrawn correctly afterwards and when typing
> the letters appear in the root window (e.g. it looks like I am typing
> on the Desktop of Windows itsself) and all different artifacts are drawn
> on the screen. Even after quitting vim, I still see some artifacts.
> Very weird.
It's not weird, these are symptoms of the same problem: Vim leaks GUI resources
(you can enable monitoring of GDI objects in task manager and see them
increasing until they reach 10000). Apparently Vim creates new font for each
iteration and does not destroy created fonts.
Ken Takata
2010/10/12 Tue 15:46:39 UTC+9 Sergey Khorev:
I think I found the cause of this resource leak problem.
The leak occurs in hl_do_font() (syntax.c).
Attached patch fixes the problem. I tested it on Windows 7 and
bug.vim worked fine.
(Sorry if I posted this message twice.)
Best regards,
Ken Takata
Tony Mechelynck
line 8086?
Best regards,
Tony.
--
It's easier to fight for one's principles than to live up to them.
Bram Moolenaar
--
BLACK KNIGHT: I'm invincible!
ARTHUR: You're a looney.
"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD
/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
Ken Takata
2012/10/19 Fri 10:08:26 UTC+9 Tony Mechelynck:
> Hm... Isn't a similar addition necessary for the fontset case, before
> line 8086?
I'm not sure because the fontset case isn't used on Windows,
but it seems necessary. I have updated the patch.
Can anyone test this patch on Linux or other OS?
Best regards,
Ken Takata
Tony Mechelynck
GTK2 will be needed, since GTK2 GUI and +xfontset are mutually incompatible.
Best regards,
Tony.
--
" ... I told my doctor I got all the exercise I needed being a
pallbearer for all my friends who run and do exercises!"
-- Winston Churchill