bugGNU Octave - Bugs: bug #45625, fork() hangs on interaction with...

 
 

bug #45625: fork() hangs on interaction with Qt libraries

Submitter:  Ceral Paquet <octavebugs>
Submitted:  Sat 25 Jul 2015 11:29:31 AM UTC
   
 
Category:  Octave Function Severity:  3 - Normal
Priority:  5 - Normal Item Group:  None
Status:  Confirmed Assigned to:  None
Originator Name:  Open/Closed:  * Open
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

Thu 25 Feb 2016 05:54:48 AM UTC, comment #12: 

Oops.  I forgot all about this report and just committed a patch to disallow forks on the command line (http://hg.savannah.gnu.org/hgweb/octave/rev/980abb267014).  It can be backed out if jwe or Mike really want the feature.

Rik <rik5>
Group administrator
Thu 06 Aug 2015 05:30:11 PM UTC, comment #11: 

I'm re-titling to reflect the remaining issue which is the interaction between fork and Qt.  I've uploaded Mike's test function from comment #6 as fork_test.m for anyone who wants to play around with this.

(file #34582)

Rik <rik5>
Group administrator
Tue 28 Jul 2015 08:33:49 PM UTC, comment #10: 

I'm personally not a fan of safety features that get in the way of utility, and this looks like it could be useful for experimentation, so in my opinion we should let fork be called.

As a point of comparison, a Python interactive shell lets me call os.fork(), and the terminal seems to be in control of the child process most times, so I can then sys.exit(), but os.waitpid(0,0) says I have no child processes.

My point being it's not at all friendly or well-defined what an interactive shell should do or could do to handle fork better, but why not let users call it if they know what they're doing?

So that just leaves the problem of Qt causing our waitpid function to hang.

Mike Miller <mtmiller>
Group Member
Tue 28 Jul 2015 07:41:12 PM UTC, comment #9: 

I don't think we lose much by restricting fork to scripts, rather than the top-level command line.

A normal usage of fork is that the child process goes off and does a lot of work.  But if you are using fork on the command line you're not going to type a long script in to the child portion of the if/else branch.  1) it's tedious, 2) you might have a typo and it's a pain to rework a long block on the command line, and 3) the code to execute is usually something you might want to invoke again, and that means you would want to collect it into a block in an m-file anyways.

But that's just my opinion.  We could also just ignore this as I think it is pretty uncommon usage.

Rik <rik5>
Group administrator
Tue 28 Jul 2015 07:29:54 PM UTC, comment #8: 

Shouldn't it be possible to do


pid = fork (); if (pid) [~, sts] = waitpid (pid); else pause (3); exit (3); endif


at the command line?  I know weird things can happen if you fork and the child doesn't exit or exec, but this is a power tool so I think it would still be handy to allow this kind of experimentation directly at the command line.

If we really want a safe mode for things like fork or other potentially confusing or dangerous functions, then maybe we should have something like the way Emacs allows certain commands to be disabled for novices.

John W. Eaton <jwe>
Group administrator
Tue 28 Jul 2015 04:07:36 AM UTC, comment #7: 

I think we should break this bug in to two parts.  One is just related to calling fork from the command line and can stay in this report.  The other half is the newly discovered problem with fork and the Qt libraries.

Rik <rik5>
Group administrator
Tue 28 Jul 2015 02:46:39 AM UTC, comment #6: 

So besides Rik's point about making the fork function error if a user tries to call it from the top level, there is another lower-level bug here with fork and the Qt libraries.

The following script works fine for me with --no-gui-libs (octave-cli), but hangs as Ceral describes when I run it in the GUI or with --no-gui (meaning Qt's event loop is still running).


function fork_test ()
  pid = fork ();
  if (pid != 0)
    printf ("waiting for child process %d…", pid);
    fflush (stdout);
    [~, sts] = waitpid (pid);
    printf (" done: %d\n", WEXITSTATUS (sts));
  else
    pause (3);
    exit (3);
  endif
endfunction


I think this hang may be related to bug #38305, where it was observed that there is some interference between the way Octave and Qt both want to manage child processes. I don't have an exact explanation but it certainly seems related.

Mike Miller <mtmiller>
Group Member
Sun 26 Jul 2015 11:45:39 AM UTC, comment #5: 

Hi Mike - thanks for the tip. I added an exit but still get a hang. The script below causes it for me.

>> ver

----------------------------------------------------------------------
GNU Octave Version: 4.0.0
GNU Octave License: GNU General Public License
Operating System: Linux 3.16.0-44-generic #59~14.04.1-Ubuntu SMP Tue Jul 7 15:07:27 UTC 2015 x86_64
----------------------------------------------------------------------
no packages installed.



%% - causes a hang --- %%
function  fork_test()

[pid, msg] = fork();

if pid
# wait child to complete
disp(["waiting for ", num2str(pid)]);
% do some useful work
%plot(1:10)
waitpid(pid)
else
% do some useful work
%A = randn(100);
%pause(10);
exit();
endif


Ceral Paquet <octavebugs>
Sat 25 Jul 2015 03:05:25 PM UTC, comment #4: 

Ha, ok I'll set back to confirmed if you think some safety valve is in order.

Mike Miller <mtmiller>
Group Member
Sat 25 Jul 2015 03:04:21 PM UTC, comment #3: 

The help for the fork function contains the following:

>  0
>       You are in the child process.  You can call 'exec' to start
>       another process.  If that fails, you should probably call
>       'exit'.


So your "else" case should have either an exec() or an exit() in it after it does something useful. If the child process does not exit, the waitpid() call in the main process will block.

Everything looks like it's working as expected to me.

Mike Miller <mtmiller>
Group Member
Sat 25 Jul 2015 03:00:10 PM UTC, comment #2: 

Good catch.  I don't think the fork command should be allowed at the top-level command line.  What you are seeing seems to be the parent and child both competing to receive input from the keyboard.  I believe a simple fix is to change the fork DEFUN in syscalls.cc to check whether Octave is at the top-level.  I thought I could just use the function at_top_level() from symtab.h, but it fails to compile.  I'm CC'ing jwe because he will know the correct function to use.

Rik <rik5>
Group administrator
Sat 25 Jul 2015 12:04:03 PM UTC, comment #1: 

More fork weirdness causing octave to hang.

>> A=fork_test(); % this seems to work, it returns and I get a plot

waiting for 6261

>> figure % this does nothing
>> figure 2 % ditto
>> close all % ditto
>>
>>
>>
>>
>>
>> exit % doesn't work - we're stuck



The function is below. Again, there isn't much info on how to use fork so this is a bit of guesswork.



function A = fork_test()

[pid, msg] = fork();

if pid
  # wait child to complete
  disp(["waiting for ", num2str(pid)]);
  % do some useful work 
  plot(1:10)

  waitpid(pid)
else
  % do some useful work
  A = randn(100);
  pause(10);
endif


Ceral Paquet <octavebugs>
Sat 25 Jul 2015 11:29:31 AM UTC, original submission:  

Let me preface this by saying I don't know what I expected to happen.

Typing fork at the command prompt renders octave unusable - it's impossible to type in any commands as they break up as you type them, leaving a few letters which give syntax errors.

Ceral Paquet <octavebugs>

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #34582:  fork_test.m added by rik5 (262B - text/x-objcsrc)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by mmuetzel (Updated the item)
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by rik5
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by octavebugs (Submitted the item)
  •  

    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 10 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2020-12-02 mtmiller Carbon-CopyRemoved 80942 -
    2020-12-02 mmuetzel Release4.0.0 dev
    2015-08-06 rik5 Summaryfork on command line fork() hangs on interaction with Qt libraries
    2015-08-06 rik5 Attached File- Added fork_test.m, #34582
    2015-07-25 mtmiller StatusWorks For Me Confirmed
    2015-07-25 mtmiller CategoryInterpreter Octave Function
        StatusConfirmed Works For Me
    2015-07-25 rik5 Carbon-Copy- Added jwe
    2015-07-25 rik5 CategoryNone Interpreter
        StatusNone Confirmed

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code