how to set breakpoint at Mutex#lock? - rubymine

I'm trying to set a breakpoint every time Mutex#lock is called in RubyMine, but since mutex.rb is a stub I can't seem to do it. Anybody know how I would do this?

I ended up just defining the following in a file and putting breakpoints there:
class Mutex
alias real_lock lock
alias real_synchronize synchronize
def lock
real_lock
end
def synchronize &block
real_synchronize &block
end
end

Related

How to clear persistent variables in sub-functions

I have a script that calls a function, which is written in separate file and contains sub-functions that are inner to main function only. In one of my sub-functions, I have persistent variable that I would like to clear every time I run the main script. How can I do so? In addition, I have breakpoints through my code, and I would prefer to keep them while I clear the persistent variable - how that can be done?
MainScript.m script:
clear variables;
for iterNum=1:5
dataOut = MyMainFunction(iterNum);
end
disp(dataOut);
MyMainFunction code:
function dataOut = MyMainFunction(iterNum)
if (iterNum==1)
clear MySubFunction;
end
dataOut = MySubFunction();
end
function dataOut = MySubFunction()
persistent idx;
if isempty(idx)
idx=1;
end
dataOut=idx;
idx=idx+1;
end
I would like to clear "idx" persistent variable every time that I run MainScript.m, but of course to keep that variable as long as the script is running.
Thanks, John
The easiest way I see is to call clear followed the function name:
clear MySubFunction
instead of
clear variables;
This should clear all the persistent variables in that particular function. This will probably have the side effect of removing the stored JIT'd copy of it, causing it to be reparsed the next time it is invoked.
You can use munlock if you previously mlock'ed your function.
OR
You can define a special set of parameters in your function that are designed to solely clear the persistent variable, and you call the function with this syntax at the beginning of your main file.
Unfortunately, the other answer is partially incorrect - it is NOT possible to clear persistent variables in a sub-function using clear MySubFunction.
To quote an answer by a MathWorks staff member,
Only top level or main functions (with the same name as the file) may be cleared. To clear any local or nested function the main function must be cleared and that can't be done while the main function (or any other function in the file) is running.
and
Only whole m files can be cleared from memory. The entire file is managed as a unit so sub functions can't be cleared without clearing the main function.
As such, your options are to
separate the sub-function into its own m-file, or
clear the entire MyMainFunction from within MainScript.m, or
follow Ratbert's second suggestion, i.e. instead of using clear, give MySubFunction an additional argument that tells it to reset the persistent variables by itself

Error message while using Test::MockObject->fake_module

I have inherited a perl project that I am having a problem testing. There are existing tests, and one of them uses the Test::MockObject->fake_module function. This test passes now. However, if I add a use (or use_ok) for an additional testing module (which also works ok in different tests), I am getting the following:
No mocked subs for loaded module 'IO::File'
In the test in question we have this:
my $io_file_mock = Test::MockObject->new();
$io_file_mock->set_isa('IO::File', 'IO::Handle');
$io_file_mock->set_true('flush', 'print');
$io_file_mock->fake_module('IO::File');
$io_file_mock->fake_new('IO::File');
I see in the documentation for MockObject->fake_module that this is written:
If you use fake_module() to mock a module that already exists in memory -- one you've loaded elsewhere perhaps, but do not pass any subroutines to mock, this method will throw an exception. This is because if you call the constructor later on, you probably won't get a mock object back and you'll be confused.
Not sure I understand this message and how I can make my test work.
Can anyone please help me?
Thanks
Solved in the comments:
I was able to solve my problem by putting the above code in a separate BEGIN block before the BEGIN block that calls my use_ok calls. Is there any problem with that? - Mark
A BEGIN code block is executed as soon as possible, that is, the moment it is completely defined, even before the rest of the containing file (or string) is parsed.
If the use_ok method that was failing is in a BEGIN block and it depended other variables, then those dependent variables would need to be initialized in a BEGIN block as well or they would be temporarily undef when use_ok was called.
For more information read: BEGIN, UNITCHECK, CHECK, INIT and END

How to place a breakpoint at the start of a method programmatically?

