-
Notifications
You must be signed in to change notification settings - Fork 58
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[CRASH] wxLuaEdit at "Run wxLua program" #5
Comments
@ildar, I don't think there is anything I can do as these look to be wxwidgets asserts and not something that wxlua would be responsible for. One way to see where they are thrown would be to compile wxwidgets with debug info (and don't strip the binaries when wxlua is built) and step through the debugger to see under what conditions they are thrown, but still, there is not much I can do and these should probably be reported (or at least discussed) in wxdev list. |
Also, I don't see any information indicating crash. I think the crash needs to be investigated separately; you can open the dump in gdb and look at the stack trace that led to the crash. |
Yes, indeed. Very sorry for that. Here it comes.
Please note that this is wxLua + wxGTK + GTK+3 (I noticed that you still
use GTK+2).
GTK version is 3.22.24
[wxLuaEdit.crash.txt](https://github.com/pkulchenko/wxlua/files/1426749/wxLuaEdit.crash.txt)
|
Just to copy the relevant information here:
The relevant fragment from Valgrind log:
Just to confirm, this is running wxLuaEdit, not ZeroBrane Studio, right? Do you know what was done in the editor at the time of the crash? The stack trace looks believable, but I don't see any calls to update wxStatusBar, so I'm not sure why it's in the trace. I did run into some issues with status bar updates from |
Paul, this is indeed wxLuaEdit, not ZBS.
I believe that the crash occurs related to IDLE state (one guy from
#wxwidgets IRC gave me a hint about it).
As I wrote, it crashes while I'm clicking around in the app. But with
valgrind actually the window doesn't make it even to draw :) crashing
earlier.
|
Paul,
I rebuilt wxGTK/wxstedit/wxLua with GTK+2. Now the wxLuaEdit doesn't crash.
But from Valgrind point of view the difference is small: error number is
100+. Attaching: [wxLuaEdit.valgrind.log](https://github.com/pkulchenko/wxlua/files/1482104/wxLuaEdit.valgrind.log)
|
Paul,
I got another crash, could you please check? This one is after X-Paste with
middle-click (Linux x64). Could you please check?
I see it on two prebuilt wxlua (old veresions). I'll get you backtraces
soon.
|
Ah, sorry,
it seems to be the same `DoUpdateStatusText` problem.
|
So, if the issue is with wxLuaEdit, can you apply the same workaround I implemented in ZBS as described in my earlier comment? |
@ildar, can you try the change in my last comment to see if it fixes the issue? |
@ildar, actually, I checked the source code of wxLuaEdit to see how to apply the suggested solution, but I don't see any usage of wxStatusBar, so not sure why it's showing up in the stack trace. Are you running the debug or release build? |
Currently the most annoying is crash on mouse-middle-click to paste (
#5 (comment)).
I believe it's not in wxLuaEdit source because wxLua and ZBS also crash the
same way.
Output:
$ wxLuaEdit
(wxLuaEdit:27730): Gtk-CRITICAL **: 11:52:33.488:
gtk_box_gadget_distribute: assertion 'size >= 0' failed in GtkScrollbar
(wxLuaEdit:27730): Gtk-CRITICAL **: 11:52:33.488:
gtk_box_gadget_distribute: assertion 'size >= 0' failed in GtkScrollbar
(wxLuaEdit:27730): Gtk-CRITICAL **: 11:52:33.488:
gtk_box_gadget_distribute: assertion 'size >= 0' failed in GtkScrollbar
(wxLuaEdit:27730): Gtk-CRITICAL **: 11:52:33.488:
gtk_box_gadget_distribute: assertion 'size >= 0' failed in GtkScrollbar
(wxLuaEdit:27730): Gtk-WARNING **: 11:52:33.488: Negative content width -8
(allocation 12, extents 10x10) while allocating gadget (node button, owner
GtkButton)
(wxLuaEdit:27730): Gtk-WARNING **: 11:52:33.488: Negative content height -4
(allocation 6, extents 5x5) while allocating gadget (node button, owner
GtkButton)
(wxLuaEdit:27730): Gtk-WARNING **: 11:52:33.488: Negative content width -14
(allocation 6, extents 10x10) while allocating gadget (node button, owner
GtkButton)
(wxLuaEdit:27730): Gtk-CRITICAL **: 11:52:33.489:
gtk_box_gadget_distribute: assertion 'size >= 0' failed in GtkScrollbar
(wxLuaEdit:27730): Gtk-CRITICAL **: 11:52:33.489:
gtk_box_gadget_distribute: assertion 'size >= 0' failed in GtkScrollbar
(wxLuaEdit:27730): Gtk-WARNING **: 11:52:33.499: Negative content width -14
(allocation 6, extents 10x10) while allocating gadget (node button, owner
GtkButton)
(wxLuaEdit:27730): Gtk-WARNING **: 11:52:33.499: Negative content width -14
(allocation 6, extents 10x10) while allocating gadget (node button, owner
GtkButton)
(wxLuaEdit:27730): Gdk-CRITICAL **: 11:52:35.982: The window 0xa25660
already has a drawing context. You cannot call
gdk_window_begin_draw_frame() without calling gdk_window_end_draw_frame()
first.
(wxLuaEdit:27730): Gdk-CRITICAL **: 11:52:35.982:
gdk_drawing_context_get_cairo_context: assertion 'GDK_IS_DRAWING_CONTEXT
(context)' failed
Ошибка сегментирования
|
@ildar, thank you for the update. I don't see any reason why it would be failing in Just to confirm, are you saying that this crash happens after you make mouse-middle-click? Also, are you still running wxLuaEdit example? I don't see any status bar-related code in it, so not sure if this is a bogus stack trace or there is something else going on... Can you try compiling and running wxwidgets/samples/stc example and using the same mouse-middle-click there to paste? I'm curious if you get the same behavior or not. If you do, I can open a wxwidgets ticket for it. |
Paul, I'm very sorry for the confusion i made to you.
The last trace I published was for `wxLua`, not wxLuaEdit (both suffer from
this issue).
I'll fix and publish the latter a few hours later.
It's a brilliant idea about wx example I'll try it today.
|
@ildar, I'm still a bit confused about what happens. If the crash is related to middle-mouse click, then I'd try to reproduce it in the wxwidgets sample to see if the same problem exists there, in which case I can open a wxwidgets ticket. If the crash is related to exiting the wxlua process, then I suggest re-testing on the most recent master branch, as there have been several fixes that I expect to address this issue. Let me know what you can find. With respect to your backtrace, I check wxLuaEdit source, but I don't see wxStatusBar used anywhere there, and it looks like that method is shown in the stack trace. If you are not running the debug build, can you try compiling with the DEBUG option and then executing the same action in the application to see what stack trace is going to be reported. |
@ildar, please retest on the current master branch build; I've made several changes that allow building against the current wxwidgets master, so would be interested to see if this is fixed, as I plan to use the master branch for the next upgrade. |
Paul, FYI I experience the mid-mouse-click crash on the
https://github.com/pkulchenko/ZeroBraneStudio/tree/upgrade-binaries-190 .
In ZBS.
I mean your pristine binaries.
WRONG! Please ignore:
A minute later I found that the crash does not happen in "C" locale. While e.g. "en_US" locale does the thing:
```
[ildar@ildar ZeroBraneStudio-upgrade-binaries-190]$ LANG=en_US ./zbstudio.sh
[ildar@ildar ZeroBraneStudio-upgrade-binaries-190]$
(lua:457105): Gdk-CRITICAL **: 14:57:26.598: The window 0x734c40 already
has a drawing context. You cannot call gdk_window_begin_draw_frame()
without calling gdk_window_end_draw_frame() first.
(lua:457105): Gdk-CRITICAL **: 14:57:26.598:
gdk_drawing_context_get_cairo_context: assertion 'GDK_IS_DRAWING_CONTEXT
(context)' failed
./zbstudio.sh: line 20: 457105 Segmentation fault bin/linux/$ARCH/lua
src/main.lua zbstudio -cwd "$CWD" "$@"
```
(here I got rid of 2>/dev/null)
I wonder if this clarifies anything.
|
oops. The bug is back. Even with "C" locale.
Yet Paul, please note that your binaries crash too. Then let's check the
bottom layer:
… $ rpm -q glibc libgtk+3utton
glibc-2.27-alt8.x86_64
libgtk+3-3.24.11-alt1.x86_64
|
@ildar, can you check the core dump? |
@ildar, the last gdb stacktrace you included was for LuaEdit. Do you have the similar one for ZBS? Also, does the crash happen when you click on the mid-mouse-click in the editor? |
@ildar, I tested on Ubuntu 16.04, but can't cause a crash when the mid-mouse-click is done. I get the text pasted (inconsistently a bit), but no crashes. Does the app crash when the click happens or when you close the app? |
@ildar, can you get the backtrace from gdb like you did earlier? I can't do anything with the coredump on my machine (as it needs to be processed on yours). |
(gdb) bt
#0 0x00007ffff52a40f0 in cairo_translate () from /usr/lib64/libcairo.so.2
#1 0x00007ffff5bd6a35 in ?? () from /usr/lib64/libgtk-3.so.0
#2 0x00007ffff5a7dcef in gtk_main_do_event () from /usr/lib64/libgtk-3.so.0
#3 0x00007ffff5598375 in ?? () from /usr/lib64/libgdk-3.so.0
#4 0x00007ffff55a86c8 in ?? () from /usr/lib64/libgdk-3.so.0
#5 0x00007ffff55a98c6 in ?? () from /usr/lib64/libgdk-3.so.0
#6 0x00007ffff55a9ac4 in ?? () from /usr/lib64/libgdk-3.so.0
#7 0x00007ffff7308efc in wxWindow::Update() ()
from bin/linux/x64/clibs/libwx.so
#8 0x00007ffff731a2b8 in wxStatusBar::DoUpdateStatusText(int) ()
from bin/linux/x64/clibs/libwx.so
#9 0x00007ffff7220e6c in ?? () from bin/linux/x64/clibs/libwx.so
#10 0x000000000042ba29 in ?? ()
#11 0x0000000000410102 in lua_pcall ()
#12 0x00007ffff726c21c in wxLuaState::LuaPCall(int, int) ()
from bin/linux/x64/clibs/libwx.so
#13 0x00007ffff7260f02 in wxLuaEventCallback::OnEvent(wxEvent*) ()
from bin/linux/x64/clibs/libwx.so
#14 0x00007ffff7260d05 in wxLuaEventCallback::OnAllEvents(wxEvent&) ()
from bin/linux/x64/clibs/libwx.so
#15 0x00007ffff745610c in wxAppConsoleBase::CallEventHandler(wxEvtHandler*,
wxEventFunctor&, wxEvent&) const () from bin/linux/x64/clibs/libwx.so
#16 0x00007ffff74d1592 in
wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntr--Type <RET> for
more, q to quit, c to continue without paging--
yBase const&, wxEvtHandler*, wxEvent&) () from bin/linux/x64/clibs/libwx.so
#17 0x00007ffff74d1d50 in wxEvtHandler::SearchDynamicEventTable(wxEvent&) ()
from bin/linux/x64/clibs/libwx.so
#18 0x00007ffff74d1e0a in wxEvtHandler::TryHereOnly(wxEvent&) ()
from bin/linux/x64/clibs/libwx.so
#19 0x00007ffff74d1e5f in wxEvtHandler::ProcessEventLocally(wxEvent&) ()
from bin/linux/x64/clibs/libwx.so
#20 0x00007ffff74d1ed3 in wxEvtHandler::ProcessEvent(wxEvent&) ()
from bin/linux/x64/clibs/libwx.so
#21 0x00007ffff7274f84 in wxStyledTextCtrl::NotifyParent(SCNotification*) ()
from bin/linux/x64/clibs/libwx.so
#22 0x00007ffff727fb94 in ScintillaWX::NotifyParent(SCNotification) ()
from bin/linux/x64/clibs/libwx.so
#23 0x00007ffff7560408 in Editor::NotifyUpdateUI() ()
from bin/linux/x64/clibs/libwx.so
#24 0x00007ffff756b1cc in Editor::Paint(Surface*, PRectangle) ()
from bin/linux/x64/clibs/libwx.so
#25 0x00007ffff7281651 in ScintillaWX::DoPaint(wxDC*, wxRect) ()
from bin/linux/x64/clibs/libwx.so
#26 0x00007ffff7278402 in wxStyledTextCtrl::OnPaint(wxPaintEvent&) ()
from bin/linux/x64/clibs/libwx.so
#27 0x00007ffff745610c in wxAppConsoleBase::CallEventHandler(wxEvtHandler*,
wxEventFunctor&, wxEvent&) const () from bin/linux/x64/clibs/libwx.so
#28 0x00007ffff74d1592 in
wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&,
wxEvtHandler*, wxEvent&) () from bin/linux/x64/clibs/libwx.so
#29 0x00007ffff74d165b in wxEventHashTable::HandleEvent(wxEvent&,
wxEvtHandler*) () from bin/linux/x64/clibs/libwx.so
#30 0x00007ffff74d1e25 in wxEvtHandler::TryHereOnly(wxEvent&) ()
from bin/linux/x64/clibs/libwx.so
#31 0x00007ffff74d1e5f in wxEvtHandler::ProcessEventLocally(wxEvent&) ()
from bin/linux/x64/clibs/libwx.so
#32 0x00007ffff74d1ed3 in wxEvtHandler::ProcessEvent(wxEvent&) ()
from bin/linux/x64/clibs/libwx.so
#33 0x00007ffff74d1ff1 in wxEvtHandler::SafelyProcessEvent(wxEvent&) ()
from bin/linux/x64/clibs/libwx.so
#34 0x00007ffff730c258 in wxWindow::GTKSendPaintEvents(_cairo*) ()
from bin/linux/x64/clibs/libwx.so
#35 0x00007ffff730c452 in ?? () from bin/linux/x64/clibs/libwx.so
#36 0x00007ffff5a7ec8c in ?? () from /usr/lib64/libgtk-3.so.0
#37 0x00007ffff5bc11ff in ?? () from /usr/lib64/libgtk-3.so.0
#38 0x00007ffff497ce8d in g_closure_invoke ()
from /usr/lib64/libgobject-2.0.so.0
#39 0x00007ffff4990555 in ?? () from /usr/lib64/libgobject-2.0.so.0
#40 0x00007ffff4998b9b in g_signal_emit_valist ()
from /usr/lib64/libgobject-2.0.so.0
#41 0x00007ffff4999b6f in g_signal_emit () from
/usr/lib64/libgobject-2.0.so.0
#42 0x00007ffff5bcdafa in ?? () from /usr/lib64/libgtk-3.so.0
#43 0x00007ffff59bca52 in gtk_container_propagate_draw ()
from /usr/lib64/libgtk-3.so.0
#44 0x00007ffff59bcb32 in ?? () from /usr/lib64/libgtk-3.so.0
#45 0x00007ffff5b0417b in ?? () from /usr/lib64/libgtk-3.so.0
#46 0x00007ffff59c199d in ?? () from /usr/lib64/libgtk-3.so.0
#47 0x00007ffff59c6668 in ?? () from /usr/lib64/libgtk-3.so.0
#48 0x00007ffff5b026d1 in ?? () from /usr/lib64/libgtk-3.so.0
#49 0x00007ffff5bcd8df in ?? () from /usr/lib64/libgtk-3.so.0
#50 0x00007ffff59bca52 in gtk_container_propagate_draw ()
from /usr/lib64/libgtk-3.so.0
#51 0x00007ffff5a260a1 in ?? () from /usr/lib64/libgtk-3.so.0
#52 0x00007ffff5a7ec8c in ?? () from /usr/lib64/libgtk-3.so.0
#53 0x00007ffff5bc11ff in ?? () from /usr/lib64/libgtk-3.so.0
#54 0x00007ffff497cda1 in g_closure_invoke ()
from /usr/lib64/libgobject-2.0.so.0
#55 0x00007ffff498fdad in ?? () from /usr/lib64/libgobject-2.0.so.0
#56 0x00007ffff4998b9b in g_signal_emit_valist ()
from /usr/lib64/libgobject-2.0.so.0
#57 0x00007ffff4999b6f in g_signal_emit () from
/usr/lib64/libgobject-2.0.so.0
#58 0x00007ffff5bcdafa in ?? () from /usr/lib64/libgtk-3.so.0
#59 0x00007ffff59bca52 in gtk_container_propagate_draw ()
from /usr/lib64/libgtk-3.so.0
#60 0x00007ffff5a260a1 in ?? () from /usr/lib64/libgtk-3.so.0
#61 0x00007ffff5a7ec8c in ?? () from /usr/lib64/libgtk-3.so.0
#62 0x00007ffff5bc11ff in ?? () from /usr/lib64/libgtk-3.so.0
#63 0x00007ffff497ce8d in g_closure_invoke ()
from /usr/lib64/libgobject-2.0.so.0
#64 0x00007ffff498fdad in ?? () from /usr/lib64/libgobject-2.0.so.0
#65 0x00007ffff4998b9b in g_signal_emit_valist ()
from /usr/lib64/libgobject-2.0.so.0
#66 0x00007ffff4999b6f in g_signal_emit () from
/usr/lib64/libgobject-2.0.so.0
#67 0x00007ffff5bcdafa in ?? () from /usr/lib64/libgtk-3.so.0
#68 0x00007ffff59bca52 in gtk_container_propagate_draw ()
from /usr/lib64/libgtk-3.so.0
#69 0x00007ffff59bcb32 in ?? () from /usr/lib64/libgtk-3.so.0
#70 0x00007ffff5970e24 in ?? () from /usr/lib64/libgtk-3.so.0
#71 0x00007ffff59c199d in ?? () from /usr/lib64/libgtk-3.so.0
#72 0x00007ffff59c6668 in ?? () from /usr/lib64/libgtk-3.so.0
#73 0x00007ffff5973801 in ?? () from /usr/lib64/libgtk-3.so.0
#74 0x00007ffff5bcd8df in ?? () from /usr/lib64/libgtk-3.so.0
#75 0x00007ffff59bca52 in gtk_container_propagate_draw ()
from /usr/lib64/libgtk-3.so.0
#76 0x00007ffff59bcb32 in ?? () from /usr/lib64/libgtk-3.so.0
#77 0x00007ffff5bdb289 in ?? () from /usr/lib64/libgtk-3.so.0
#78 0x00007ffff5bcd8df in ?? () from /usr/lib64/libgtk-3.so.0
#79 0x00007ffff5bd6a43 in ?? () from /usr/lib64/libgtk-3.so.0
#80 0x00007ffff5a7dcef in gtk_main_do_event () from /usr/lib64/libgtk-3.so.0
#81 0x00007ffff5598375 in ?? () from /usr/lib64/libgdk-3.so.0
#82 0x00007ffff55c8972 in ?? () from /usr/lib64/libgdk-3.so.0
#83 0x00007ffff48976ee in g_main_context_dispatch ()
from /lib64/libglib-2.0.so.0
#84 0x00007ffff4897988 in ?? () from /lib64/libglib-2.0.so.0
#85 0x00007ffff4897c82 in g_main_loop_run () from /lib64/libglib-2.0.so.0
#86 0x00007ffff5a7d035 in gtk_main () from /usr/lib64/libgtk-3.so.0
#87 0x00007ffff72f8192 in wxGUIEventLoop::DoRun() ()
from bin/linux/x64/clibs/libwx.so
#88 0x00007ffff746d2ed in wxEventLoopBase::Run() ()
from bin/linux/x64/clibs/libwx.so
#89 0x00007ffff745644c in wxAppConsoleBase::MainLoop() ()
from bin/linux/x64/clibs/libwx.so
#90 0x00007ffff721f6c1 in ?? () from bin/linux/x64/clibs/libwx.so
#91 0x000000000042ba29 in ?? ()
#92 0x0000000000410102 in lua_pcall ()
#93 0x0000000000403b8a in _start ()
|
Thank you for diving deep into this issue.
You mentioned you tried Ubuntu. In case you want to test on ALTLinux (my
case) you can get Live CD and test in it. Get a flavor you like at
https://www.altlinux.org/Regular
Thanks again.
|
@ildar, this seems to be a GTK3 issue and may be version-specific. I see multiple reports from various applications, so it's likely doesn't have anything to do with wxlua or ZBS. As I see diff --git a/src/editor/editor.lua b/src/editor/editor.lua
index 6b4cac4f..7ac09a39 100644
--- a/src/editor/editor.lua
+++ b/src/editor/editor.lua
@@ -1242,7 +1242,7 @@ function CreateEditor(bare)
function (event)
PackageEventHandle("onEditorPainted", editor, event)
- if ide.osname == 'Windows' then
+ if ide.osname == 'Windows' or ide.osname == 'Unix' then
-- STC_PAINTED is called on multiple editors when they point to
-- the same document; only update status for the active one
if notebook:GetSelection() == notebook:GetPageIndex(editor) then
@@ -1288,7 +1288,7 @@ function CreateEditor(bare)
PackageEventHandle("onEditorUpdateUI", editor, event)
- if ide.osname ~= 'Windows' then updateStatusText(editor) end
+ if ide.osname ~= 'Windows' and ide.osname ~= 'Unix' then updateStatusText(editor) end
editor:GotoPosDelayed()
updateBraceMatch(editor) |
BTW, what's the GTK version on your machine and what does |
Paul, as i wrote before,
$ rpm -q glibc libgtk+3
glibc-2.27-alt8.x86_64
libgtk+3-3.24.11-alt1.x86_64
It is x86_64 Intel Xeon notebook from Dell.
|
The proposed patch didn't help BTW.
|
Your earlier message reported a slightly older GTK version.
That's too bad, as I don't have any other suggestion short of not using the middle button to paste the text ;(. Not sure what else can be done assuming this is indeed a GTK issue, which is what it looks like. You can try upgrading to a newer version of GTK if there is one or rebuilding using GTK2, which doesn't seem to suffer from this issue. |
That's ok. Thanks a lot.
I still want to try wx examples a bit later as it takes a little more
compiler exercises.
|
@ildar, one more suggestion to try. Can you see if you can crash this minimal sample: require "wx"
local frame = wx.wxFrame(wx.NULL, wx.wxID_ANY, "STC Demo",
wx.wxDefaultPosition, wx.wxSize(450, 450), wx.wxDEFAULT_FRAME_STYLE )
local e = wxstc.wxStyledTextCtrl(frame, wx.wxID_ANY,
wx.wxDefaultPosition, wx.wxSize(0, 0), wx.wxBORDER_STATIC)
e:SetLexer(wxstc.wxSTC_LEX_LUA)
e:SetProperty("fold", "1")
frame:Show(true)
wx.wxGetApp():MainLoop() |
Paul,
I could not make it crash 🤔 whilst zbs crashes reliably
|
@ildar, interesting. Then you can try two things to see if you can get any of the two to crash: (1) test the following example: https://github.com/pkulchenko/wxlua/blob/master/wxLua/samples/editor.wx.lua diff --git a/src/editor/editor.lua b/src/editor/editor.lua
index 6b4cac4f..ebd15170 100644
--- a/src/editor/editor.lua
+++ b/src/editor/editor.lua
@@ -1240,6 +1240,7 @@ function CreateEditor(bare)
-- where refresh of R/W and R/O status in the status bar is delayed.
editor:Connect(wxstc.wxEVT_STC_PAINTED,
function (event)
+ do return end
PackageEventHandle("onEditorPainted", editor, event)
if ide.osname == 'Windows' then
@@ -1270,6 +1271,7 @@ function CreateEditor(bare)
editor.processedUpdateContent = 0
editor:Connect(wxstc.wxEVT_STC_UPDATEUI,
function (event)
+ do return end
-- some of UPDATEUI events may be triggered as the result of editor updates
-- from subsequent events (like PAINTED, which happens in documentmap plugin).
-- the reason for the `processed` check is that it is not possible |
(1) crashed immediately
(2) I couldn't crash this. Yahoo, we have a workaround here!
|
That's good; now let's figure out which one of the handlers is causing it. Can you comment one-by-one to see if this is UPDATEUI or PAINTED? I suspect it is UPDATEUI and if it is, can you comment out If it works, then try the following patch: diff --git a/src/editor/editor.lua b/src/editor/editor.lua
index 57ae5f82..29da2cfb 100644
--- a/src/editor/editor.lua
+++ b/src/editor/editor.lua
@@ -1288,7 +1288,13 @@ function CreateEditor(bare)
PackageEventHandle("onEditorUpdateUI", editor, event)
- if ide.osname ~= 'Windows' then updateStatusText(editor) end
+ if ide.osname ~= 'Windows' then
+ if ide.osname == "Unix" then
+ editor:DoWhenIdle(function() updateStatusText(editor) end)
+ else
+ updateStatusText(editor)
+ end
+ end If it doesn't work (you can still crash it after commenting out line with |
@ildar, this is a more complete patch: diff --git a/src/editor/editor.lua b/src/editor/editor.lua
index 57ae5f82..6fba4822 100644
--- a/src/editor/editor.lua
+++ b/src/editor/editor.lua
@@ -1238,17 +1238,17 @@ function CreateEditor(bare)
-- brackets or backspace is used (very slow screen repaint with 0.5s delay).
-- Moving it to PAINTED event creates problems on OSX (using wx2.9.5+),
-- where refresh of R/W and R/O status in the status bar is delayed.
+ -- PAINTED is better, as it allows to track INS vs OVR and R/O vs R/W status.
editor:Connect(wxstc.wxEVT_STC_PAINTED,
function (event)
PackageEventHandle("onEditorPainted", editor, event)
- if ide.osname == 'Windows' then
- -- STC_PAINTED is called on multiple editors when they point to
- -- the same document; only update status for the active one
- if notebook:GetSelection() == notebook:GetPageIndex(editor) then
- updateStatusText(editor)
- end
+ local doc = ide:GetDocument(editor)
+ if doc and doc:IsActive() then
+ editor:DoWhenIdle(function() updateStatusText(editor) end)
+ end
+ if ide.osname == 'Windows' then
if edcfg.usewrap ~= true and editor:AutoCompActive() then
-- showing auto-complete list leaves artifacts on the screen,
-- which can only be fixed by a forced refresh.
@@ -1288,8 +1288,6 @@ function CreateEditor(bare)
PackageEventHandle("onEditorUpdateUI", editor, event)
- if ide.osname ~= 'Windows' then updateStatusText(editor) end
-
editor:GotoPosDelayed()
updateBraceMatch(editor)
local minupdated I still need to test it on macOS, but it works as expected in all scenarios on Windows, so I'd be interested if you run into any problems with it on Linux. Thanks. |
1st things first: masking wxstc.wxEVT_STC_UPDATEUI is enough. And, yes,
just removing `updateStatusText(editor)` works fine.
2nd, the last patch with moving `updateStatusText` call worked fine too.
Thank you so much! Please write if I can do anything else for this case.
|
Sounds good. The changes also look good on macOS, so I'll be merging them into the upgrade branch shortly. The issue still appears to be with wxwidgets somewhere, but at least there is a workaround for it. |
…kulchenko/wxlua#5). This also fixed R/O vs R/W status update on macOS.
…kulchenko/wxlua#5). This also fixed R/O vs R/W status update on macOS.
…kulchenko/wxlua#5). This also fixed R/O vs R/W status update on macOS.
…kulchenko/wxlua#5). This also fixed R/O vs R/W status update on macOS.
…kulchenko/wxlua#5). This also fixed R/O vs R/W status update on macOS.
…kulchenko/wxlua#5). This also fixed R/O vs R/W status update on macOS.
@ildar, FWIW, there was a very similar wxwidgets issue that was fixed for Windows (https://trac.wxwidgets.org/ticket/18451); I suspect it could have affected Linux as well causing the problem you saw. |
Actually not just on "Run wxLua program" but maybe earlier.
Could you please check? This is the git HEAD built against wxGTK git HEAD (GTK+3).
The text was updated successfully, but these errors were encountered: