Tue 13 Dec 2016 08:13:13 PM UTC, comment #11:
if I run
octave --no-window-system
the code runs fine.
|
Thu 17 Nov 2016 06:07:05 PM UTC, comment #10:
It should be added that, since the segfault is in one of the two child processes, you should attach to a child process with gdb -p PID. For this, you can insert a 'pause (long_time)' as the first command into your function 'par_test'. Or better, as the second command, and the first command should print out the pid of the process (getpid, as mentioned in the last post), but set page_screen_output to false before doing this.
For clarity: run pararrayfun with your changed par_test, and from another terminal, attach with gdb to the printed out pid, before par_test finishes its 'pause()'. Then give the command 'run' from gdb and hope to see the caught segfault. Then 'bt'.
But in debugging parallel processes it can happen that the segfault doesn't occur under debugging conditions. I'd believe you have good chances if the segfault occurs even if you set nproc to 1 in pararrayfun. Then you should try the debugging with nproc==1.
|
Thu 17 Nov 2016 03:48:39 AM UTC, comment #9:
Try either "gdb octave-cli" or run Octave, and then attach gdb to it in a separate terminal (use getpid in Octave, and gdb -p PID to attach to the running process).
Updating release tag to 4.2.0, please update to 4.2.0 when you can since it has been released.
|
Wed 16 Nov 2016 02:29:28 AM UTC, comment #8:
I managed to install gdb. I run gdb octave and then inside gdb: r testing.m.
This gives:
parcellfun: 0/2 jobs donepanic: Segmentation fault: 11 -- stopping myself...
panic: Segmentation fault: 11 -- stopping myself...
warning: parcellfun: premature exit due to closed pipe
warning: called from
parcellfun at line 347 column 11
pararrayfun at line 85 column 26
testing at line 12 column 1
warning: broken pipe
warning: broken pipe
octave exited with signal 1
[Inferior 1 (process 10307) exited normally]
(gdb) bt
No stack.
(gdb)
Any ideas why there is no stack? Am I doing something wrong?
|
Thu 10 Nov 2016 04:29:41 PM UTC, comment #7:
I tried octave-cli and it gives the same error. No difference.
gdb is giving me a hard time, haven't managed to make it work yet.
|
Tue 08 Nov 2016 08:35:37 PM UTC, comment #6:
Have you tried octave-cli instead of "octave --no-gui" when logged in locally on the machine? They are not the same, "octave --no-gui" still starts a QApplication and runs the Octave interpreter on a secondary thread.
When you see the message "octave: no graphical display found" and "octave: disabling GUI features", that means that octave-cli is being run because it is running in a headless environment.
So again, the problem appears to me to be due to the use of fork in the parallel package when the interpreter is not the primary thread and it is running in a Qt context (even without the GUI).
If you have the gdb debugger, you can try running Octave in the way that causes it to segfault, attach to the process with gdb in a separate terminal, and then trigger the segfault. See http://wiki.octave.org/Debugging_Octave for some information on using gdb with Octave.
|
Tue 08 Nov 2016 07:36:19 PM UTC, comment #5:
This is becoming very strange. I have physical access to the Mac computer today. When I try to run the test code directly, it gives the old error:
parcellfun: 0/2 jobs donepanic: Segmentation fault: 11 -- stopping myself...
panic: Segmentation fault: 11 -- stopping myself...
warning: parcellfun: premature exit due to closed pipe
warning: called from
parcellfun at line 347 column 11
pararrayfun at line 85 column 26
testing at line 90 column 1
warning: broken pipe
warning: broken pipe
with both gui and no gui
If I access the Mac remotely from my Linux machine, and run octave testing.m, again I get:
parcellfun: 0/2 jobs donepanic: Segmentation fault: 11 -- stopping myself...
panic: Segmentation fault: 11 -- stopping myself...
warning: parcellfun: premature exit due to closed pipe
warning: called from
parcellfun at line 347 column 11
pararrayfun at line 85 column 26
testing at line 90 column 1
warning: broken pipe
warning: broken pipe
If I, additionally, logout from the Mac and login via ssh from my Linux machine, and run octave testing.m,
Nov 8 08:20:53 octave[1055] <Error>: Set a breakpoint at CGSLogError to catch errors as they are logged.
Nov 8 08:20:53 octave[1055] <Error>: This user is not allowed access to the window system right now.
octave: no graphical display found
octave: disabling GUI features
Nov 8 08:20:53 octave-cli-4.2.0-rc2[1055] <Error>: Set a breakpoint at CGSLogError to catch errors as they are logged.
Nov 8 08:20:53 octave-cli-4.2.0-rc2[1055] <Error>: This user is not allowed access to the window system right now.
parcellfun: 2/2 jobs done
So now it complains when starting octave, but the code runs fine. I am clueless.
About BLAS, I did otools -L /usr/lib/libblas.dylib this is what I get:
/usr/lib/libblas.dylib:
/System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1225.0.0)
I don't know how to check the stack on octave.
Does this help?
|
Tue 08 Nov 2016 07:31:04 PM UTC, comment #4:
> I want to help solve the issue.
Then can you please try to use the bug tracker web interface to participate?
|
Tue 08 Nov 2016 06:45:12 PM UTC, comment #3:
Ioan - your replies via direct email reply are not sent to the bug tracker, please copy the relevant details and submit them on the bug tracker web interface.
To summarize what you have provided privately, it sounds like octave-cli (Octave command-line only, no GUI threading) works fine for you, but segfaults when you try to use the parallel package with Qt loaded. If all you care about is running the interpreter in command mode, perhaps you should always use octave-cli for consistent results. Do you want to help resolve this problem beyond that point?
|
Sun 06 Nov 2016 09:05:48 AM UTC, comment #2:
As yet there was no reply to Mikes request for additional information. Especially the information regarding BLAS would be important for verification that this is the right track of thinking.
This would be not the first issue with threads in combination with 'fork' in parcellfun. I think here we are at the limit of what can be done with just 'fork'ing.
A solution would be a different way, similar to what is done in netcellfun, but with local servers, spawned with something like fork/ecexve.
I'm now planning to implement such an alternative solution, but it will be in a different function than parcellfun, maybe within netcellfun.
This alternative way could even make a Windows (non-cygwin) version theoretically possible, using CreateProcess, though I currently can't assess the possibilities for process communication there.
|
Fri 04 Nov 2016 09:32:46 PM UTC, comment #1:
Adding parallel package maintainer in cc.
A debug stack trace would probably be helpful here in discovering the reason for the segmentation fault.
Which BLAS library is being used? Does setting OMP_NUM_THREADS=1 in the environment before running Octave change anything?
|
Fri 04 Nov 2016 06:17:10 PM UTC, original submission:
--------------code---------------
pkg load parallel;
function par_test(t)
N=128;
A=randi(N,N);
B=randi(N,N);
A*B;
endfunction
pararrayfun(nproc, @par_test, 1:3, "UniformOutput", false)
--------------Error--------------
parcellfun: 0/2 jobs donepanic: Segmentation fault: 11 -- stopping myself...
panic: Segmentation fault: 11 -- stopping myself...
warning: parcellfun: premature exit due to closed pipe
warning: called from
parcellfun at line 347 column 11
pararrayfun at line 85 column 26
testing at line 90 column 1
warning: broken pipe
warning: broken pipe
--------------Info--------------
parallel version 3.1.1
-------------Comments----------
simply running par_test(1) works
running in parallel works for N<128, gives a seg fault for N>=128
running in parallel works on a Linux machine
|