Simultaneous breakpoint custom probes?

[Aristos Queue]

At some point, a debug problem becomes so thorny that a programmer must declare that the current debug tools are insufficient and spend time writing new tools before proceeding. In my current hobby-at-home project, I've hit that point. I spent this entire weekend writing a couple of tools for tackling parallel debugging.

One tool that I haven't written (yet) is a custom probe to simultaneously pause parallel VIs, and I want to know if anyone has already written such a beast and would share it so I don't have to build it.

What I'm imagining is this:

A custom probe that has on its panel an array of paths to other VIs. When the custom probe trips, it passes True for its boolean output (to pause the running VI) and it also calls Pause VI method on all the VIs listed in the array. There would be an option for each path to pause all the reentrant clones of the path or a particular subset of reentrant clones.

I need this to debug an event handler and to keep the parallel VIs from continuing to generate events. A couple of times, I have gotten very close to the source of a bug only to have LV run out of memory because the background VIs continued to generate events and queue stuff up. It's really annoying.

Basically, I need this probe to do what a breakpoint typically does when there are parallel loops on the VI's diagram -- it pauses both loops. But put both of those loops into subVIs and now you have my problem.

PS: Bonus points if the custom probe registers the pause with some central debug tool that has a list of all the paused VIs so that all of them can be told to unpause as a group rather than finding and hitting the Pause button on every diagram (which in my case could be 10 to 20 VIs).

[Ravi Beniwal]

Had some fun working on this today. Almost done; will share the code tomorrow!

[Ravi Beniwal]

OK, I couldn't wait for tomorrow; here it is!

I believe it does most of what you asked for. Let's see those bonus points too

So, the code consists of a Breakpoint Manager and a Functional Global (FG). Drop the FG in any VI that you want to pause on demand. It will add the VI (clone or otherwise) to the Breakpoint Manager's list. You can Pause/Resume All/Selected.

I added two lists, one for paths and one for VI names because clones will not have paths. Also, It might be just easier to drop the VI into a VI rather than copying/pasting its path in a paths array. Although, the functionality is there if that works better in some cases.

Instructions:

1. Run the Breakpoint Manager (SBP_Main.vi) first so that it can initialize the FG.

2. Run the "Parallel VIs Launcher.vi", which will launch a couple of clones of a reentrant VI.

I didn't make a custom probe as I din't know what datatype the probe was supposed to work with. Just drop the FG with Action:Pause in any custom probe. When the probe trips, it will pause all VIs registered with the Breakpoint Manager.

Simultaneous Breakpoints Manager.zip

[Olivier Jourdan]

Great work Ravi!

I've got some ideas about your tool.

Use All VI in Memory property could be interesting to access all VI without editing code. To avoid selection issue when lot of VIs are in memory, adding a filter to the VI list could be sufficient.

An other way I'm thinking about to built the VI list is to use almost the same thing we use in SAPHIR "Chronograph" probes. If we can list the VI where a probe is open, you could easily build the VI list to pause. I think it can be a good solution between "All VI in Memory" and "adding code". The only matter is that as far as know we are not able to know in which VI the probe is open

Anyway, it's the first time I heard about this debug need, but it's really challenging probe designing

Edited September 20, 2011 by Olivier Jourdan

[drjdpowell]

Use All VI in Memory property could be interesting to access all VI without editing code.

That was my first thought, but I don't think that list includes dynamically-launched clones (which AQ will be using, I think). At least, it didn't seem to work under LabVIEW 8.6 when I tried it briefly.

-- James

[Olivier Jourdan]

That was my first thought, but I don't think that list includes dynamically-launched clones (which AQ will be using, I think). At least, it didn't seem to work under LabVIEW 8.6 when I tried it briefly.

-- James

You're right. It doesn't work

[Ravi Beniwal]

I guess we could combine the LabVIEW Task Manager and the Simultaneous Breakpoint tool, if that makes some things easy. So you could select VIs from the Task Manager and add them to the Simultaneous Breakpoint tool.

Can someone please put their creative hat on and suggest a name for this. I'm getting tired of typing "Simultaneous Breakpoint tool". I'd rather be connecting boxes with lines coding

[drjdpowell]

I need this to debug an event handler and to keep the parallel VIs from continuing to generate events. A couple of times, I have gotten very close to the source of a bug only to have LV run out of memory because the background VIs continued to generate events and queue stuff up. It's really annoying.

The only alternate idea I can think off is to add the debug feature to whatever framework you are using to either dynamically launch the VIs, or to pass messages. The launching subVI could keep a list of references to the VIs that it launches (for access by the debug tool). Or if there is a common "enqueue" or "send message" subVI, that could be commanded by the debug tool to pause its own caller.

But surely there must be a way to get a reference to all running VI's, including clones?

-- James

[Ravi Beniwal]

Should there be an option to let a pause condition in a clone, pause other clones of the same VI only, instead of pausing all VIs registered with the Simultaneous Breakpoint Manager?

[Aristos Queue]

But surely there must be a way to get a reference to all running VI's, including clones?

Surely not. See my post here.

Should there be an option to let a pause condition in a clone, pause other clones of the same VI only, instead of pausing all VIs registered with the Simultaneous Breakpoint Manager?

Not sure. The sad part about all this is that my interest extends to solving one particular bug. I'm not sure how much utility all of this will generally have in the future, so I'm not recommending anyone pour too much time into it. Having said that, I'm thrilled to have what you've built thus far!

[Ravi Beniwal]

Not sure. The sad part about all this is that my interest extends to solving one particular bug. I'm not sure how much utility all of this will generally have in the future, so I'm not recommending anyone pour too much time into it. Having said that, I'm thrilled to have what you've built thus far!

There's nothing sad about this. I've used the some workaround to achieve similar functionality in the past and have certainly used the Task Manager a lot. Cleaning all this up and adding all this functionality can only help everybody.

Besides, we are having fun doing this, which is the whole point IMO!