seg fault in rpc session

[maurizioandreotti]

I was testing latest D-Rats-python3_tyw as of today 26/4/2022 and, after having connected to usual k3pdr ratflector, done a ping all, opened the map window, issued an "request all position" i got to:

04/26/2022 19:18:16:DEBUG:Transporter:parse_blocks: [NET k3pdr.dstargateway.org:9000-IZ2LXI] Got a block: DDT2+: 1:2:1 K2TJW->IZ2LXI (b'rc\x1fOK'...[5])
04/26/2022 19:18:16:INFO:SessionManager:incoming: Received block 1:1 for session `rpc'
Segmentation fault

[wb8tyw]

When working on the pluginsrv module, it looked like some of the rpc code is calling GTK methods from threads instead of using the GLib.idle_add() function, which may be a cause of that.

We need to map out and tag with comments code that is running in thread, or something to help cut down on this.

[maurizioandreotti]

Do you have any idea or suggestion tonbe of more help when yjis happen? I mean how to get relevant info when this happen? Eg something like core dump save or logs or anything? Il ven 29 apr 2022, 02:13 John E. Malmberg ***@***.***> ha scritto:

…

When working on the pluginsrv module, it looked like some of the rpc code is calling GTK methods from threads instead of using the GLib.idle_add() function, which may be a cause of that. We need to map out and tag with comments code that is running in thread, or something to help cut down on this. — Reply to this email directly, view it on GitHub <#173 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB2W7OQY7G472FGWEWMEQXDVHMSQXANCNFSM5UMRMPZA> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[wb8tyw]

Unfortunately this type of crash does not really give any useful data.

It is related to the GTK Critical Messages that also show up from time to time that reference non-existent line numbers.

About the only way we are going to find these is by learning enough about d-rats internals.

These crashes can also occur by calling deprecated GTK 3 methods, which there are still a lot of cases that I have not found.

GTK is not thread-safe according to the current documentation, and the documentation implies that the old GTK version previously used by d-rats was not actually thread safe either, even though it had thread methods in it. Those thread methods are still present in the current GTK 3, and are designated as deprecated.

The crashes in the map code were caused by the tile fetching thread issuing a GTK 3 call directly, instead of calling Glib.idle_add() as a wrapper to it.

[wb8tyw]

17 modules have "threading" in them to investigate.

[wb8tyw]

https://wiki.gnome.org/Attic/GdkLock

Still trying to understand this document.
Interesting comment in it: "Using GTK+ from multiple threads on Windows does not work at all"
So it is possible that every use of "@run_gtk_locked" needs to be changed.

[wb8tyw]

`
*** BUG ***
In pixman_region_append_non_o: The expression y1 < y2 was false
Set a breakpoint on '_pixman_log_error' to debug

Segmentation fault
`

[wb8tyw]

#181 fixes a resource leak that could possibly be causing this and other issues. This resource leak was due to a bug unique to my python3 fork.