FileDialog hangup in KDE #3807
Labels
bug
Issues that relate to unexpected/unwanted behavior. Don't use for PRs.
comp: sclang
sclang C++ implementation (primitives, etc.). for changes to class lib use "comp: class library"
crash
things which cause a crash in the interpreter, servers, or IDE. do not use for PRs
os: Linux
Milestone
Comments
|
(having some trouble with code formatting...) |
nhthn
added
bug
|
cannot reproduce on ubuntu + xfce. does this more minimal reproducer also work? (server is not booted, no GUI running) (
var go;
go = {
FileDialog.new(
okFunc: { },
cancelFunc: go,
fileMode: 1,
acceptMode: 0,
stripResult: false,
path: Platform.userHomeDir
);
};
go.value;
) |
|
After some trial and error: the more minimal version appears to be more difficult to make hang, but it hangs pretty much every time if I paste it in and run it immediately after starting scide, while docs are still being indexed. At that moment also indexing of the docs never completes (or maybe it's just the post window that hangs as well) |
|
immediately after booting the IDE, or immediately after rebooting the interpreter? |
|
immediately after booting the IDE |
|
let's see if we can isolate the differences between the two code snippets. can you try A) the original code without the server booted, and B) the minimal code with the server booted? |
|
A) doesn't hang up (
s.waitForBoot({
var go;
go = {
FileDialog.new(
okFunc: { },
cancelFunc: go,
fileMode: 1,
acceptMode: 0,
stripResult: false,
path: Platform.userHomeDir
);
};
go.value;
});
) |
|
If I wait for a while after booting the server manually (to exclude some race condition during startup), the minimal code fragment takes about 20-30 times canceling to hang up. |
|
got two possible fixes here, branches https://github.com/supercollider/supercollider/tree/topic/filedialog-1 https://github.com/supercollider/supercollider/tree/topic/filedialog-2 |
|
filedialog-1 doesn't seem to contain any commit - forgot to push? |
|
oops, pushed |
|
unfortunately both versions still can freeze with the server booted (second version faster than the first version it seems) |
|
However, with both patches applied simultaneously, I haven't been able to make it freeze yet. I'll keep trying ;) |
|
Meh... now it hung up after 64 "cancels". It seems to take longer to freeze than before, but it doesn't seem to be completely solved yet. |
|
here are some of the resources i found that might help us attack this:
according to the KDE issue tracker link, this bug has been fixed in KDE. from the last link:
can you try that? |
|
pressing ESC doesn't help - it remains frozen |
|
i suspect this is upstream. next thing to try is to see if we can make a minimal reproducer without using SC. please create a new directory, and the following in then run |
|
I just canceled that dialog 500 times without any hangup
|
|
To be honest, scide's own file dialogs never ever froze on me before (and I've been a fairly regular user of scide for the better part of the past 2 years) so forgive me for sounding perhaps somewhat sceptical about the upstream hypothesis. Is there anyway I can "break into" the frozen process and force it to dump a stack trace e.g. ? |
I think you can use gdb for that. check the documentation for attaching to a process by pid number. then you can type 'bt' to get a back trrace. The build must have debug symbols. |
|
Ok I made a debug build, then attached gdb and asked for a backtrace: |
|
I guess it's more useful to have a backtrace of all threads in this case... |
|
A new day, a new experiment: I dumped backtraces for all threads, once when it was hanging and once when it was not hanging. I then removed all threads that are common between the two scenario's and ended up with this: Case where it's hanging: Case where it's not hanging: |
|
@scztt has a lead on this one -- has something to do with incorrectly re-entering the language thread, and in theory should actually be happening on all platforms (but mysteriously isn't). appears that the method will have to be rewritten with an asynchronous callback. |
|
that's good news... it's slowly driving me crazy having to kill the interpreter all the time for no good reason :) |
|
(after today, make that "quickly" driving me crazy :) ) |
|
That is excellent news. I'll be sure to test it when I get home this evening. |
|
@scztt sure: |
|
Is anyone still looking at this? I find thread 34 suspicious because it appears to be present in all stack traces of hangups, and it seems to use a construct that (as far as I can see) is only used on linux platforms (string_popen_thread_func). Is it possible/worth trying to remove/replace this construct as is (presumably) done on other platforms? #0 0x00007fbb64ab0934 in read () from /usr/lib/libc.so.6 |
|
i don't know how to fix this, and scott has been pretty busy recently. sorry :/ |
shimpe
added a commit
to shimpe/supercollider
that referenced
this issue
Aug 14, 2019
This was referenced Aug 14, 2019
shimpe
added a commit
to shimpe/supercollider
that referenced
this issue
Aug 15, 2019
|
A workaround seems to be to adapt the reproducer code as follows |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I have no idea how to go about debugging this. The following code often just works, and then suddenly it simply hangs up (just keep clicking load-cancel-load-cancel-etc). Sometimes it freezes immediately, sometimes it takes about 20-30 open-cancel cycles (never more until now). When it freezes, there's no known way of recovering other than killing the interpreter.
The problem is particularly annoying because it can lead to data loss (this dialog is typically used in save buttons too). Looking through google, hangups with file dialogs may be related to using "native file dialogs" (which, I think, is some flag available only in C++).
I'm working on a KDE (kde plasma 5.13.1, kde framework 5.47.0, qt 5.11.1, 16Gb RAM, 64bit Os, 8xIntel Core i7-4910MQ CPU @ 2.90 GHz) linux environment (arch linux - kernel 4.17.2-1-ARCH #1 SMP PREEMPT Sat Jun 16 11:08:59 UTC 2018 x86_64 GNU/Linux), with supercollider built from source (sha1 3c49a4f).
The following code can be used to reproduce the hangup on my system. The most efficient way of opening and closing the dialog several times I found so far is to just left mouse click the load button, then type alt-C to cancel.
(s.waitForBoot({ w = Window.new("test", Rect(0,0,400,400)); w.layout_(HLayout( Button().string_("Load").action_({ | button | var filename = FileDialog.new( okFunc:{ "Ok".postln; }, cancelFunc: { "Cancel".postln; }, fileMode:1, acceptMode:0, stripResult:false, path:Platform.userHomeDir ); }); )); w.front; }); )The text was updated successfully, but these errors were encountered: