Problem with debugger (Heisenberg Uncertainty Principle?)

I'm having a problem with my debugger not syncing up with what my program actually does. Specifically when I run my program I find some problems with the output, but when I enter the debugger and run it, I find the output at the end is exactly what I want. It's as if attempting to observe the problem makes it disappear (HUP).

My code is quite complicated, and the potential error could be occurring (and not occurring) in any one of many places, so I've decided not to post any code snippets. Since it works in the debugger, I assume my code itself is sound and the problem lies with Matlab somehow. I can tell you that is a GUI and that the general problem lies in updating the handles object. I am using Matlab r2006b on Windows 7 64 bit.

Has anyone else experienced a problem like this?

Answer 1

[Lukas]

Thanks guys for the answers. I solved the problem. It was an issue with the guidata function. I was calling guidata(gcf, handles) and when I was in debug mode gcf was the figure I wanted, however when I was out of debug mode gcf was something else (not sure what). The correct call that I'm now making is guidata(handles.figure1, handles).

[Jan]

Fine! Assuming that GCA or GCA is a specific object is dangerous. I've seen a funny visualizations drawn inside the axes, which holds the icon of a warning message, which was created by a timer running in the background.

An equivalent problem is the current directory, which can be changed by another thread of the same program. Therefore absolute filenames are recommended ever, ever, ever.

Avoiding these pitfalls can save hours of debugging.

Answer 2

[Jan]

You can cheat the debugger with several smart tricks:

x = 1:10;
disp(mean(x));
eval('mean = rand(1, 10);');
disp(mean(x));

During debugging the symbol "mean" changes its meaning. But if the code is interpreted by the JIT acclerator, (at least some versions of) Matlab convert the "mean" in the last line to a pointer to the MEAN function before running the code, such that the poofed variable "mean" will not be used.

The same can happen for ASSIGNIN. My old Matlab 6.5 had even problems, when the upper/lowercase of the poofed variable did not match the name of a built-in function. Assigning "RANK" dynamically (by the evil EVAL or ASSIGNIN) caused a crash, when Matlab thoughts the built-in "rank()" was meant. In Matlab R2009a the confusion happens only with matching case.

Do you have any EVAL, EVALIN or ASSIGNIN in your code? If so, either give up debugging or remove them carefully. There is always a better method.

Alternative: Matlab's JIT had some bugs in its early times. R2006b can be called "historical". You can try to disable it temporarily:

feature('accel', 'off')
feature('jit', 'off')

But upgrading could be a more convenient, efficient and progressive idea. However, let me mention that I know a bunch of good reasons to avoid upgrading also.

Answer 3

[Image Analyst]

For what it's worth, I have seen weird things in prior versions before, like it throwing an exception on a particular line if I run the program, but not if I set a breakpoint on that line and then continue once I've stopped there. Or having a simple innocuous fprintf() that prints out some debug info for some inexplicable reason fix the code, but the code didn't work if the fprintf was commented out. Sorry, I don't remember the versions, or exact circumstances or the fixes, if I found any.

Answer 4

[choma community]

i dont know build gui from this my work...please help me to do me work please download this link below and correctly my work...thanks before

http://www.mediafire.com/?jwot8cqttyvpyj5