bugGNU Octave - Bugs: bug #38305, Conflicts between octave's SIGCHLD...

 
 

bug #38305: Conflicts between octave's SIGCHLD handler and qt process handling

Submitter:  None
Submitted:  Mon 11 Feb 2013 12:46:21 PM UTC
   
 
Category:  GUI Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Other
Status:  Fixed Assigned to:  None
Originator Name:  Originator Email:  -email is unavailable-
Open/Closed:  * Closed Release:  * dev
Operating System:  * GNU/Linux Fixed Release:  None
Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Mon 06 Apr 2015 02:29:16 AM UTC, comment #46: 

I think so. I don't see any uses of QProcess in Octave now, except to start the external editor, but that does not rely on getting the child process exit status.

If there is a need to use QProcess in libgui later, this may come up again, but closing as fixed for now.

Mike Miller <mtmiller>
Group Member
Mon 06 Apr 2015 12:50:43 AM UTC, comment #45: 

@Mike: Quoting from comment #44, "Leaving this bug report open for the file dialog case and the more general case of QProcess / SIGCHLD handler not working. If there are no further problems in the current GUI, this should be closed as fixed."

Can this bug be closed now?

Rik <rik5>
Group administrator
Sat 21 Feb 2015 05:47:22 AM UTC, comment #44: 

Thanks Torsten, I adapted your patch to use Octave's iprocstream and pushed it to default:

http://hg.savannah.gnu.org/hgweb/octave/rev/be7b05f95d7c

It works perfectly for me with gzip-compressed and xz-compressed info files.

Leaving this bug report open for the file dialog case and the more general case of QProcess / SIGCHLD handler not working. If there are no further problems in the current GUI, this should be closed as fixed.

Mike Miller <mtmiller>
Group Member
Sat 03 Jan 2015 08:54:01 AM UTC, comment #43: 

The problems whith unzipping compressed info files are fixed on my system with the attached patch. It handles the unzipping process by popen instead of QProcess. I'd be happy if the patch could be tested on other systems with compressed info files.

@Thorsten: Does the use of non-native file dialogs (see comment #38) fixes the freeze when opening a file dialog?

(file #32750)

Torsten Lilge <ttl>
Group Member
Mon 13 Jan 2014 03:10:29 AM UTC, comment #42: 

I'm not sure what the status is.  It has certainly been out of my mind for a while (because of how busy I've been).  Seeing that there are about three or so bug reports that come back to this same issue, I'd say this is a rather high priority bug.  I think that this is of the sort that JWE should be involved in because of its OS dependence and core behavior.  Given the 3.8 series has been announced, perhaps now is a good time to get some of John's bandwidth.

Dan Sebald <sebald>
Wed 01 Jan 2014 08:38:00 PM UTC, comment #41: 

Marking bug #41055 (problems unzipping compressed info files) as duplicate of this bug.

Torsten Lilge <ttl>
Group Member
Wed 01 Jan 2014 07:14:30 PM UTC, comment #40: 

What is the actual status of the discussion concerning octave  core's SIGCHLD handler?

Torsten Lilge <ttl>
Group Member
Sun 07 Jul 2013 05:47:43 PM UTC, comment #39: 

Another issue that seems to have the same cause are possible freezes when opening new documentation tabs as described in patch #7949. Therefore, patch #7949 was closed and the long term solution will be discussed in this bug report.

Torsten Lilge <ttl>
Group Member
Sun 07 Jul 2013 05:23:17 PM UTC, comment #38: 

The same problem was described in #patch 7948 (including a reference to the KDE bug report
https://bugs.kde.org/show_bug.cgi?id=260719
which was mentioned by Dan, too). The solution (maybe temporary workaround) was to prevent native file dialogs. I pushed patch #7948 with changeset

http://hg.savannah.gnu.org/hgweb/octave/rev/6bd74153c3ae

and I would like to ask if you could test if it fixes the problem on your system, too.

Torsten Lilge <ttl>
Group Member
Mon 27 May 2013 09:24:43 AM UTC, comment #37: 

OK.  Great that you found the problem!

On the other hand, it could be a bad problem requiring some help and discussion from the maintainers list.

The SIGCHLD is a signal notification to the parent process whenever one of its child processes terminates:

http://www.gnu.org/software/libc/manual/html_node/Job-Control-Signals.html#Job-Control-Signals

You commented out Octave's signal handler for this, so the application is likely falling back on Qt's signal handler.  I believe that the Samba server via Qt is using a child process that originates from the Qt GUI thread.  That child process(es) is probably an extremely fast LAN access on the order of a fraction of a second and may not show up in the system monitor because it doesn't last very long.

I bet the problem is that Octave core's SIGCHLD handler doesn't have the GUI-thread-created child processes in its list.  Therefore, it cannot appropriately respond to the signals associated with those children.  This is tricky.  Either Octave will have to not set the SIGCHLD signal handler when run under the GUI (not so bad) or the GUI thread will have to figure out how to put child processes in Octave core's child list (nasty).  It depends on whether there are some child processes for which Octave core needs to respond to in a special way.

I'll write to the maintainers list sometime later today.

Dan Sebald <sebald>
Mon 27 May 2013 08:40:55 AM UTC, comment #36: 

I already tried to find which signal it is. And by broot-force trial and error (and with a bit luck) I found quickly:

Lines 472-474 (sighandlers.cc)
#ifdef SIGCHLD
//  octave_set_signal_handler (SIGCHLD, sigchld_handler);
#endif
That comment makes it not freeze!

I have no idea what this signal means or does, but without it, I see NO freeze (I double checked)

Thorsten Liebig <thorsten>
Mon 27 May 2013 08:34:43 AM UTC, comment #35: 

OK, so I assume Octave functions at least reasonably well, e.g., basic commands sans file i/o, large matrices, etc.  Remove the comments delimiters so that install_signal_handlers (); is run.

Well, inside libinterp/interfcn/sighandlers.cc is the routine install_signal_handlers() that we looked at earlier.  Can comment out some things here or there that might seem like a problem.  But first try replacing every "SIG_IGN" by "SIG_DFL" and recompile.  I'm now wondering if this old System V signal:

#ifdef SIGPOLL
  octave_set_signal_handler (SIGPOLL, SIG_IGN);
#endif

is being used by Samba.

Dan Sebald <sebald>
Mon 27 May 2013 08:24:41 AM UTC, comment #34: 

With that change it does NOT freeze..

Thorsten Liebig <thorsten>
Mon 27 May 2013 08:16:51 AM UTC, comment #33: 

"
and:
octave_initialize_interpreter (octave_cmdline_argc, octave_cmdline_argv,
// octave_embedded);

octave_execute_interpreter ();
exec();
--> file dialog *did not freeze"
But I guess that was no surprise?
"

Not a surprise, no.  But confirming is good to prevent going off track.

If you are not seeing SIGHUP or SIGINT in your signals.h file, then I assume that KUbuntu is not using those signals so I doubt that is where the problem lies.

I think the thing to do next is just a process of elimination.  Go back to the unmodified octave-main-thread.cc.

In the file libinterp/octave.cc is a function octave_initialize_interpreter ().  Most of the lines of code look pretty innocuous, but let's confirm it is the signal handler configuration that is the problem.  Place comments around this install_signal_handlers:


/*
  if (! embedded)
    install_signal_handlers ();
  else
    quit_allowed = false;
*/


Hopefully there are no real important signals within Octave core for Octave to run, at least for a little while and not taxing the system too much.

Dan Sebald <sebald>
Mon 27 May 2013 07:39:18 AM UTC, comment #32: 

Wow, a lot of updates ;)

I tried the
octave_set_signal_handler (SIGIO, SIG_DFL);
at "sighandlers.cc" line 561
--> no effect

In "octave-main-thread.cc" I tried:
octave_execute_interpreter ();
exec();
--> no effect

and:
  octave_initialize_interpreter (octave_cmdline_argc, octave_cmdline_argv,
  //                               octave_embedded);

  octave_execute_interpreter ();
  exec();
--> file dialog *did not freeze"
But I guess that was no surprise?

The "SIG" command in Octave gave the same list you posted.

I did a "grep SIGAIO * -r" in my BUILD directory (I do out of source build) but did not find anything...

Shall I send you my /usr/include/signal.h, but I didn't find any SIGHUP or SIGINT and I guess the file is the default/not secret for (K)Ubuntu?

Shall I try something else/ did I miss something to try?
I'm not sure I really understand this all about the signals...
But somehow this is causing the problems...

Thorsten Liebig <thorsten>
Mon 27 May 2013 06:24:14 AM UTC, comment #31: 

Just writing some lines of investigation here...

I notice in the sighandlers.cc file is this configuration for SIGIO:


octave_set_signal_handler (SIGIO, SIG_IGN);


Here is a description of SIGIO:

http://www.gnu.org/software/libc/manual/html_node/Asynchronous-I_002fO-Signals.html#Asynchronous-I_002fO-Signals

And here is a description of what SIG_IGN means:

http://www.gnu.org/software/libc/manual/html_node/Basic-Signal-Handling.html

I'm wondering if we need a valid signal handler or use the default signal handler (i.e., SIG_DFL) rather than ignoring the signal.  The documentation says to not ignore something for which there could be a valid signal sent.  I'm wondering if perhaps under the scenario you describe, i.e., a Samba server there might be some asynchronous signal sent (i.e., a meaningful SIGIO signal).  Perhaps if that is the case then ignoring the signal is the wrong thing to do because the OS kernel believes (rightfully so) that the QProcesses are not responding.

If you want to give something a try, see what happens when you change that line above to:


octave_set_signal_handler (SIGIO, SIG_DFL);


Dan Sebald <sebald>
Mon 27 May 2013 05:56:05 AM UTC, comment #30: 

I've looked through the signal code for Octave and there are some deficiencies in the SIG routine.  There are two or three signal definitions that won't appear in the least even though they might be defined.  Could you please email me a copy of your /usr/include/bits/signum.h file?  Or maybe it is /usr/include/signal.h or /usr/include/sys/signal.h... whichever has the list of definitions such as

#define SIGHUP 1 /* Hangup (POSIX).  */
#define SIGINT 2 /* Interrupt (ANSI).  */
etc.

Dan Sebald <sebald>
Sun 26 May 2013 10:21:23 PM UTC, comment #29: 

I searched for a command that might be displaying the signal information, and here it is (compare results with yours and note any differences):


>> SIG
ans =

  scalar structure containing the fields:

    ABRT =  6
    ALRM =  14
    BUS =  7
    CHLD =  17
    CLD =  17
    CONT =  18
    FPE =  8
    HUP =  1
    ILL =  4
    INT =  2
    IOT =  6
    PIPE =  13
    POLL =  29
    PROF =  27
    PWR =  30
    QUIT =  3
    SEGV =  11
    STOP =  19
    SYS =  31
    TERM =  15
    TRAP =  5
    TSTP =  20
    TTIN =  21
    TTOU =  22
    URG =  23
    USR1 =  10
    USR2 =  12
    VTALRM =  26
    IO =  29
    WINCH =  28
    XCPU =  24
    XFSZ =  25


Dan Sebald <sebald>
Sun 26 May 2013 10:12:44 PM UTC, comment #28: 

Further information:  I'm running Gnome without any kind of LAN.  I do not see a SIGAIO defined in my config file (i.e. I did a whole search of my BUILD directory

grep SIGAIO * -r

and saw nothing).  Perhaps check if that is defined in KDE LAN environments.

Dan Sebald <sebald>
Sun 26 May 2013 10:06:19 PM UTC, comment #27: 

Hunting around a bit in the code, I think the following might be getting close to the source.

For a recap, we've found that KDE-linux version of the GUI has standard Qt file-dialogs that freeze under the condition that there is a Samba server in the system.  We have a vague notion that the Samba server and QProcess aren't working together well and somehow the signal about a completed system process is being masked or blocked in some way from reaching back to the QProcess.  Furthermore, the before/after line of non-freeze/freeze appears to be line 935 in main-window.cc:

"_octave_qt_link->execute_interpreter ();"

