52583Re: Vim SEGV after netbeans messes up syntax data structures
- Nov 29, 2008On Sun, Jun 1, 2008 at 12:05 PM, Bram Moolenaar <Bram@...> wrote:
>The problem of "Netbeans events are handled while updating the screen,
> Xavier de Gaye wrote:
>> >> Problem:
>> >> --------
>> >> Vim version 7.1.298 on linux.
>> >> Vim crashes processing received netbeans messages while redrawing the
>> >> windows. This happens about once every five times when running the
>> >> [...]
>> >> The following tests have been completed successfully with this patch:
>> >> * no Vim crash with the pyclewn test case
>> >> * no error reported by Valgrind with the pyclewn test case
>> >> * Vim does not crash when doing fast stepping with clewn
>> >> * netbeans does process messages when Vim is idle in normal_cmd()
>> >> * the full pyclewn regression test suite runs Ok.
>> >> [...]
>> > This will help, but I think it's still possible that Vim is updating the
>> > screen somewhere when a netbeans event is received. In functions called
>> > from normal_cmd() it's very well possible that the screen is updated
>> > directly instead of setting the must_redraw flag.
>> > One way to solve this is to set that callback_restricted flag in
>> > ui_breakcheck(). Because we don't want to handle the netbeans messages
>> > while checking if the user typed CTRL-C.
>> > It might still not be sufficient though. It's difficult to overview
>> > what happens with these asynchronous messages. And we also have to be
>> > careful not to block event handling (I think that happens when you would
>> > use the may_garbage_collect flag).
>> > Perhaps you can try out the change to ui_breakcheck() and tell us what
>> > happens. Perhaps there are other places where gui_mch_update() is
>> > called and we don't want to handle events, thus setting the flag in
>> > gui_mch_update() might be an alternative. But you can't do that
>> > always...
>> Setting the callback_restricted flag in ui_breakcheck() does not work.
>> Most pyclewn automated tests fail because the netbeans messages are
>> received (and queued) in ui_breakcheck() and nb_parse_messages() never
>> gets a chance to process the received messages. This points out to
>> a problem that may occur when netbeans is run interactively: if the
>> last netbeans message is received in ui_breakcheck(), it is not
>> processed by nb_parse_messages() and appears to the user as not
>> received at all (until the next message arrives).
>> Except for that problem, this solution fixes the memory corruption as
>> expected in all the tests that do run.
>> Another way to fix this is to prevent the netbeans callback to call
>> any vim function at all. This cancels the need of a global
>> callback_restricted flag. The callback queues the received messages
>> and exit the gui event loop. The messages are processed in the idle
>> loop where vim is waiting for character input.
>> The following patch (also attached to this mail) implements this
>> solution for FEAT_GUI_GTK. All the tests are successful (see the list
>> of tests above, in the original post) including the 51 pyclewn tests.
> This makes sense. I'll put this in the todo list for having a closer
>> I think it is possible to implement the same solution for
>> FEAT_GUI_W32, but Windows support in pyclewn is not ready yet and I
>> don't know what application can be used to test the patch (maybe Agide ?).
> This should not be changed without proper testing. So let's leave it
> as-is until we can test it.
causing a crash" has been fixed in Vim 7.2 for gtk. The attached patch
to Vim 7.2.55 (subversion revision 1273) fixes this same problem for
The following tests have been completed successfully with this patch
and pyclewn version 0.6 on Windows:
* Vim processes netbeans messages when idle
* the full pyclewn regression test suite runs Ok
Note that the crash could not be reproduced with Vim 7.2 and pyclewn,
as the current implementation of pyclewn on Windows is too slow.
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
- << Previous post in topic Next post in topic >>