bugGNU Octave - Bugs: bug #50400, exit() in forked child doesn't...


bug #50400: exit() in forked child doesn't return

Submitter:  Olaf Till <i7tiol>
Submitted:  Sat 25 Feb 2017 04:42:14 PM UTC
Category:  Interpreter Severity:  3 - Normal
Priority:  5 - Normal Item Group:  None
Status:  None Assigned to:  None
Originator Name:  Olaf Till 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

Tue 02 Apr 2024 12:59:50 AM UTC, comment #8: 

This issue is caused by the presence of the Qt libraries.  If your application is solely doing data crunching, and not creating plots, then using the CLI version of Octave (octave-cli executable) which isn't linked with Qt will work.

I just tried original minimum working example and it passes cleanly with octave-cli.

Rik <rik5>
Group administrator
Mon 01 Apr 2024 09:55:13 AM UTC, comment #7: 

I was caught by this and can confirm the the workaround of comment #6 does work.

A couple of comments

- Could "fork() is discouraged" be mentioned in the Octave documentation on fork()?

- Perhaps exposing _exit(2) which exits immediately (without running exit handlers like exit(3)) could give an alternative fix, Ruby does this (see https://apidock.com/ruby/v2_5_5/Kernel/exit%21) -- that's in C99 (as _Exit()).

J.J. Green <jjg>
Sat 21 May 2022 02:37:04 PM UTC, comment #6: 

Maybe this is a suitable workaround:

Instead of calling exit(0); in the child process you could call exec("sh", {"-c", "exit 0"});

At least it seems to avoid that octave hangs after calling exit().

Wed 10 Feb 2021 07:03:51 PM UTC, comment #5: 

That's one of the problems that motivated reworking parcellfun() not to use fork(). I think this and other problems with fork()ing Octave sessions won't be fixed, instead, fork() is discouraged with Octave.

Olaf Till <i7tiol>
Group Member
Tue 09 Feb 2021 12:53:50 PM UTC, comment #4: 

Hi Olaf, I stumbled over this today and it's still present in 7.0.0 (hg id: 2a4998b97990). Have you found a workaround?

Andreas Weber <andy1978>
Group Member
Sat 25 Feb 2017 09:49:08 PM UTC, comment #3: 

Well, hacked a wrapper class around a QMutex*, adding a reinit method. But it seems I was wrong, and the problem is not with the mutex at all. The child doesn't hang in trying to lock the mutex.

Rather, it hangs in waiting for another thread to signal a condition (GUI shut down). It's clear that it must wait forever, since there is no further thread any more in the child.

So again, not clear what to do.

Olaf Till <i7tiol>
Group Member
Sat 25 Feb 2017 08:08:58 PM UTC, comment #2: 

At exit(), octave_qt_link::do_confirm_shutdown() tries to lock a QMutex (which, since it's constructed before forking, is unusable in the child).

QMutex is initialized at construction, doesn't provide a method for re-initialization, and has copying disabled. So it can't be made usable again in the forked child.

What can be done to prevent the child from deadlocking at exit()?

Olaf Till <i7tiol>
Group Member
Sat 25 Feb 2017 04:54:10 PM UTC, comment #1: 

Maybe something similar to the last patch in bug #47478 should be done, registering (with pthread_at_fork()) functions to be called at fork() time, which should care for the QT threads and (otherwise non-functional) QT mutexes in the child.

Olaf Till <i7tiol>
Group Member
Sat 25 Feb 2017 04:42:14 PM UTC, original submission:  

dev branch, 2bed6d6bb2e2, 2017-02-24 11:43:56-0800
with QT, started with ./run-octave, with or without option --no-gui.

After fork (i.e. the fork builtin), exit() in the child makes the child (and so the parents waitpid()) hang. Reproduce with:

function demo_exit_hangs ()
  if ((pid = fork) > 0)
    ## parent
    waitpid (pid);
  elseif (pid < 0)
    ## error
    error ("could not fork");
    ## child
    exit (0);

Backtrace of the hanging child:

#0  pthread_cond_wait@@GLIBC_2.3.2 ()
    at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1  0x00007f44ab041eab in QWaitCondition::wait(QMutex*, unsigned long) ()
   from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#2  0x00007f44b07e1fd1 in octave_qt_link::do_confirm_shutdown (this=0x12ba1b0)
    at libgui/src/octave-qt-link.cc:65
#3  0x00007f44aff3b458 in octave_link::confirm_shutdown ()
    at libinterp/corefcn/octave-link.h:96
#4  0x00007f44aff3656c in Fquit (args=...)
    at libinterp/corefcn/interpreter.cc:224

so it waits for some mutex in QT.

exit(0) in an unforked session works o.k..

Olaf Till <i7tiol>
Group Member


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

Attach Files:

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by jjg (Posted a comment)
  • -email is unavailable- added by andy1978 (Posted a comment)
  • -email is unavailable- added by i7tiol (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.


    Follows 1 latest change.

    Date Changed by Updated Field Previous Value => Replaced by
    2022-05-28 ineiev Carbon-CopyRemoved 0 -

    Back to the top

    Powered by Savane 3.13-4b48.
    Corresponding source code