crashes with version 2020.1-135-g78752b2

[marilmanen]

Unfortunately it's me again. I have started getting daily crashes (yesterday and today), but I have not yet figured out what triggers the crash. I have removed some of the files that are open in nedit-ng, so maybe there's still something wrong in that area.... This crash happened when I tried to run a macro.

#0  0x00002ae97806f22c in QtSharedPointer::ExternalRefCountData::getAndRef(QObject const*) () at /lib64/libQt5Core.so.5
#1  0x00002ae9775ee44c in QWidgetWindow::handleMouseEvent(QMouseEvent*) () at /lib64/libQt5Widgets.so.5
#2  0x00002ae9775f0d65 in QWidgetWindow::event(QEvent*) () at /lib64/libQt5Widgets.so.5
#3  0x00002ae977596d8c in QApplicationPrivate::notify_helper(QObject*, QEvent*) () at /lib64/libQt5Widgets.so.5
#4  0x00002ae97759df68 in QApplication::notify(QObject*, QEvent*) () at /lib64/libQt5Widgets.so.5
#5  0x00002ae9781afbe6 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () at /lib64/libQt5Core.so.5
#6  0x00002ae977ba51ed in QGuiApplicationPrivate::processMouseEvent(QWindowSystemInterfacePrivate::MouseEvent*) () at /lib64/libQt5Gui.so.5
#7  0x00002ae977ba6f25 in QGuiApplicationPrivate::processWindowSystemEvent(QWindowSystemInterfacePrivate::WindowSystemEvent*) () at /lib64/libQt5Gui.so.5
#8  0x00002ae977b848db in QWindowSystemInterface::sendWindowSystemEvents(QFlags<QEventLoop::ProcessEventsFlag>) () at /lib64/libQt5Gui.so.5
#9  0x00002ae9805d2950 in userEventSourceDispatch(_GSource*, int (*)(void*), void*) () at /lib64/libQt5XcbQpa.so.5
#10 0x00002ae97cab8099 in g_main_context_dispatch () at /lib64/libglib-2.0.so.0
#11 0x00002ae97cab83f8 in g_main_context_iterate.isra.19 () at /lib64/libglib-2.0.so.0
#12 0x00002ae97cab84ac in g_main_context_iteration () at /lib64/libglib-2.0.so.0
#13 0x00002ae9781fe45c in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () at /lib64/libQt5Core.so.5
#14 0x00002ae9781ae6db in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () at /lib64/libQt5Core.so.5
#15 0x00002ae97771527d in QMenu::exec(QPoint const&, QAction*) () at /lib64/libQt5Widgets.so.5
#16 0x00002ae9781d8273 in QMetaObject::activate(QObject*, int, int, void**) () at /lib64/libQt5Core.so.5
#17 0x00002ae9775bb7f5 in QWidget::customContextMenuRequested(QPoint const&) () at /lib64/libQt5Widgets.so.5
#18 0x0000000000586d49 in TextArea::contextMenuEvent(QContextMenuEvent*) (this=0x1d982c0, event=<optimized out>)
    at /tools/ext/free/downloads/nedit-ng/src/TextArea.cpp:1100
