Geany-scope blank window, inusable

[IridiumXOR]

If you load geany scope, load a simple "Hello world" software written in C compiled with -g, and you start the execution with geany scope you obtain a blank window without text or buttons and geany freeze.. so geany scope is unusable...
geany scope 1.27 in Fedora 24 with italian language

reported in https://bugzilla.redhat.com/show_bug.cgi?id=1341107

[aztennenbaum]

I installed geany and geany-plugins from git on a fresh xubuntu 16.04 system, and found this same issue

When I try to debug, it instead hangs with geany using 100% cpu. It seems to get past the stage of actually loading gdb, and i have found that geany rarely responds to mouse clicks, and when I kill gdb, it goes back to functioning normally.

I have tried with geany 1.27 and had the same issue

here are the steps I have used to go from a fresh linux install to my current state:

sudo apt-get install git libvte-dev libtool
sudo apt-get install ctags gdb meld nemiver libwebkit-dev vim

git clone https://github.com/geany/geany
cd geany
./autogen.sh --disable-html-docs
make
sudo make install
cd ..

git clone https://github.com/geany/geany-plugins
cd geany-plugins
./autogen.sh --disable-html-docs
make
sudo make install

I then enable scope debugger, at which point the issue becomes apparent

[andreygursky]

The same with 1.29.

[lstandage135]

I had this same issue with the Scope Debugger v0.94 in Geany 1.27 on Ubuntu 16.04. However I was able to get other Debugger 'Various debuggers integration' v1.27 to work.

[kugel-]

I can confirm that scope simply doesn't work anymore. @zhekov can you assist?

[zhekov]

Scope is orphaned from more than a year now, and I don't even have a Linux system at home ATM... but if the issue is cross-platform, I'll try to fix it. What's the preffered way to build Geany under Win32 recently? Any msys64 support?

[andreygursky]

@zhekov, the packages from msys2/mingw-w64 (http://www.msys2.org/) https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-geany and https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-geany-plugins are up-to-date (1.29). (I'm on Debian)

[zhekov]

I'll have to patch these a bit for gtk+3. They are for +2, but the official Win32 binaries (also +2) seem to work without any problems. Or install a Slack, I was going to do that anyway...

[kugel-]

The problem is probably specific to Unix. The backtrace shows that glib hangs in read() (via g_io_read_chars(), via Geanys spawn API), even though gio signals readiness for the input. The input fd comes from openpty()

I wonder...if gio works properly with file descriptions that come openpty()?

[zhekov]

@kugel- Thanks.

The only spawn() call launches gdb, and the only call to openpty() is when creating the "program terminal": a VTE widget that serves as a console for the program being debugged under *nix.

The widget is created on scope startup, but the terminal is not used until gdb is launched. Shortly after that, it's passed to gdb via "-gdb-set inferior-tty <tty-name>".

It may be that the procedure to setup VTE has changed. It was changed in 0.25, and there were problems with the VTE pty before (conterm.c:/pty_master/).

[zhekov]

I checked the VTE API documentation.

In version 0.26 (or even earlier?), the function "vte_pty_child_setup()" appears. It's documented as "FIXMEchpe", but the documentation for vte_pty_new() says "you MUST call it before using fork or spawn with this terminal". No such remark for vte_pty_new_foreign(), used by Scope, but given that we indirectly (via gdb) connect the terminal to a spawned program, maybe vte_pty_child_setup() will help?..

Starting with 0.38, vte_pty_new_foreign() has been renamed to vte_pty_new_foreign_sync(), which sounds disturbing. A sync read from the pty is very likely to block, which is exactly what we see. Maybe we should explicitly set the master to non-blocking I/O, before / after / instead of vte_pty_child_setup()?..

Last and least, there may be a bug in VTE, or it may be simply impossible to use it for the program spawned by gdb any more. How about describing the situation to the VTE devs?

[kugel-]

Since spawn_with_callbacks() is used, read() shouldn't block since GIO signals read-readiness.

I don't believe it's a VTE bug but the spawn API or GIO seem buggy to me?

[zhekov]

@kugel-

I'm reading the VTE sources now. It was (completely?) rewritten at some point after 0.28, but some parts remain unchanged, and the easiest test seems to be like this: write a simple "Hello, world!" program that outputs the string to a file, for example "/tmp/boza" or even "/dev/null", and does not emit anything to stdout/stderr (or read from stdin).

Since you confirmed the bug, your configuration is probably suitable for testing?..

Now, if spawn or GIO were the cause, there should have been problems with the other spawn()-ed programs, for example Find in Files -> grep, since the g_io_channel_read_chars() in spawn is used for all callers. Plus, with spawn_async_with_pipes() being private, there is no way to pass spawn*() an input fd obtained from openpty().

[zhekov]

I've got a blocking Ubuntu now. In the default configuration, the entire GUI blocks, which is pretty amazing.

Disabling the VTE terminal, setting the debug console to non-VTE, and using an empty program without any output, compiled without -g, helps a bit - Geany uses only ~98% CPU time instead of 100%, you can switch file/debug tabs, and see the debug console: some of the startup gdb commands are executed and their output is displayed, very slowly, but the breakpoint at "main" is not reached, or the gdb output from hitting it is not displayed, at least not in any reasonable period of time.

The next step would be to set some debug output in spawn_read_cb() and see what happens there...

[zhekov]

Log from spawn_read_cb():

Activation: 1
condition: 1 = G_IO_IN
chars_read: 28
status: 1 = G_IO_STATUS_NORMAL

Activation: 2
condition: 1 = G_IO_IN
(no chars read)
status: 3 = G_IO_STATUS_AGAIN
.....
Activation: 22737
condition: 1 = G_IO_IN
(no chars read)
status: 3 = G_IO_STATUS_AGAIN
.....
Activation: 81541 (these new machines are pretty fast)
condition: 1 = G_IO_IN
chars_read: 808
status: 1 = G_IO_STATUS_NORMAL
.....

@kugel- You were right, it's not a VTE problem per se.

spawn_read_cb() is invoked continuously by GIO with G_IO_IN but zero bytes to read.

Unless there is some very strange spawn bug, which I'm unable to notice, it's a GIO problem. VTE may be affected too, though it's G_IO_IN watch is simpler.

[zhekov]

I removed my previous comment. b4n probably had his reasons to make spawn-Win32 unicode, and it's not my job as a current non-developer to complain anyway. I asked him to state his name as a developer of the unicode part, and that's it.

Now, it'll be interesting whether a callback that detects continuous empty G_IO_IN-s can add a timeout source to the context (removing it's own gio watch source is easy), and whether G_IO_OUT-s are affected too...

