- Undocumented Matlab - https://undocumentedmatlab.com -
Runtime code instrumentation
Posted By Yair Altman On September 28, 2017 | 3 Comments
I regularly follow the MathWorks Pick-of-the-Week (POTW) blog [1]. In a recent post [2], Jiro Doke highlighted Per Isakson’s tracer4m [3] utility. Per is an accomplished Matlab programmer, who has a solid reputation in the Matlab user community for many years. His utility uses temporary conditional breakpoints to enable users to trace calls to their Matlab functions and class methods. This uses a little-known trick that I wish to highlight in this post.
tracer()
that logs the function call (using dbstack) and always returns the value false
. He then dynamically created a string that contains a call to this new function and used the dbstop function to create a conditional breakpoint based on this function, something similar to this:
dbstop('in', filename, 'at', location, 'if', 'tracer()');
We can use this same technique for other purposes. For example, if we want to do some action (not necessarily log – perhaps do something else) when a certain code point is reached. The benefit here is that we don’t need to modify the code at all – we’re adding ad-hoc code pieces using the conditional breakpoint mechanism without affecting the source code. This is particularly useful when we do not have access to the source code (such as when it’s compiled or write-protected). All you need to do is to ensure that the instrumentation function always returns false
so that the breakpoint does not become live and for code execution to continue normally.
The tracer4m utility is quite sophisticated in the sense that it uses mlint and smart regexp to parse the code and know which functions/methods occur on which line numbers and have which type (more details [4]). In this sense, Per used undocumented functionality. I’m certain that Jiro was not aware of the dependency on undocumented features when he posted about the utility, so please don’t take this to mean that Jiro or MathWorks officially support this or any other undocumented functionality. Undocumented aspects are often needed to achieve top functionality, and I’m happy that the POTW blog highlights utilities based on their importance and merit, even if they do happen to use some undocumented aspect.
tracer4m‘s code also contains references to the undocumented profiler option -history
[5], but this is not in fact used by the code itself, only in comments. I use this feature in my profile_history utility [6], which displays the function call/timing history in an interactive GUI window. This utility complements tracer4m by providing a lot more information, but this can result in a huge amount of information for large and/or long-running programs. In addition, tracer4m has the benefit of only logging those functions/methods that the user finds useful, rather than all the function call, which enables easier debugging when the relevant code area is known. In short, I wish I had known about tracer4m when I created profile_history. Now that I know about it, maybe I’ll incorporate some of its ideas into profile_history in order to make it more useful. Perhaps another moral of this is that we should actively monitor the POTW blog, because true gems are quite often highlighted there.
Categories: Medium risk of breaking in future versions, Stock Matlab function, Undocumented feature
Article printed from Undocumented Matlab: https://undocumentedmatlab.com
URL to article: https://undocumentedmatlab.com/articles/runtime-code-instrumentation
URLs in this post:
[1] Pick-of-the-Week (POTW) blog: https://blogs.mathworks.com/pick
[2] recent post: https://blogs.mathworks.com/pick/2017/08/11/trace-your-calls-to-your-methods
[3] tracer4m: http://www.mathworks.com/matlabcentral/fileexchange/28929-tracer4m
[4] more details: http://undocumentedmatlab.com/blog/parsing-mlint-code-analyzer-output
[5] undocumented profiler option -history
: http://undocumentedmatlab.com/blog/undocumented-profiler-options-part-3
[6] profile_history utility: http://undocumentedmatlab.com/blog/function-call-timeline-profiling
[7] webinars on advanced Matlab topics: http://undocumentedmatlab.com/blog/advanced-matlab-online-webinars
[8] Parsing mlint (Code Analyzer) output : https://undocumentedmatlab.com/articles/parsing-mlint-code-analyzer-output
[9] Running VB code in Matlab : https://undocumentedmatlab.com/articles/running-vb-code-in-matlab
[10] A couple of internal Matlab bugs and workarounds : https://undocumentedmatlab.com/articles/couple-of-bugs-and-workarounds
[11] Controlling plot data-tips : https://undocumentedmatlab.com/articles/controlling-plot-data-tips
[12] Function call timeline profiling : https://undocumentedmatlab.com/articles/function-call-timeline-profiling
[13] Creating a simple UDD class : https://undocumentedmatlab.com/articles/creating-a-simple-udd-class
Click here to print.
Copyright © Yair Altman - Undocumented Matlab. All rights reserved.
3 Comments To "Runtime code instrumentation"
#1 Comment By Mark Whitfield On October 3, 2017 @ 14:07
Hello.
You mentioned that this technique could be useful for compiled code, but I thought that break points didn’t work in compilied code. Do you know of an undocumented work around?
Thank you for all the useful advice you post on this blog.
#2 Comment By Yair Altman On October 3, 2017 @ 21:03
@Mark – I meant p-coded code
#3 Comment By Mark Whitfield On October 4, 2017 @ 20:07
Thank you.