#19 0x00002ae9775d553e in QWidget::event(QEvent*) () at /lib64/libQt5Widgets.so.5
#20 0x00002ae97767b70e in QFrame::event(QEvent*) () at /lib64/libQt5Widgets.so.5
#21 0x00002ae9781af9dd in QCoreApplicationPrivate::sendThroughObjectEventFilters(QObject*, QEvent*) () at /lib64/libQt5Core.so.5
#22 0x00002ae977596d65 in QApplicationPrivate::notify_helper(QObject*, QEvent*) () at /lib64/libQt5Widgets.so.5
#23 0x00002ae97759f42a in QApplication::notify(QObject*, QEvent*) () at /lib64/libQt5Widgets.so.5
#24 0x00002ae9781afbe6 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () at /lib64/libQt5Core.so.5
#25 0x00002ae9775ee87d in QWidgetWindow::handleMouseEvent(QMouseEvent*) () at /lib64/libQt5Widgets.so.5
#26 0x00002ae9775f0d65 in QWidgetWindow::event(QEvent*) () at /lib64/libQt5Widgets.so.5
#27 0x00002ae977596d8c in QApplicationPrivate::notify_helper(QObject*, QEvent*) () at /lib64/libQt5Widgets.so.5
#28 0x00002ae97759df68 in QApplication::notify(QObject*, QEvent*) () at /lib64/libQt5Widgets.so.5
#29 0x00002ae9781afbe6 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () at /lib64/libQt5Core.so.5
#30 0x00002ae977ba51ed in QGuiApplicationPrivate::processMouseEvent(QWindowSystemInterfacePrivate::MouseEvent*) () at /lib64/libQt5Gui.so.5
#31 0x00002ae977ba6f25 in QGuiApplicationPrivate::processWindowSystemEvent(QWindowSystemInterfacePrivate::WindowSystemEvent*) () at /lib64/libQt5Gui.so.5
#32 0x00002ae977b848db in QWindowSystemInterface::sendWindowSystemEvents(QFlags<QEventLoop::ProcessEventsFlag>) () at /lib64/libQt5Gui.so.5
#33 0x00002ae9805d2950 in userEventSourceDispatch(_GSource*, int (*)(void*), void*) () at /lib64/libQt5XcbQpa.so.5
#34 0x00002ae97cab8099 in g_main_context_dispatch () at /lib64/libglib-2.0.so.0
#35 0x00002ae97cab83f8 in g_main_context_iterate.isra.19 () at /lib64/libglib-2.0.so.0
#36 0x00002ae97cab84ac in g_main_context_iteration () at /lib64/libglib-2.0.so.0
#37 0x00002ae9781fe45c in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () at /lib64/libQt5Core.so.5
#38 0x00002ae9781ae6db in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () at /lib64/libQt5Core.so.5
#39 0x00002ae9781b6c04 in QCoreApplication::exec() () at /lib64/libQt5Core.so.5
#40 0x00000000004978c2 in main(int, char**) (argc=<optimized out>, argv=<optimized out>) at /tools/ext/free/downloads/nedit-ng/src/nedit.cpp:149

[marilmanen]

I created empty files f1, f2 and f3 and added a macro containing just command open("f2"), Then I did random modifications to f1 and f3, added there also text f2 and started closing f2 and opening it with the macro and sometimes by selecting the "f2" text in the f1 file and pressing Ctrl+Y. After couple iterations nedit will always crash.

[marilmanen]

I forgot to mention that I have also tested version 2020.1-136-gb8e63d4 and the issue exists also with that version

[eteran]

Hmm, seems to involve a context menu, will investigate!

[eteran]

@marilmanen Can you send me your .config directory tarred up, I have a feeling this is triggered by settings and custom menus

[marilmanen]

@eteran I sent my settings to your gmail address

[eteran]

@marilmanen thanks!

I'll check it out and let you know what I discover. It's probably something stupid, :-P.

[eteran]

@marilmanen so... so far, I have been hammering your example with your settings. I made a few macros for opening files "f1", "f2", and "f3". Connected them to some keyboard shortcuts and have been rapid-fire opening and closing these files...

So far, no crash :-(.

I've done random edits, saved, closed, re-opened. edits, no-save, close, re-open every combination I can think of.

If there's anything else you can think of which triggers the issue somewhat reliably, of course, let me know. I'm going to be throwing a buynch of linters and sanitizers at the code to see what falls out. Based on your stack trace, I have a feeling WHERE it is... just not WHAT it is.

But we'll get to the bottom of it!

[marilmanen]

I manage to get it crashing, but I'm not able to figure out just how..... I do have a feeling that the it helps to get the crash if the open("f2") macro is executed more than one times in a row and it does crash only by using the open("f2") macro, select tab f2 or f3 and closing f2 tab. No need to have any content on any of the files and the tab f1 does not seem to play any role.

[eteran]

@marilmanen I know you are a heavy nc user. I just fixed two major bugs regarding that, which MAY affect this (maybe).

basically, I made -wait work, LOL. It was accidentally timing out after 30 seconds and I fixed a pretty bad bug regarding using nc to launch nedit-ng where it would put things in a state that could crash on some operations. The second one has the best chance of being the fix for this issue... but we'll see.

Initially, when I was testing, I was just running nedit-ng directly, but then I remembered that you use the server mode and started testing there and found some crashes, but they were different than what you reported... Maybe.

[eteran]

Gah, I just realized that the startDetached function that I pretty much need is only available in Qt 5.10 a newer. So either I need to raise the requirements or hack around it.

[eteran]

Nvm, I lucked out. The variant of the function I used became available in 5.5 :-) According to this:

https://doc.qt.io/archives/qt-5.5/qprocess.html#startDetached

[marilmanen]

Hmm, some new issue now, I can't start nedit anymore with my "mystery" command

nc-ng -svrname u_837 -svrcmd 'sc ng -server' -noask

[eteran]

Hmm, assuming sc will launch nedit-ng, I would expect it to work.

Does it work if you have it run nedit more directly? Is it only an issue when sc is in the command?

[marilmanen]

Looks like there's some issue related with the wrapper I'm using and after a quick look at the wrapper I'm not sure it's needed anymore. I need to check why I'm still using the wrapper.

[marilmanen]

OK, I definitely have some old nedit related strange ways to start the editor, but I have been trying to understand what's going on and just can't figure out what. Can you explain? Create executable /tmp/wrap script with content

eval 'exec perl -wS $0 ${1+"$@"}'
    if 0;
exec "perl /tmp/wrap.pl";

The /tmp/wrap.pl content is

system "nedit-ng -server &";

and finally the command line for starting nedit

nc-ng -svrname u_837 -svrcmd '/tmp/wrap -server' -noask

With version 2020.1-136-gb8e63d4 everything works fine, but with 020.1-139-g59eab07 I get nc-ng: The server process failed to start. Either the invoked program is missing, or you may have insufficient permissions to invoke the program.

[eteran]

Thanks for the example wrapper. I'll take a look at what's going on.

I am GUESSING that the issue is the ampersand backgrounding the execution because that causes the script to run nedit in the BG and then exit.

And I am also guessing, that Qts startdetached isn't given enough time to notice that it started based on it exiting so fast.

But I still need to test things out.

[marilmanen]

I have removed the extra complexity from my startup script as I found no need for the -svrcmd option anymore. In the old nedit I used the -svrcmd to add common .nedit setup with the -import option on top of user settings, but now all settings are aligned in the .config directory by my wrapper script (that's the config_user.ini). This is how I should have done it in the previous millennia with the old nedit.

[eteran]

@marilmanen did that script ever work with NG? I see that it works with classic nedit, but even when I try it with 2020.1, I get a failure to start the script.

Is it supposed to have a perl shebang in it?

[eteran]

Yea, I dunno what the story is with the eval, exec perl stuff, I can't get that to work with any version of NG I've tried (does with with NEdit-5... so that's interesting).

However, if I changed your script to be one file and simply read:

#!/bin/env perl
system "nedit-ng -server &"

Then it works as expected. However, I can say that the script, doesn't seem to be doing very much. I assume you normally have something like: nedit-ng -server -import $HOME/.config/nedit-ng/config_user.ini in there? And you certainly don't need the &

[anjohnson]

@eteran That change to client/nc.cpp in commit 59eab07f3bece appears to have fixed some problems I've been having for ages with it not opening multiple files properly! It's still not perfect, but when nc-ng starts the server at least it now opens all the files on that command-line as tabs in the same window (previously I might get one Untitled window and a mixture of windows with one or more tabs in them). If the server is already running it now seems to always open each file in a new window though.

[eteran]

Thanks for the update. So you get one file per window? Interesting...

I'll have to test that a bit more, I hope now that things are executing correctly that it'll be an easier fix 🙂

[anjohnson]

That was on macOS; on Linux running nc-ng with a list of several files to start the server just opened a single Untitled window, but a subsequent run with that server running opened all the files as tabs in that window, so the behavior is definitely OS-specific.

[eteran]

So weird...

I can say that the "single Untitled but not the requested file" sounds like it started NG, but failed to connect to the server for some reason. I'll try to debug that situation.

But I just tried both the not already running and already running scenarios and I got the expected behavior of a single nedit window with all files open, no untitled every time.

Being both OS and seemingly desktop specific reaks of "race condition", so I'll see what I can do.

The odd thing is when you specify multiple files, it gets sent a single message to the server. So there's no real reason why it should end up in multiple windows as far as I can tell. It should be no different than just opening files via the UI in rapid succession.

But, I am glad that a bunch of the quirks are ... better :-P. I'll continue to investigate!

[anjohnson]

I was connecting to Linux remotely via NoMachine (NX) so that might be slowing down some of the X11 interactions, although I'm not certain of that since it's sending updates of my whole desktop asynchronously. My Linux box is faster than this Mac with lots of idle CPUs though, so it might have more to do with that. HTH, got to get back to work.

[eteran]

@anjohnson every little bit helps. I just pushed a minor set of tweaks which do a few things

1. Displays a message informing you if nc failed to connect to the server.
2. Make the various timeouts a little more clear for testing
3. Increased the connection timeout by 100%

So... when you get a chance it would be very helpful to test 2 things for me :-)

First, is the current server start timeout big enough? In other words, do you no longer get a single-window with just untitled? Or do you get that (now with a message on the command line saying that it couldn't connect).

Secondly, if you are still getting a failure to connect, can you try changing a single variable and seeing if it helps?

In client/nc.cpp there is now a pretty easy to identify line that read:

constexpr int RetryCount = 20; 

That 20 equates to roughly 2.5 seconds. If you are still getting failures to connect, try larger numbers, please! I think values as high as about 200 (about 25 seconds) MAY be reasonable... maybe. But I don't want to overdo it either.

let me know what you find :-)

[marilmanen]

@eteran I found a very simple way to get the crash with 2020.1-140-g5a64da5.

mkdir -p /tmp/nedit/atc
mkdir -p /tmp/nedit/rtl
touch /tmp/nedit/atc/foo
touch /tmp/nedit/rtl/foo.vhdl
nc-ng /tmp/nedit/rtl/foo.vhdl
Macro/sc/atc/controlfile

[eteran]

Thanks!, lemme see if I can replicate :-)