[kugel-]

@zhekov does the win32-unicode thing relate to this issue (or is this just an side-rant ;-) )?

[kugel-]

How do you detect an empty G_IO_IN anyway, if not doing a blocking read()?

[zhekov]

@kugel- No, the unicode is not related. I lost my temper, for which I apologize.

The detection in the callback pretty easy: it it invoked with a G_IO_IN | G_IO_PRI condition, attempts to read, but immediately receives G_IO_STATUS_AGAIN. Just to be sure, the callback may count these, and react when they reach, say, 200. Their speed seems to be 5..10K/second on my machine, so 200 seems like a safe bet which will not waste any noticeable time.

[zhekov]

Fixed it. :) A few more tests, and hopefully a RP in Saturday.

[kugel-]

I'm curious, what's the bug (and in what code)?

[zhekov]

Almost surery GLib. I'll explain in detail with the PR.

[zhekov]

geany/geany#1461

[andreygursky]

and the easiest test seems to be like this: write a simple "Hello, world!" program that

BTW, @zhekov, have you (or someone else involved with that bug) written such a tiny reproducer?

[elextr]

@andreygursky did you test the fix at #1461?

[andreygursky]

@elextr, not yet. I thought about finding the bad commit in GLib.

[elextr]

@andreygursky while its nice to fix Glib, we have to handle faulty versions, they are gonna be in the wild for some years yet, hence #1461

[andreygursky]

@elextr, the bug in GLib could be considered as DoS and thus a security issue, which after being fixed should be backported to stable distributions. OTH you're right, who knows, whether this happens. But still I think identifying the bug might help with finding an easier workaround.

[zhekov]

@andreygursky

AFAIK, nobody has written a test program.
The glib version that introduced the bug should be 2.43.0 or 2.43.1, see #1461.

[lpaulsen93]

@zhekov: thanks for the fix 👍

@elextr @kugel-: I can confirm that this also fixed the problem on my system. Are there any plans to merge this in the next time?

[elextr]

@LarsGit223 presume you actuially meant to ping geany/geany#1461 its the PR :)

[lpaulsen93]

@elextr: yes, of course. I have repeated my question there.

[lpaulsen93]

As geany/geany#1461 is merged now, this can be closed.

[b4n]

Maybe we should make Scope depend on Geany 1.34 to be sure it has a working version?

[elextr]

Maybe we should make Scope depend on Geany 1.34 to be sure it has a working version?

Just bump the ABI.

[b4n]

I don't think it's a very good idea: we didn't actually break ABI, and we could load an older Scope and it would work. The only thing would be preventing from loading Scope with an older Geany, which could be achieved by the plugin depending on a 1.34 API. And there's only 1 known plugin suffering from the issue anyway, so I don't think a "solution" should be penalizing everybody.
Anyway, my suggestion is not really useful in practice, because all it does is try and preventing using an older Geany with a newer Scope, but anybody with an older Scope would not be stopped, and anybody with a newer Geany wouldn't need it… so it only can help for latest version of either Scope or Geany. Bah.

[elextr]

ABI should change on semantics changes, which did change, but you are right its of little practical use.

[lpaulsen93]

I think this should be closed.

[lpaulsen93]

Can this be closed finally?

[lpaulsen93]

Ping. This can be closed.