I have a quick question about some demo code from the directshownet samples.
Is the following:
// Set the video to stream to pictureBox1
int hr;
hr = this.videoWindow.put_Owner(this.pictureBox1.Handle);
DsError.ThrowExceptionForHR(hr);
Preferable to:
// Set the video to stream to pictureBox1
DsError.ThrowExceptionForHR(this.videoWindow.put_Owner(this.pictureBox1.Handle));
for any reason? If so, why?
Cheers
Suppose the code is incorrect and the method fails with an error HRESULT. You likely will be debugging this code in the near future. In that situation, what do you prefer? Having to debug into ThrowExceptionForHR to examine the HRESULT that was returned, or putting a watch on the local hr?
I know which I would prefer.
Suppose the hr is only an error code sometimes. What do you prefer, putting a breakpoint inside ThrowExceptionForHR, or putting a conditional breakpoint on the caller that only breaks if the value stored in hr is an error code?
Again, I know which I would prefer.
Design your code to be easy to debug. You'll thank yourself later.
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.
has anyone experience the following issue?
A stack variable getting changed/corrupted after calling ne10 assembly function such as ne10_len_vec2f_neon?
e.g
float gain = 8.0;
ne10_len_vec2f_neon(src, dst, len);
after the call to ne10_len_vec2f_neon, the value of gain changes as its memory is getting corrupted.
1. Note this only happens when the project is compiled in release build but not debug build.
2. Does Ne10 assembly functions preserve registers?
3. Replacing the assembly function call to c equivalent such as ne10_len_vec2f_c and both release and debug build seem to work OK.
thanks for any help on this. Not sure if there's an inherent issue within the program or it is really the call to ne10_len_vec2f_neon causing the corruption with release build.enter code here
I had a quick rummage through the master NEON code here:
https://github.com/projectNe10/Ne10/blob/master/modules/math/NE10_len.neon.s
... and it doesn't really touch address-based stack at all, so not sure it's a stack problem in memory.
However based on what I remember of the NEON procedure call standard q4-q7 (alias d8-d15 or s16-s31) should be preserved by the callee, and as far as I can tell that code is clobbering q4-6 without the necessary save/restore, so it does indeed look like it's clobbering the stack in registers.
In the failed case do you know if gain is still stored in FPU registers, and if yes which ones? If it's stored in any of s16/17/18/19 then this looks like the problem. It also seems plausible that a compiler would choose to use s16 upwards for things it needs to keep across a function call, as it avoids the need to touch in-RAM stack memory.
In terms of a fix, if you perform the following replacements:
s/q4/q8/
s/q5/q9/
s/q6/q10/
in that file, then I think it should work; no means to test here, but those higher register blocks are not callee saved.
While decrypting I get the error : The operation couldnot be performed RNCryptorError 1
I dont understand what I am doing wrong. Here is my block of code
For anyone who might search here: this is a duplicate of RNCryptor#174, and you may want to read there as well.
Please just post code into the question rather than a screenshot. I can't compile a screenshot, and they're very hard to read.
Error 1 is an HMAC error. Either your data is corrupted or your password is incorrect.
Note that NSException never makes sense in Swift. Switch can't catch them. They only make sense in ObjC if you're going to crash the program shortly after. They're not memory-safe in ObjC. You meant to use Swift's throw and ErrorType, which are unrelated to raise or NSException.
I've recently become interested in trying to adapt my Rock-Paper-Scissors game into a multiplayer-friendly program, so today I decided I'd look up a tutorial on servers. It seems I'm following it precisely (aside from using a different IDE). However, something is going wrong and I'm not sure exactly what it is, and it works fine for the tutorial maker. I've looked up EOFException but it didn't exactly help me out.
The tutorial on Youtube
My screenshot of the issue.
[Documentation on EOFException](I had a link here, but I need at least 10 reputation to post more than two links)
"Signals that an end of file or end of stream has been reached unexpectedly during input.
This exception is mainly used by data input streams to signal end of stream. Note that many other input operations return a special value on end of stream rather than throwing an exception."
[A similar but apparently unresolved question asked here](I had a link here too]
By the way, if you look up exactly what I've posted here, you'll also find that I've asked it at DaniWeb. I'm just posting in multiple places in case it isn't resolved at one or the other. If it is, well... the more knowledge, the better.
EOFException during readUTF() just means it's reached the end of the stream, like it says on the tin. Note that this method doesn't return null at end of stream, unlike readLine() (but like all other readXXX() methods).
It can also mean that your sending and receiving is out of sync, e.g. you are trying to read some ridiculously large number of bytes because you left out a readInt() or similar, or you wrote something extra at the peer that you shouldn't have, so you're trying to read the next bytes in the stream as the result of writeUTF() when it isn't. This is an application protocol error.
How this happened in the code you posted is another question, but your code doesn't close the sockets, which doesn't help. Add an out.close() to your server code, and in.close() to the client code. However I cannot reproduce your problem with or without these closes. Are you sure this is the real code?
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.