[eteran]

@marilmanen Unfortunately, so far, I can't reproduce it locally. This is a fresh build. Tried in both Release and Debug builds.

https://user-images.githubusercontent.com/571477/103732181-e20ad380-4fb4-11eb-8981-9e4f72662c67.mp4

I do have a question though based on the stack trace you shared above, it looks like the issue is SOMEHOW related to context menus.

So there's two things I'm wondering if doing the following has any effect for you:

In src/MainWindow.cpp, lines 1468-1500 there is the following:

    // update background menu, which is owned by a single document
    delete document->contextMenu_;
    document->contextMenu_ = createUserMenu(language, BGMenuData, CommandTypes::Context);

    // handler for BG menu scripts
    connect(document->contextMenu_, &QMenu::triggered, this, [this](QAction *action) {
        QVariant data = action->data();
        if (!data.isNull()) {

            /* Don't allow users to execute a macro command from the menu (or accel)
               if there's already a macro command executing, UNLESS the macro is
               directly called from another one.  NEdit can't handle
               running multiple, independent uncoordinated, macros in the same
               window.  Macros may invoke macro menu commands recursively via the
               macro_menu_command action proc, which is important for being able to
               repeat any operation, and to embed macros within eachother at any
               level, however, a call here with a macro running means that THE USER
               is explicitly invoking another macro via the menu or an accelerator,
               UNLESS the macro event marker is set */
            if (DocumentWidget *document = currentDocument()) {
                if (document->macroCmdData_) {
                    QApplication::beep();
                    return;
                }

                const auto index   = data.toUInt();
                const QString name = BGMenuData[index].item.name;
                if (QPointer<TextArea> area = lastFocus()) {
                    execNamedBGMenuCmd(document, area, name, CommandSource::User);
                }
            }
        }
    });

What happens if you comment that out? Does it fix the crash?

[anjohnson]

I just built 5a64da51a862a on MacOS. Starting a server with nc-ng and a couple of files and it worked as expected. I used nc-ng to open one more file and it opened it instantly, but it its own window, not as a separate tab (I have the preference Tabbed Editing -> Open File in New Tab checked, and things like File -> Open and Cmd+Y do that properly).

Then I quit that server and ran nc-ng again with a list of 66 filenames:

woz$ time nc-ng *.c *.h

real    0m0.767s
user    0m0.021s
sys 0m0.020s

Subjectively, most of that time it appeared to do nothing; a single Untitled window opened maybe 3/4 of the way through so probably at or just after the 0.5 second mark. No files were opened, no errors or messages. I haven't tried increasing those timeouts since it isn't taking that long.

Next I timed nc-ng starting a server with no files, then ran it again (twice) with that list of 66 files:

woz$ time nc-ng

real    0m0.680s
user    0m0.019s
sys 0m0.018s
woz$ time nc-ng *.c *.h

real    0m0.038s
user    0m0.020s
sys 0m0.014s
woz$ time nc-ng *.c *.h

real    0m0.041s
user    0m0.020s
sys 0m0.014s

