I have a question about inner Matlab error management. Right now I have quite a large program with a lot of variables and functions that cumulated over my code writting and I'm 100 percent sure that I did not catch all the bugs and mistakes in the program and I don't want it to crash completely when is used by layman user. So, is there a way to display errordlg message and for example restart the program when there will be any given error directly by Matlab (for example when I forgot to declare a global variable etc.)?
Thanks for answers, Peter
Crashes are good, because they force users to report bugs.
If you don't want to go that route, Matlab provides try-catch: wrap your code in a try-catch block. If there is an error, you'll find yourself in the catch block where you can have Matlab send you an email with the error message, and restart the program if necessary.
You can use try/catch statements to respond to errors in your program. There's more information here.
Related
I'm working on a project based on the stm32f4discovery board using IAR Embedded Workbench (though I'm very close to the 32kb limit on the free version so I'll have to find something else soon). This is a learning project for me and so far I've been able to solve most of my issues with a few google searches and a lot of trial and error. But this is the first time I've encountered a run-time error that doesn't appear to be caused by a problem with my logic and I'm pretty stuck. Any general debugging strategy advice is welcome.
So here's what happens. I have an interrupt on a button; each time the button is pressed, the callback function runs my void cal_acc(uint16_t* data) function defined in stm32f4xx_it.c. This function gathers some data, and on the 6th press, it calls my void gn(float32_t* data, float32_t* beta) function. Eventually, two functions are called, gn_resids and gn_jacobian. The functions are very similar in structure. Both take in 3 pointers to 3 arrays of floats and then modify the values of the first array based on the second two. Unfortunately, when the second function gn_jacobian exits, I get the HardFault.
Please look at the link (code structure) for a picture showing how the program runs up to the fault.
Thank you very much! I appreciate any advice or guidance you can give me,
-Ben
Extra info that might be helpful below:
Running in debug mode, I can step into the function and run through all the lines click by click and it's OK. But as soon as I run the last line and it should exit and move on to the next line in the function where it was called, it crashes. I have also tried rearranging the order of the calls around this function and it is always this one that crashes.
I had been getting a similar crash on the first function gn_resids when one of the input pointers pointed to an array that was not defined as "static". But now all the arrays are static and I'm quite confused - especially since I can't tell what is different between the gn_resids function that works and the gn_jacobian function that does not work.
acc1beta is declared as a float array at the beginning of main.c and then also as extern float32_t acc1beta[6] at the top of stm32f4xx_it.c. I want it as a global variable; there is probably a better way to do this, but it's been working so far with many other variables defined in the same way.
Here's a screenshot of what I see when it crashes during debug (after I pause the session) IAR view at crash
EDIT: I changed the code of gn_step to look like this for a test so that it just runs gn_resids twice and it crashes as soon as it gets to the second call - I can't even step into it. gn_jacobian is not the problem.
void gn_step(float32_t* data, float32_t* beta) {
static float32_t resids[120];
gn_resids(resids, data, beta);
arm_matrix_instance_f32 R;
arm_mat_init_f32(&R, 120, 1, resids);
// static float32_t J_f32[720];
// gn_jacobian(J_f32, data, beta);
static float32_t J_f32[120];
gn_resids(J_f32, data, beta);
arm_matrix_instance_f32 J;
arm_mat_init_f32(&J, 120, 1, J_f32);
Hardfaults on Cortex M devices can be generated by various error conditions, for example:
Access of data outside valid memory
Invalid instructions
Division by zero
It is possible to gather information about the source of the hardfault by looking into some processor registers. IAR provides a debugger macro that helps to automate that process. It can be found in the IAR installation directory arm\config\debugger\ARM\vector_catch.mac. Please refer to this IAR Technical Note on Debugging Hardfaults for details on using this macro.
Depending on the type of the hardfault that occurs in your program you should try to narrow down the root cause within the debugger.
I am using websave function of MATLAB to download data from a website. The data is arranged by date. I have put the date in a loop to run the code for a certain period of time. However, on some dates, there is no data available. For those dates, the program halts and give 'internal error'.
I want to know how can I download data without interruptions even if there is missing data on some dates avoiding this internal error.
First of all, that sounds like a very poorly designed API if you're getting internal errors for an empty query result. Maybe there is a better way to make the call that you need? If you show some more code maybe we can help you.
That being said, you can use the try/catch construct to surround the call to websave, that way if it throws an error, it will not interrupt the flow of your program.
for k = date_range
try
websave(filename, url);
catch
% There was some error
disp('Skipping this one!')
end
end
Perl currently implements $SIG{__DIE__} in such a way that it will catch any error that occurs, even inside eval blocks. This has a really useful property that you can halt the code at the exact point where the error occurs, collect a stack trace of the actual error, wrap this up in an object, and then call die manually with this object as the parameter.
This abuse of $SIG{__DIE__} is deprecated. Officially, you are supposed to replace $SIG{__DIE__} with *CORE::GLOBAL::die. However, these two are NOT remotely equivalent. *CORE::GLOBAL::die is NOT called when a runtime error occurs! All it does is replace explicit calls to die().
I am not interested in replacing die.
I am specifically interested in catching runtime errors.
I need to ensure that any runtime error, in any function, at any depth, in any module, causes Perl to pass control to me so that I can collect the stack trace and rethrow. This needs to work inside an eval block -- one or more enclosing eval blocks may want to catch the exception, but the runtime error could be in a function without an enclosing eval, inside any module, from anywhere.
$SIG{__DIE__} supports this perfectly—and has served me faithfully for a couple of years or more—but the Powers that Be™ warn that this fantastic facility may be snatched away at any time, and I don't want a nasty surprise one day down the line.
Ideally, for Perl itself, they could create a new signal $SIG{__RTMERR__} for this purpose (switching signal is easy enough, for me anyway, as it's only hooked in one place). Unfortunately, my persuasive powers wouldn't lead an alcoholic to crack open a bottle, so assuming this will not happen, how exactly is one supposed to achieve this aim of catching runtime errors cleanly?
(For example, another answer here recommends Carp::Always, which … also hooks DIE!)
Just do it. I've done it. Probably everyone who's aware of this hook has done it.
It's Perl; it's still compatible going back decades. I interpret "deprecated" here to mean "please don't use this if you don't need it, ew, gross". But you do need it, and seem to understand the implications, so imo go for it. I seriously doubt an irreplaceable language feature is going away any time soon.
And release your work on CPAN so the next dev doesn't need to reinvent this yet again. :)
On a recent post I was told that there are differences between the way parallel toolbox handles warnings and the way regular matlab deoes it. I felt that poster hand gone someway to answering my question so I marked it as answered. But I still have some additional questions (hope this doesn't contitute double posting).
Error only triggers when I don't use parfor?
I just wondered if someone can explain to me what these differences are?
Also what is meant by parfor being sandboxed?
Is it still possible to use try catch type structures with the parallel tool box or using some other mechanism to chain the same thing?
To be clear when I run using parfor warning messages are still produced telling me the matix is illconditioned but it doesn't seem to be being picked up as an error despite me adding the lines
warnState(1) = warning('error', 'MATLAB:singularMatrix');
warnState(2) = warning('error', 'MATLAB:illConditionedMatrix');
However, when I run using a regular for loop it is picked up as an error.
So the parallel tool box is producing the warnings correctly its just not translating them into errors via the code above so they can be used in a try catch structure.
Kind Regards
Hugh
I think the problem in your original code is that you changed the warnings to errors on the MATLAB client only. To make that change on the workers, you need to do
spmd
warnState(1) = warning('error', 'MATLAB:singularMatrix');
warnState(2) = warning('error', 'MATLAB:illConditionedMatrix');
end
There's also the pctRunOnAll function to run things everywhere.
Also, I don't know what the OP meant about matlabpool workers being 'sandboxed'. The differences between your MATLAB client and the workers are:
The workers always run in single threaded mode; and
The workers run with no display (although they can produce off-screen graphics and save to file)
I have a requirement.
I am processing some files and after the processing are done I am archiving those files into an archive folder with timestamp appended.
The file archiving and putting time stamp portion I am doing in the Finally block. Now a new requirement has come where I need to mail if something wrong goes in the original files and then I need to archive the same. Now this piece of code I need to handle in the catch block.
But if I write the code entirely in the catch block, then it will fire only if there is an exception; otherwise not.
So basically I am writing the same pice of code in both the catch and finally block.
What is the standard and recommended approach you people think will be better in this case?
I am using C#3.0
Thanks.
A finally block is really for code that "always" has to run, even after an exception. This typically means cleanup type code. It's a "code smell" to see processing type code in a finally block.
Maybe you can post your code, and we can suggest a better way for you.