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.
|
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)
|
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.
|
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.
|
Tue 28 Jul 2015 07:29:54 PM UTC, comment #8:
Shouldn't it be possible to do
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.
|
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.
|
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).
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.
|
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
|
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.
|
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.
|
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.
|
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
|
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.
|