Neither of those requests caused it to open any files. However on giving it a shorter list of only 28 files nc-ng returned in about the same time and I got 28 new windows with the requested files in them:

woz$ time nc-ng *.c

real    0m0.036s
user    0m0.017s
sys 0m0.013s

I guess I should have been doing that in the nedit-nc tree so you could try to replicate it...

Hmm, it seems to be related to the number of files requested; in the nedit-ng/src directory if I run nc-ng *.h I just get Untitled, but nc-ng *.ui opens all of them, in separate windows.

Hopefully this gives you some more clues, I don't think it's a timeout issue at all and I haven't seen any of your new error messages. I can try the same things on Linux tomorrow if you like, let me know.

[eteran]

OK, and just to be sure, this is after a make install meaning that it is definitely using the new code, right?

[anjohnson]

Yup, I checked that SHA against the one in the Help About window.

[marilmanen]

@eteran Unfortunately same crash with 2020.1-140-g5a64da5-dirty, so commenting out lines 1468-1500 didn't help

[eteran]

@anjohnson OK, I'm inspecting the code to see what I can spot. One question that comes to mind...

What do you see on the command line if you add the following line to src/NeditServer.cpp on line 230 (just above int lastIconic = 0;):

printf("NEdit: client request packet received:\n%s\n", jsonDocument.toJson().data());

?

You should see a pretty large JSON array, with an entry for each file you asked to open along with a bunch of flags.

