Retroarch: [QT] SIGABRT when launched after already loading some content

[ghost]

First and foremost consider this:
Only RetroArch bugs should be filed here. Not core bugs or game bugs
This is not a forum or a help section, this is strictly developer oriented
Description
QT browser thing crashes when it is launched after already have launched some content.

Expected behavior
should safely swith in or out of qt regardless of when invoked.

Actual behavior
crash

Steps to reproduce the bug
open retroarch (do not launch or switch to QT browser (F5)).
open any content (was using NES and nestopia for example). let it run a few secs. then close content.
launch QT (using F5, dunno if theres anyther way) and run a content (using "Run" at bottom left)
this should crash all the time.
alternate method

run retroarch
run content (NES was what i tested)
press F5 or launch QT
close content
crash!
Bisect Results
[Try to bisect and tell us when this started happening]

Version/Commit

You can find this information under Information/System Information

RetroArch: 1.7.3 commit 2771f8c
Environment information

OS: linux arch
Compiler: gcc version 7.3.1 20180312 (GCC)

[orbea]

No backtrace?

[orbea]

Maybe related, but I can open the Qt ui while content is running fine, but if I then close that content RetroArch closes immediately with.

$ retroarch
qt5ct: using qt5ct plugin
qt5ct: D-Bus global menu: no
GLib (gthread-posix.c): Unexpected error from C library during 'pthread_setspecific': Invalid argument.  Aborting.
Aborted

[orbea]

Ah, I was expecting a segfault when I read this issue.

That said there is a segfault when closing RA that seems related to Qt, but it only happens when I'm not expecting it so I haven't been unable to try debugging it yet...

[orbea]

Sorry, I thought I was replying to a different issue...

Why did you close this, was it resolved?

[ghost]

no, its not resolved... just dont want to put in the extra time to trace after finding it to be an issue...
besides, issues ive been posting hasnt been flagged or confirmed to be a bug and will just be buried deep (again.)

[bparker06]

Confirmed here with archlinux also, on latest commit.

[bparker06]

Probably related to this:

bool QCoreApplication::hasPendingEvents()
Note: this function is not thread-safe. It may only be called in the main thread and only if there are no other threads running in the application (including threads Qt starts for its own purposes).

In my own backtrace (yours did not include all threads), I can see there is a QThread running (for D-Bus perhaps?), so that may be related.

[bparker06]

c2ad8d47d3 fixes this for me.

[orbea]

This is fixed here too.

[orbea]

@retro-wertz When you have some time can you check if this is fixed for you too? :)

[ghost]

done