The lines of code beginning the new thread are:


  setlocale (LC_NUMERIC, "C");
  octave_initialize_interpreter (octave_cmdline_argc, octave_cmdline_argv,
                                 octave_embedded);
  octave_execute_interpreter ();


Following the routine "octave_initialize_interpreter" leads to some modifications to signal handling in a file called siglist.c.  If there is someone who understands this, please comment.  The line in particular I'm wondering about is:


# ifdef SIGAIO
      sys_siglist[SIGAIO] = "LAN I/O interrupt";
# endif
-verabtim-

because it seems to me that one might have something to do with with a Samba server.  Why is Octave modifying (or not modifying but at least monitoring, I'm not sure) the signals?

This is still a bit fuzzy for me because this is being done in a separate thread from where the GUI Qt file-dialog is freezing.  But maybe these low-level modifications affect all threads.

Dan Sebald <sebald>
Sun 26 May 2013 09:47:56 PM UTC, comment #26: 

Perhaps change those tests to the following (it's just adding the default exec() to make sure the thread doesn't end immediately):


void
octave_main_thread::run (void)
{
  // Matlab uses "C" locale for LC_NUMERIC class regardless of local setting
  setlocale (LC_NUMERIC, "C");

//  octave_initialize_interpreter (octave_cmdline_argc, octave_cmdline_argv,
                                 octave_embedded);

//  octave_execute_interpreter ();
  exec ();
}


Then this:


void
octave_main_thread::run (void)
{
  // Matlab uses "C" locale for LC_NUMERIC class regardless of local setting
  setlocale (LC_NUMERIC, "C");

//  octave_initialize_interpreter (octave_cmdline_argc, octave_cmdline_argv,
                                 octave_embedded);

//  octave_execute_interpreter ();
  exec ();
}


Then this:


void
octave_main_thread::run (void)
{
  // Matlab uses "C" locale for LC_NUMERIC class regardless of local setting
  setlocale (LC_NUMERIC, "C");

//  octave_initialize_interpreter (octave_cmdline_argc, octave_cmdline_argv,
                                 octave_embedded);

//  octave_execute_interpreter ();
  exec ();
}


Dan Sebald <sebald>
Sun 26 May 2013 09:39:28 PM UTC, comment #25: 

Hold on.  Placing a GUI element inside that run function will probably break no matter what because it sounds like "run" is the starting point of the new thread, i.e., whatever is inside of "run" is executing in the non-GUI thread.

So, let's try placing the Qt file-dialog instruct after

_octave_qt_link->execute_interpreter ();

in main-window.cc and comment out portions of "run".  That is, first try this:


void
octave_main_thread::run (void)
{
  // Matlab uses "C" locale for LC_NUMERIC class regardless of local setting
  setlocale (LC_NUMERIC, "C");

  octave_initialize_interpreter (octave_cmdline_argc, octave_cmdline_argv,
                                 octave_embedded);

//  octave_execute_interpreter ();
}


Then this:


void
octave_main_thread::run (void)
{
  // Matlab uses "C" locale for LC_NUMERIC class regardless of local setting
  setlocale (LC_NUMERIC, "C");

//  octave_initialize_interpreter (octave_cmdline_argc, octave_cmdline_argv,
                                 octave_embedded);

//  octave_execute_interpreter ();
}


Then this:


void
octave_main_thread::run (void)
{
  // Matlab uses "C" locale for LC_NUMERIC class regardless of local setting
//  setlocale (LC_NUMERIC, "C");

//  octave_initialize_interpreter (octave_cmdline_argc, octave_cmdline_argv,
                                 octave_embedded);

//  octave_execute_interpreter ();
}


Note the behavior of freezing in all three cases.

Dan Sebald <sebald>
Sun 26 May 2013 09:16:15 PM UTC, comment #24: 

OK, helpful.

Please remove that default Qt file dialog command and place it in the octave_main_thread::run inside octave-main-thread.cc:


void
octave_main_thread::run (void)
{
  // Matlab uses "C" locale for LC_NUMERIC class regardless of local setting
  setlocale (LC_NUMERIC, "C");

  octave_initialize_interpreter (octave_cmdline_argc, octave_cmdline_argv,
                                 octave_embedded);

  octave_execute_interpreter ();
}