(WARNING, it will have the full paths of files, if you don't want them public, feel free to email directly to me at evan.teran@gmail.com).

[eteran]

@eteran Unfortunately same crash with 2020.1-140-g5a64da5-dirty, so commenting out lines 1468-1500 didn't help

And you got the same stack trace that has this in the middle?

#17 0x00002ae9775bb7f5 in QWidget::customContextMenuRequested(QPoint const&) () at /lib64/libQt5Widgets.so.5
#18 0x0000000000586d49 in TextArea::contextMenuEvent(QContextMenuEvent*) (this=0x1d982c0, event=<optimized out>)
    at /tools/ext/free/downloads/nedit-ng/src/TextArea.cpp:1100

[eteran]

@marilmanen OK, if so, I have another thing to test by commenting out :-P.

What if you comment out lines 710-714 of src/DocumentWidget.cpp?

    connect(area, &TextArea::customContextMenuRequested, this, [this](const QPoint &pos) {
        if (contextMenu_) {
            contextMenu_->exec(pos);
        }
    });

[marilmanen]

@eteran I commented out also the lines 710-714 and now it seems to crash about 8 times out of 10 trials. Previously it crashed each time I tried, but the amount of trials was the not big enough for any real statistics.

[eteran]

@marilmanen

OK, that's super strange because with those lines commented, there is essentially no more connection to any changes introduced in 2020.1-135-g78752b2.

if you are using a debug build, can you share stack traces? Are they the same as the first one you shared?

[marilmanen]

@eteran I managed to get the crash also in my personal Ubuntu laptop with the latest code. It does not happen each time I try, but it does happens about every second time. I have tested with the lates code and with the out commented lines.

[marilmanen]

@eteran Here is the stack trace

#0  0x00007f8d975d64d0 in ?? () from /lib/x86_64-linux-gnu/libQt5Widgets.so.5
#1  0x00007f8d975d74d2 in QMenu::mouseReleaseEvent(QMouseEvent*) () from /lib/x86_64-linux-gnu/libQt5Widgets.so.5
#2  0x00007f8d9748f2b6 in QWidget::event(QEvent*) () from /lib/x86_64-linux-gnu/libQt5Widgets.so.5
#3  0x00007f8d975d9adb in QMenu::event(QEvent*) () from /lib/x86_64-linux-gnu/libQt5Widgets.so.5
#4  0x00007f8d9744ca66 in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /lib/x86_64-linux-gnu/libQt5Widgets.so.5
#5  0x00007f8d97456343 in QApplication::notify(QObject*, QEvent*) () from /lib/x86_64-linux-gnu/libQt5Widgets.so.5
#6  0x00007f8d96a3493a in QCoreApplication::notifyInternal2(QObject*, QEvent*) () from /lib/x86_64-linux-gnu/libQt5Core.so.5
#7  0x00007f8d97455457 in QApplicationPrivate::sendMouseEvent(QWidget*, QMouseEvent*, QWidget*, QWidget*, QWidget**, QPointer<QWidget>&, bool, bool) ()
   from /lib/x86_64-linux-gnu/libQt5Widgets.so.5
#8  0x00007f8d974abce4 in ?? () from /lib/x86_64-linux-gnu/libQt5Widgets.so.5
#9  0x00007f8d974ae1ec in ?? () from /lib/x86_64-linux-gnu/libQt5Widgets.so.5
#10 0x00007f8d9744ca66 in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /lib/x86_64-linux-gnu/libQt5Widgets.so.5
#11 0x00007f8d974560f0 in QApplication::notify(QObject*, QEvent*) () from /lib/x86_64-linux-gnu/libQt5Widgets.so.5
#12 0x00007f8d96a3493a in QCoreApplication::notifyInternal2(QObject*, QEvent*) () from /lib/x86_64-linux-gnu/libQt5Core.so.5
#13 0x00007f8d96e1d7d3 in QGuiApplicationPrivate::processMouseEvent(QWindowSystemInterfacePrivate::MouseEvent*) () from /lib/x86_64-linux-gnu/libQt5Gui.so.5
#14 0x00007f8d96e1f10b in QGuiApplicationPrivate::processWindowSystemEvent(QWindowSystemInterfacePrivate::WindowSystemEvent*) () from /lib/x86_64-linux-gnu/libQt5Gui.so.5
#15 0x00007f8d96df935b in QWindowSystemInterface::sendWindowSystemEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /lib/x86_64-linux-gnu/libQt5Gui.so.5
#16 0x00007f8d92f7932e in ?? () from /lib/x86_64-linux-gnu/libQt5XcbQpa.so.5
#17 0x00007f8d95a0bfbd in g_main_context_dispatch () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#18 0x00007f8d95a0c240 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#19 0x00007f8d95a0c2e3 in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#20 0x00007f8d96a8c565 in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /lib/x86_64-linux-gnu/libQt5Core.so.5
#21 0x00007f8d96a334db in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /lib/x86_64-linux-gnu/libQt5Core.so.5
#22 0x00007f8d96a3b246 in QCoreApplication::exec() () from /lib/x86_64-linux-gnu/libQt5Core.so.5
#23 0x00005585fa5864b5 in main (argc=<optimized out>, argv=<optimized out>) at /home/isi/src/nedit-ng/src/nedit.cpp:149

[eteran]

Ok, well I'll have to try it in an Ubuntu VM and see if that helps reproduce it.

What version of ubuntu do you use?

[marilmanen]

I'm using 20.04.1 with Xfce 4.14

[eteran]

Also, I assume you are triggering the macro via the main menu, not the context menu , Right?

I ask because while the stack traces are different, they both appear to involve mouse events in the callstack.

[marilmanen]

Yes, with the commented lines the main menu is the only available option. I also tested without mouse and the result is same.

[eteran]

Ok, last question for the night 😜.

Does your desktop do the ubuntu style unified menu thing?

I have a new theory as to what could cause the crash. Basically, I'm thinking that when a new document is opened, it can trigger a user menu recreation while IN the menu event handler. So we may be deleting the soon to be replaced menu a bit too soon.

It's just a theory, but I think it fits and would be an easy fix.

[marilmanen]

It's 11am here, so I'm just getting into speed. I'm not sure what a "ubuntu style unified menu thing" is, but I see the issue in Centos and Ubuntu, so I think it's Xfce related and I do use the "Window Buttons" panel.

[eteran]

@marilmanen the unified menu is the single meny at the top of the desktop for all applications, like on macOS. But you're right, maybe it's an Xfce thing. Now that I have details of your setup, I'll create a VM and see if I can reproduce with those things in place. If I can reproduce it, I can fix it :-P.

[anjohnson]

Interesting, makes some sense:

woz$ nc-ng src/NeditServer.cpp 
NEdit: client request packet received:
[
    {
        "create": 0,
        "geometry": "",
        "iconic": 0,
        "is_tabbed": -1,
        "langMode": "",
        "line_number": 0,
        "path": "/Users/anj/Software/other/nedit-ng/src/NeditServer.cpp",
        "read": 0,
        "toDoCommand": "",
        "wait": false
    }
]

woz$ nc-ng src/NeditServer.*
NEdit: client request packet received:
[
    {
        "create": 0,
        "geometry": "",
        "iconic": 0,
        "is_tabbed": -1,
        "langMode": "",
        "line_number": 0,
        "path": "/Users/anj/Software/other/nedit-ng/src/NeditServer.cpp",
        "read": 0,
        "toDoCommand": "",
        "wait": false
    },
    {
        "create": 0,
        "geometry": "",
        "iconic": 0,
        "is_tabbed": -1,
        "langMode": "",
        "line_number": 0,
        "path": "/Users/anj/Software/other/nedit-ng/src/NeditServer.h",
        "read": 0,
        "toDoCommand": "",
        "wait": false
    }
]

woz$ nc-ng src/*.h
woz$ 

The third time (src/*.h) I just got the Untitled window.

I also did nc-ng -debug-proto src/*.h and got back a long JSON string, here's a sample from the start and end:

[{"create":0,"geometry":"","iconic":0,"is_tabbed":-1,"langMode":"","line_number":0,"path":"/Users/anj/Software/other/nedit-ng/src/BlockDragTypes.h","read":0,"toDoCommand":"","wait":false},{"create":0,"geometry":"","iconic":0,"is_tabbed":-1,"langMode":"","line_number":0,"path":"/Users/anj/Software/other/nedit-ng/src/Bookmark.h","read":0,"toDoCommand":"","wait":false},

{"create":0,"geometry":"","iconic":0,"is_tabbed":-1,"langMode":"","line_number":0,"path":"/Users/anj/Software/other/nedit-ng/src/nedit.h","read":0,"toDoCommand":"","wait":false},{"create":0,"geometry":"","iconic":0,"is_tabbed":-1,"langMode":"","line_number":0,"path":"/Users/anj/Software/other/nedit-ng/src/shift.h","read":0,"toDoCommand":"","wait":false},{"create":0,"geometry":"","iconic":0,"is_tabbed":-1,"langMode":"","line_number":0,"path":"/Users/anj/Software/other/nedit-ng/src/userCmds.h","read":0,"toDoCommand":"","wait":false}]

BTW the nc-ng -version output could probably use the new Git version info too.

I also tried nc-ng -tabbed src/*.ui with a server already running; the files still all opened in their own window, the only difference is that I get "is_tabbed": 1, instead of "is_tabbed":-1, so the tab/window problem when a server is already running seems to be a server issue.

Sorry, we should probably have moved this to a different GitHub issue...

[eteran]

@anjohnson No worries! this is helpful :-).

I see two issues that you are experiencing:

1. when you for just the untitled window, you didn't get any JSON output. That means that for some reason, the message wasn't received at all. But you also didn't get any error message saying it failed to connect... So for some reason, the packet just disappeared... strange. I actually forgot about the --debug_proto flag, LOL. But what you showed looks about right. Need to find out why the packet gets dropped sometimes :-(

2. The second is that for some reason, the server isn't properly tabbing things (-1 means "use user preferences, 0 means window per doc, 1 means tab per doc). So in both cases, you SHOULD have gotten tabs, but for some reason, you didn't :-/.

[eteran]

EDIT: Don't worry about doing this test, I was able to replicate it locally. Thanks!

---

@anjohnson makes me wonder if you're running into this error:

QLocalSocket::DatagramTooLargeError

In which case, I'll have to break up the message into several to send it.

Can you try adding a debug line and testing the case where it opens nothing?

Try adding:

        printf("Socket Error State: %d\n", socket->error());
        printf("Socket Error String: %s\n", qPrintable(socket->errorString()));

on line 487 of client/nc.cpp, so it reads like this:

        socket->write(ba);
        socket->flush();
        socket->waitForBytesWritten(timeout.count());

        printf("Socket Error State: %d\n", socket->error());
        printf("Socket Error String: %s\n", qPrintable(socket->errorString()));

        // if we are enabling wait mode, we simply wait for the server
        // to close the socket. We'll leave it to the server to track
        // when everything is all done. Otherwise, just disconnect.
        if (ServerPreferences.waitForClose) {
            socket->waitForDisconnected(-1);
        } else {
            socket->disconnectFromServer();
        }

When things worked correctly, it should output:

Socket Error State: -1
Socket Error String: Unknown error

[eteran]

@anjohnson OK, I've been able to replicate the issue with "just untitled", for me I have to open a stupidly large number of files, but I can trigger it reliably.

Basically, it seems to an issue with the amount of data I'm allowed to send in the pipe. I'll see what can be done to stream it properly.