Certain Matlab scripts crash when I try to exit them from the command line, or when I put an "exit force" in the script. (The weird thing is I have not been able to determine what causes some programs to crash and some not to.) So e.g. here is a very simple Matlab program (bugtest.m) which exhibits this behaviour, on Mac OS:
function bugtest(ifile, ofile)
data = csvread(ifile, 1, 0); % skip the first line
csvwrite(ofile, data);
end
When I Matlab this script from the command line, and then type exit when I get the Matlab prompt, it works fine:
bash> /Applications/MATLAB_R2018b.app/bin/matlab -nodisplay -nojvm -r "bugtest('z2.csv','z3.csv')"
[Matlab copyright message]
>> exit
exit
But when I include the exit on the command line, it crashes (depending on the script, but the script bugtest.m always crashes):
bash> /Applications/MATLAB_R2018b.app/bin/matlab -nodisplay -nojvm -r "bugtest('z2.csv','z3.csv');exit"
[Matlab copyright message]
--------------------------------------------------------------------------------
Segmentation violation detected at Thu Aug 22 15:55:40 2019 +0930
--------------------------------------------------------------------------------
Configuration:
Crash Decoding : Disabled - No sandbox or build area path
Crash Mode : continue (default)
[etc]
The same thing happens if there is an "exit force" inside bugtest.m. And yet other Matlab scripts work fine from the command line.
What is the cause of this problem, and how do I fix it?
To me this looks like a timing issue, where one thread is still finalizing writing to the file while another thread starts to tear down the runtime. I say this because when manually typing exit, some time has passed after running csvwrite, and the error doesn't occur.
One can simulate this situation in a script by adding a small pause, for example pause(1), before calling exit.
Obviously this is a bug that should be reported to the MathWorks so they can fix it.
Related
On a i686 / 32-bit dual CPU, with a fresh Debian Stretch installation, I've installed Octave 4.2.1 and run ./mytest after providing it with execution privileges:
#!/bin/bash
./mytest.m
where test.m reads
#!/usr/bin/octave
exit(0)
The result is:
Terminate called after throwing an instance of 'octave::exit_exception'
panic: Aborted -- stopping myself...
attempting to save variables to 'octave-workspace'..
save to 'octave-workspace' complete
octave exited with signal 6
but the program is intended to exit normally. Same result replacing exit with quit, but it terminates correctly when starting it with $ octave -q --no-gui and then > quit. What's wrong here?
Update: In the meanwhile, this showed up: http://savannah.gnu.org/bugs/?49271, so now the question would be: can a non-Octave configuration solve the problem? (Confirmed: Octave 4.0.0 does not reproduce the error.)
When running a bash script like source script or . script from the command line, then all the lines in the script are added to bash's "source buffer" and then the current command shell just continues. Stopping execution is impossible (apart from aborting the shell), using ctrl-C only interrupts the current command, but then the next command is executed.
Where is this buffer, and would it be possible to clear it??
Example script:
echo A
sleep 10
echo B
sleep 10
echo C
sleep 10
echo D
After having done "source script", is there any way to stop it executing any further after it has been 'submitted'?
There is - to the best of my knowledge - no such thing as a source buffer in bash, so there is nothing to erase. The source command just executes the commands found in its arguments in the current environment (i.e. not in a child process).
There is nothing in the handling of source which is in particular related to the handling of signals. Maybe your shell script is setup to ignore Control-C? I suggest that you run your script with -x in order to find the culprit.
I am trying to debug a concurrent program in LLDB and am getting a seg fault, but not on every execution. I would like to run my process over and over until it hits a seg fault. So far, I have the following:
b exit
breakpoint com add 1
Enter your debugger command(s). Type 'DONE' to end.
> run
> DONE
The part that I find annoying, is that when I get to the exit function and hit my breakpoint, when the run command gets executed, I get the following prompt from LLDB:
There is a running process, kill it and restart?: [Y/n]
I would like to automatically restart the process, without having to manually enter Y each time. Anyone know how to do this?
You could kill the previous instance by hand with kill - which doesn't prompt - then the run command won't prompt either.
Or:
(lldb) settings set auto-confirm 1
will give the default (capitalized) answer to all lldb queries.
Or if you have Xcode 6.x (or current TOT svn lldb) you could use the lldb driver's batch mode:
$ lldb --help
...
-b
--batch
Tells the debugger to running the commands from -s, -S, -o & -O,
and then quit. However if any run command stopped due to a signal
or crash, the debugger will return to the interactive prompt at the
place of the crash.
So for instance, you could script this in the shell, running:
lldb -b -o run
in a loop, and this will stop if the run ends in a crash rather than a normal exit. In some circumstances this might be easier to do.
I'm still pretty new to bash scripting, and I'm having a hard time figuring out why this simple trap is not working as expected.
Goal - create an optional waiting period that can be skipped by pressing CTRL+C.
Expected result of pressing CTRL+C - immediately echo "No time for napping!" and exit.
Actual result of pressing CTRL+C - immediately echo "naptime over." and exit.
#!/bin/bash
nonap() {
echo "No time for napping!"
exit
}
trap nonap INT
echo "Sleeping for 5 seconds, hit ctrl-c to proceed now."
sleep 5
echo "Naptime over."
Why is my trap function not invoked?
I just tried it (on an ancient RHEL Linux with bash 3.2.25) and saved your code in trap.sh, ran bash trap.sh, and got:
Sleeping for 5 seconds, hit ctrl-c to proceed now.
followed by:
No time for napping!
when I interrupted, as you expected. When I let it run without interrupting, I got the expected message:
Naptime over.
You then commented:
At least I know it should work as expected. I'm using the latest version of Tinycore Linux with GNU bash, version 4.0.33(1)-release (i686-pc-linux-gnu). Upon opening a new terminal, declare -f nonap and trap both return no output. After running this script and getting the "Naptime over." output, trap returns trap -- 'nonap' SIGINT and declare -f nonap returns the function as defined in my script.
To which I responded:
How are you running this script, then? Using source or . to read it? Ah, yes; you must be. I just tried that, and the interrupt while sourcing gave me Naptime over.; typing another interrupt though gave me No time for napping! and the shell exited. The second time it behaved as expected; I'm not sure what's up with the interrupt while dotting the script. That is unexpected behaviour.
Why did you want to source or dot this? Why not just use it as a plain old script?
No reason to source...I was just using that to run it while testing. I guess I've never run into any anomalies like this when using . before, but I'm still a newb too. I am seeing the same results you are, and it works as expected on the first interrupt if I run it with bash.
Well, there's a "Doctor, Doctor, it hurts when I hit my head against the wall" component to the following advice, but there's also basic pragmatism in there too.
You use source (in C shell or bash) or . (in Bourne, Korn, POSIX shells or bash) to have the script affect the environment of the invoking shell, rather than running as a sub-shell. The giveaway to solving the problem (albeit largely by fluke) was when you reported that after running the script, you had the function defined; that can't happen unless you were using source. In this case, it is fairly clear that you do not want the trap set in the calling shell. When I ran it (from a ksh with prompt Toru JL:), I got:
Toru JL: bash
bash-3.2$ trap
bash-3.2$ source trap.sh
Sleeping for 5 seconds, hit ctrl-c to proceed now.
Naptime over.
bash-3.2$ trap
trap -- 'nonap' INT
bash-3.2$ No time for napping!
Toru JL:
The 'No time for napping!' message appeared when I hit the interrupt key again, and it terminated the bash I'd run. If you continue to use it with source, you would want to add trap INT to the end of the script, and you might also want to undefine the the function.
However, you are much better off isolating it all in a shell and running it as a sub-process, I think.
But...your finding that this sort of thing plays funny games when the script is sourced is interesting. It's a minor anomaly in the behaviour of bash. I'm not sure it rises to the level of 'bug'; I'd have to read a lot of manual rather carefully (probably several times) and consult with other knowledgeable people before claiming 'bug'.
I'm not sure it will be any consolation, but I tried ksh on your script with . and it worked as we'd both expect:
Toru JL: ksh
$ . trap.sh
Sleeping for 5 seconds, hit ctrl-c to proceed now.
No time for napping!
Toru JL:
How do I allow my Matlab script to pass back a return code to the Task Scheduler? I currently have a task that runs "matlab -r myscript". The problem is the Task Scheduler always succeeds immediately after starting, even though myscript takes several minutes to run. So, I don't see how to pass back an error code.
How can I make Task Scheduler wait until the script stops running and then get matlab to pass back a return code?
Use the matlab -wait command line option to have it block until the program is finished.
There appears to be an undocumented argument to quit() to set the exit status - e.g. quit(42) - which then shows up in %ERRORLEVEL%. Since it's undocumented, you might not want to rely on it. Alternatively, have your script write its status to a file and have a wrapper script parse it.