taking the same approach trying to isolate which line of code correlates with the freeze problem.

Dan Sebald <sebald>
Sun 26 May 2013 08:29:39 PM UTC, comment #23: 

I tried to find the cause a bit more. As I mentioned earlier, running a file-dialog in an early stage worked fine.

I tracked this down to line 935 in main-window.cc:
"_octave_qt_link->execute_interpreter ();"

If I put a default Qt file-dialog before that line, it works fine, do I put it behind, it freezes...

Somehow this octave-qt-link is making trouble... But I have no idea how to continue following this lead...

Thorsten Liebig <thorsten>
Sun 26 May 2013 08:05:04 PM UTC, comment #22: 

It uses 2 processes at all times, before/during and after the file-dialog freeze... I have no idea, what QProcess is killed if it never shows up...

Thorsten Liebig <thorsten>
Sun 26 May 2013 07:19:18 PM UTC, comment #21: 

There are a couple ways.  In Gnome (what I'm using) there is a system monitor feature under the menu "System Tools".  I would imagine KDE has something similar.  The system monitor shows several things like CPU usage, network usage, system memory.  There is another category called Processes which lists stats and tracks processes.

Or, one could use the OS command "ps -u <account name>" and that will list the same information that is shown in the Processes tab of the system monitor.  For example, on my system


[sebald@ ~]$ ps -u sebald
  PID TTY          TIME CMD
 1670 ?        00:00:00 gnome-keyring-d
 1678 ?        00:00:00 gnome-session
[SNIP]
 2490 pts/1    00:00:00 bash
 2506 pts/2    00:00:00 bash
 2519 pts/2    00:00:00 lt-octave
 2652 ?        00:01:37 lt-octave
 2918 ?        00:00:57 xmms
 3380 ?        00:00:00 gvim
 3742 pts/4    00:00:00 bash
 3777 pts/4    00:00:00 ps


Notice how "ps" is the last process...that's the process associated with the command just run.

We know there should be at least two processes associated with Octave run in the GUI.  The main application GUI is a process and then the Octave core (or "worker process") is launched as a separate QProcess inside the GUI.  (If you see some discussion on the list from time to time about "thread safe" and so on, that's because we now have two separate processes interacting with one another.)

Dan Sebald <sebald>
Sun 26 May 2013 06:42:43 PM UTC, comment #20: 

I tried to look for the processes but I'm not sure I did it correctly, how did you check? I think I only saw 1 process at all times...

I have one more info: Ubuntu with the Unity desktop is not affected, it really seems to be only KDE (or Kubuntu only?)+Samba+Octave...

Thorsten Liebig <thorsten>
Sun 26 May 2013 04:14:25 PM UTC, comment #19: 

Interesting.  Well, I've watched the processes when I use the file dialog on my system and I don't see anything new that is created.  Can you see any new processes on your system when you run the Octave GUI file dialog?  The question I have is exactly what processes is it that are terminating incorrectly?  Apparently the Octave worker QProcess is still functioning, and the GUI is still running.  Are there QProcesses launched in response to detecting a Samba server?

Your own app is launched from your local account, I assume.  What about Octave/GUI, is that being launched from your own account?  Might it be on a different file system?

Dan Sebald <sebald>
Sun 26 May 2013 09:11:10 AM UTC, comment #18: 

"The file dialog is probably the only part of Octave that relies on Samba access. My guess is that Samba masks or blocks the mechanism that notifies QProcess of a completed task. "

I use the default Qt Widget / File-Dialog in my own GUI, but only inside the Octave GUI is freezes if a samba server is running. The question is why...  What is doing Octave GUI differently that causes this issue...

I would guess that it is still important to fix this, having a samba share is not that uncommon?

Thorsten Liebig <thorsten>
Sun 26 May 2013 08:55:19 AM UTC, comment #17: 

"But why does it only affect Octave's file dialog?"

The file dialog is probably the only part of Octave that relies on Samba access.  My guess is that Samba masks or blocks the mechanism that notifies QProcess of a completed task.


"As far as I understand only KDE is affected?"

This I don't know.  If it is purely a Windows environment, there shouldn't be a problem, because QProcess wouldn't be using the linux notification mechanism.  I'm not sure we have other examples of Linux + Samba server on other setups yet.

Dan Sebald <sebald>
Sat 25 May 2013 06:00:24 PM UTC, comment #16: 

Well that sounds really complex...

But why does it only affect Octave's file dialog?

As far as I understand only KDE is affected? 

Well to reproduce the bug, a fresh Kubuntu + Samba installed and the latest Octave does trigger it.

@Torsten
what desktop did you use? KDE?

The KGlobal warning seems to be a KDE/Qt bug and is unrelated to Octave, I saw this warning now with other KDE tools as well...
The only drawback is, that since stderr und stdout appear in the Octave terminal, you get to see the message which you normally would not...

Thorsten Liebig <thorsten>
Sat 25 May 2013 03:54:50 PM UTC, comment #15: 

I've tracked down some discussions on this problem, and it appears to be "non-trivial", to say the least.  The issue seemed most prevalent in VLC (this discussion isn't on target):

http://qt-project.org/forums/viewthread/14638

which leads to this lengthy discussion (which is on target):

https://bugs.kde.org/show_bug.cgi?id=260719

and these related links:

https://bugs.kde.org/show_bug.cgi?id=234484
http://lists.kde.org/?l=kde-core-devel&m=129572982213216&w=2

It would take me too much time to understand exactly what they are discussing, but the issue appears to be that QProcess is using SIGCHLD and complications arise if somehow that signal is blocked.  I've a feeling that is what the Samba server support might be doing.  If neither of you understand kernel-level behavior to this level, maybe we should move the discussion back to the maintainers list in hopes someone there understands.

Dan Sebald <sebald>
Sat 25 May 2013 02:01:17 PM UTC, comment #14: 

I still can not reproduce this, even with connected network shares. On my windows system the file dialog seems to test all devices (e.g. the floppy drive is shortly selected). Maybe there is a broken samba share that can not be accessed?

Concerning the warning message, do you see the file dialog translated or not (if using a language setting other than en_US)?

Torsten Lilge <ttl>
Group Member
Sat 25 May 2013 11:26:44 AM UTC, comment #13: 

Well I (kind of) solved the problem... and now it is getting really weird...

When I tried the file-dialog very early, I saw KDE somehow complaining about some false samba share and I remembered that some weeks ago a created a share for my wife and that since then this freezes may have occurred. At work I have had Samba shares for ever, hence Octave always froze...

I verified that in my virtual machine with a fresh Kubuntu install and Octave 3.7.5 from the unstable ppa.
The file dialog works fine, until I install samba (I didn't even create a shared folder), then it freezes as did my system...
No everyone should be able to reproduce the problem...

Octave is doing something with samba/networking that is making the file-dialog freeze...

Any ideas what is going on? At least I know can make my Octave-GUI work again...

Thorsten Liebig <thorsten>
Sat 25 May 2013 11:06:49 AM UTC, comment #12: 

I tried all what you suggested, no effect...

I even tried to insert this in front of the actual file dialog:

QString fileName = QFileDialog::getOpenFileName(this, "Open File","/home","Images (.png .xpm *.jpg)");
And it freezes!!

Adding this just before the GUI is even created, it works fine...
Something is configured/setup/defined, that makes the file dialog freeze the first time...

I guess I have to try to find at which point during GUI setup this starts to freeze.

Any suggestions for reasonable places to try are welcome ;)

Thorsten Liebig <thorsten>
Sat 25 May 2013 10:31:50 AM UTC, comment #11: 

What happens if you make the dialog modal? To test this, change the last three lines to


fileDialog->setWindowModality (Qt::Modal);
fileDialog->setAttribute (Qt::WA_DeleteOnClose);
fileDialog->exec ();


Torsten Lilge <ttl>
Group Member
Sat 25 May 2013 08:39:43 AM UTC, comment #10: 

OK.  Keep trying various things for hope of finding another clue or two.  It would seem that the dialog is hung up somewhere and eventually is killed because not responding.  When you repeat this process, open the system monitor window and watch if anything happens in the Processes list.

It is interesting that there are two messages about "QProcess: Destroyed while process is still running.".  I notice that there are two entries in the filter:

fileDialog->setNameFilter (tr ("Octave Files (.m);;All Files ()"));

Perhaps you could try removing that line of code all together.  Maybe KDE searching for "Octave Files (.m)" and "All Files ()" are the two processes that are getting stuck somehow.  BTW, wouldn't it seem that "All Files ()" should cover "Octave Files (.m)"?

Dan Sebald <sebald>
Sat 25 May 2013 08:37:06 AM UTC, comment #9: 

I can confirm that this "KGlobal::locale():" message is a bug/problem of its own. I run another Qt GUI from terminal and I see the same message if I open a file dialog, but it does not freeze. So this KGlobal message is a KDE/Qt related bug...

I only would suggest that KDE/Qt error messages should not appear in the Octave terminal???

The file dialog freeze one the other hand is Octave specific and has something to do with some QProcess blocking everything until it gets killed by some timeout?
And my feeling is, that this has nothing to do with translations and such...

Thorsten Liebig <thorsten>
Sat 25 May 2013 08:18:01 AM UTC, comment #8: 

That had no effect...

The tr macro tells Qt that you want this string to have a translation...

I'm really not sure that this "KGlobal::locale():" or the translation is the real issue here. I saw that warning on a Kubuntu machine without any freeze...
We want to solve this warning regardless, but it is not as big a problem as this annoying freeze...

Thorsten Liebig <thorsten>
Fri 24 May 2013 10:19:29 PM UTC, comment #7: 

OK Thorsten, I was going to suggest you try that since that seems to be the issue here:

http://qt-project.org/forums/viewthread/7159

The error suggests to me something where the file dialog (which translates somehow to KDE's file dialog) is attempting to use some utility which has already been initialized in some way.

If I understand correctly, the action you are taking and the point of the error message coincides with this hunk of code


void
file_editor::request_open_file (void)
{
  // Open file isn't a file_editor_tab function since the file
  // editor tab has yet to be created and there is no object to
  // pass a signal to.  Hence, functionality is here.

  // Create a NonModal message.
  QFileDialog *fileDialog = new QFileDialog (this);
  fileDialog->setNameFilter (tr ("Octave Files (*.m);;All Files (*)"));
  fileDialog->setAcceptMode (QFileDialog::AcceptOpen);
  fileDialog->setViewMode (QFileDialog::Detail);
  fileDialog->setDirectory (ced);

  connect (fileDialog, SIGNAL (fileSelected (const QString&)),
           this, SLOT (request_open_file (const QString&)));

  fileDialog->setWindowModality (Qt::NonModal);
  fileDialog->setAttribute (Qt::WA_DeleteOnClose);
  fileDialog->show ();
}


If that sound right to you, could you please remove the translator from within the argument of the second line of code?  I.e., change


  fileDialog->setNameFilter (tr ("Octave Files (*.m);;All Files (*)"));


to


  fileDialog->setNameFilter ("Octave Files (*.m);;All Files (*)");


That is the only thing I see for which there might be a conflict of two KDE utilities around the behavior you describe.

Does that rid the error message?  That "tr" is a shorthand macro for something, but I always wondered what exactly.

Dan Sebald <sebald>
Fri 24 May 2013 08:20:17 PM UTC, comment #6: 

That depends, I would guess that 30% is translated to german...
But I assume the translation is just incomplete yet?

There is no change in translation before or after the freezing file dialog.

I tried removing all lines concerning translation from "octave-gui.cc" (lines 108-111), other that I got no translation, it didn't change anything...

Thorsten Liebig <thorsten>
Fri 24 May 2013 07:46:16 PM UTC, comment #5: 

Does the translation work (octave gui and qt dialog boxes) before and/or after the hanging dialog box?

Torsten Lilge <ttl>
Group Member
Fri 24 May 2013 07:22:17 PM UTC, comment #4: 

Reopened since bug is confirmed on Kubuntu 12.10 and 13.04. Detailed information from Thorsten Liebig's post in the maintainers mailing list:

I have a strange problem with the Octave GUI on Kubuntu 13.04 and it already existed on Kubuntu 12.10

If I want to open or save a file, the file dialog and Octave freezes. At the same time I get this message in the Octave terminal: "KGlobal::locale(): Warning your global KLocale is being recreated with a valid main component instead of a fake component, this usually means you tried to call i18n related functions before your main component was created. You should not do that since it most likely will not work"
But this seems not necessarily related to the freeze (see below)

If I wait a couple of minutes, I get on the Octave terminal:
QProcess: Destroyed while process is still running.
QProcess: Destroyed while process is still running.

After this two messages, I can browse the files normally and open/save.

But this two processes that got killed seem to be important, because after this Octave behaves strange...
E.g.: Sometimes the entire GUI freezes or at least doesn't get updated if a script is running...
If I'm patient again, I get again:
"QProcess: Destroyed while process is still running."
And the GUI unfreezes again...

I tried a fresh Kubuntu 13.04 on a virtual machine and did not see this problems, except the "KGlobal::locale()..." message, but no freezes...

- Switch to language en_US does not help.
- No other dialog cases any problems
- Octave does not crash or segfault, I just can't do anything else than wait for the two QProcess to be destroyed. After that I can more or less work normally, even the file-dialog works fine after that...

Torsten Lilge <ttl>
Group Member
Wed 20 Mar 2013 05:53:07 PM UTC, comment #3: 

No response to request for info.  Closing report.

Rik <rik5>
Group administrator
Tue 05 Mar 2013 05:32:20 AM UTC, comment #2: 

- What language is configured in the settings dialog? Does the freeze occur with en_US, too?
- Does the settings dialog cause this freeze, too?

Torsten Lilge <ttl>
Group Member
Tue 05 Mar 2013 12:31:11 AM UTC, comment #1: 

Does Octave actually crash, as in a segmentation fault and a return to the shell prompt?  Or is the first File Dialog window slow to open, but subsequent dialogs are fine?

Rik <rik5>
Group administrator
Mon 11 Feb 2013 12:46:21 PM UTC, original submission:  

Octave freezes for about a minute when opening a file dialog for the first time after starting octave.

I get the message:

KGlobal::locale::Warning your global KLocale is being recreated with a valid main component instead of a fake component, this usually means you tried to call i18n related functions before your main component was created. You should not do that since it most likely will not work
QProcess: Destroyed while process is still running.

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files

 

Carbon-Copy List
  • -email is unavailable- added by mtmiller (Posted a comment)
  • -email is unavailable- added by omsai
  • -email is unavailable- added by svillemot
  • -email is unavailable- added by asrv01
  • -email is unavailable- added by rik5 (Updated the item)
  • -email is unavailable- added by sebald (Posted a comment)
  • -email is unavailable- added by ttl (Posted a comment)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 17 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2015-04-06 mtmiller StatusConfirmed Fixed
        Open/ClosedOpen Closed
    2015-02-21 mtmiller StatusPatch Submitted Confirmed
    2015-01-03 ttl StatusNeed Info Patch Submitted
    2015-01-03 ttl Attached File- Added bug38305_popen_2015-01-03.patch, #32750
    2014-10-14 omsai Carbon-Copy- Added omsai
    2014-10-10 svillemot Carbon-Copy- Added svillemot
    2014-09-18 ttl Dependencies- bugs #43247 is dependent
    2014-03-25 mtmiller Dependencies- bugs #41829 is dependent
    2014-02-09 asrv01 Carbon-Copy- Added asrv01
    2014-01-01 ttl Summarynative file dialogs extremely slow to open (~1 min) Conflicts between octave's SIGCHLD handler and qt process handling
    2013-10-22 rik5 Item GroupSegfault, Bus Error, etc. Other
        Summaryfile dialog causes crash native file dialogs extremely slow to open (~1 min)
    2013-05-29 rik5 Carbon-CopyRemoved 72865 -
    2013-05-24 ttl Open/ClosedClosed Open
    2013-03-20 rik5 Open/ClosedOpen Closed
    2013-03-10 ttl StatusNone Need Info

    Back to the top

    Powered by Savane 3.13-cf05.
    Corresponding source code