In Matlab, when I want to run a function through the debugger, I can type dbstop func, which puts a breakpoint at the first code line in func.m. Then, when I call func(...), I can proceed through the function step by step.
Is there any equivalent for methods? If I want to debug into an interactive call of obj.meth(), none of these alternatives work:
dbstep in only works if the code to be stepped into is part of the function I'm debugging, not if I'm calling it interactively
dbstop obj.mymeth, dbstop MyClass/mymeth, or dbstop MyClass.mymeth fail with Cannot find function MyClass.mymeth.
So, perhaps it's treated like a subfunction. However, dbstop in MyClass at mymeth fails with Cannot find function "mymeth" within "MyClass". This one actually surprises me most. Note that even if it would work, I would still need to find out the defining class first.
dbstop mymeth actually does set a breakpoint, but it sets it at line 1 of MyClass, rather than at the beginning of MyClass.mymeth. I have not tested what happens if mymeth is overloaded.
Next, I tried it through the metaclass and metamethod: ms = ?MyClass; meth = ms.MethodList(strcmp({ms.MethodList.Name}, 'mymeth'))
, gives me an meta.method object to my method. However, dbstop wants a string, so I can't put a breakpoint. And although the meta.method does tell me the defining class, it does not tell me the line number where the method is defined, so I can't set a breakpoint like this either.
Then, all that is left is to determine the defining class from the meta.method, open the corresponding file in the graphical interactive editor, search for the line defining the method, and put a breakpoint by hand. This is time-consuming and only works when working graphicaly.
Is there any way to step into an interactively called method, or to programmatically set a breakpoint at the beginning of a method? I'm using 2013a.
The following syntax worked for a simple test on my computer:
dbstop in MyClass.m at MyClass.mymeth

Stop execution (breakpoint) every time the execution enter in one of my classes

Is there any way to stop the execution EVERY time the app enter in one of my classes?
The equivalent would be to put a breakpoint in every single entry point of my class (for ex. viewDidLoad, viewDidAppear...) Sometimes I just need to capture every time my class is called, and I dont know which one is the entry point, so I was obliged to put a breakpoint in every entry point.
Is there any way to automatize this?
Don't know about a class but maybe this can help you.
Setting the breakpoint on a file.

In Eclipse, is there a way to disable a breakpoint until another breakpoint is hit first?

In Eclipse, is there a way to disable a breakpoint until another breakpoint is hit first?
This is a big hack, but it is a functional workaround:
Call the 'trigger' location breakpoint 1 and the target location breakpoint 2. We want breakpoint 2 to fire if-and-only-if execution has passed breakpoint 1.
Set conditional breakpoints at each.
For breakpoint 1, set the condition as System.setProperty("breaknow", "breaknow") == "". This condition will never be true, but will set a system property which we can read at breakpoint 2.
For breakpoint 2, set the condition as System.clearProperty("breaknow") != null. This condition will trigger when the system property is set, and also clear it (so we can repeat if needed).
As I said, it's a hack, but it seems to work. I submitted an Eclipse enhancement request to implement linking or chaining breakpoints as a native feature (https://bugs.eclipse.org/bugs/show_bug.cgi?id=390590). Unfortunately, I don't have bandwidth to implement it myself, but perhaps we'll get support for a cleaner solution someday.
One caveat (which applies to all conditional breakpoints, not just to this trick): From my experience, it appears that a setting a conditional breakpoint prevents the JIT from compiling the method of interest, running it in interpreted mode instead. Or perhaps, it allows the first C1 JIT stage but prevents the second-stage C2 compiler from optimizing?
In either case, you should be aware that the method you’re debugging will run considerably slower with a conditional breakpoint in place. This isn’t usually a problem, but when debugging very tight inner loops, I’ve found it better to fall back to the (sloppy) if (x) { // Do somthing useless and set a breakpoint here} method.
No. But you can have conditional breakpoints. I guess that hitting the other breakpoint indicates some change of state.
So, Right click the breakpoint -> Breakpoint properties -> check "conditional"
If you know the condition at which the other break point will be hit, then you can add that condition to the new breakpoint.
Conditional breakpoints are one possibility, and you can also set a Hit Count so that the breakpoint is only triggered after being hit the specified number of times.
But no, there is no way to do what you are asking.
Another idea is to disable your breakpoint and enable it once the other breakpoint is hit.