dynamic events memory leak

[Bublina]

Hello,

is this usage of events structure wrong ? (dynamic events terminals used as tunnels).

It was causing memory leaks in my app.

The example isnt leaking, but after I stopped using the dynamic events terminal as a tunnel, my app isnt leaking any more.

Regards

[josborne]

Your sentence below is confusing. 

Is the code you posted leaking  or not?

>>The example isnt leaking, but after I stopped using the dynamic events terminal as a tunnel, my app isnt leaking any more

Anyways:  I took a quick look.  And it appears that you are using these two parallel loops in a producer-consumer architecture.  Perhaps you are getting a memory leak because you are producing events faster than you are consuming them?

[nathand]

In LabVIEW 2011 I see no memory leak with your code, at least over a short run.  I don't know of any problem with passing dynamic event registration refnums through tunnels, but it's also not necessary to wire them across every event case, that happens implicitly.  This is a funny structure, though.  It's not usually a good idea to put an event structure inside a case structure like that, because once it's registered for an event it will remain registered for that event even if the event structure isn't currently executing.  You can build up a large backlog of unhandled events, which would look like a memory leak.

[AKA_TG]

"The example isnt leaking, but after I stopped using the dynamic events terminal as a tunnel, my app isnt leaking any more."

Thats a nice simple example of broadcasting.

When you say "as a tunnel what" exactly do you mean?

The dynamic event registration number was created external to the loop then input as a tunnel instead of a shift register?

[AKA_TG]

Nathand,

After reading your explanation I wonder how this example could be fixed to give the same functionality

I personally don't see a problem here if it is used only as a broadcast pattern, but my LabVIEW knowledge of events is

rusty. 

What am I missing here?

[Bublina]

Thank you, for input.

I am developing a big app, and i use this setup of main VI and all the subVIs controlled via several events.

Some of these subVIs have registered more then one event, for example hardware events, and i need to programatically register/unregister as the subVIs restart tasks handle errors etc.

I used similar architecture all over my project, and as i started the program, after a good minute, the program periodically leaked the memory, few KBs every now and then. I checked all common memory leaks, checked all with profiler. Found nothing. Then I checked how do the event structures work and found ussually this:

So, in desperate effort to get rid of that leak, I removed most of those shift registered dynamic event VIs (where it was possible) and the leak disappeared. I double checked, I didnt manipulate the code anywhere else.

I made a simple example, that does not leak to demonstrate the architecture. I was expecting to get facepalmed with it.

If you think it is OK, I ll have to take a deeper look at it.

[Bublina]

To nathland,

I do it like this, the event cluster contains the addressing VI (name), and if the VI that acquired the event isnt that name, the while loop just rolls over to the wait structure again. There was no bunch of events built up, was among first things i checked.

Take a look at the example. Obviously, I presume there is no possibility to get it stuck in some case. If there is, send it away in queue or something like that. For me it is very practical and clean solution. Great thing is that there is sooooo many awesome hardware events you can register too, so you get a nice VI living its own life, that you can easily control.

[Mark_Yedinak]

---

@Bublina wrote:

Thank you, for input.

I am developing a big app, and i use this setup of main VI and all the subVIs controlled via several events.

Some of these subVIs have registered more then one event, for example hardware events, and i need to programatically register/unregister as the subVIs restart tasks handle errors etc.

I used similar architecture all over my project, and as i started the program, after a good minute, the program periodically leaked the memory, few KBs every now and then. I checked all common memory leaks, checked all with profiler. Found nothing. Then I checked how do the event structures work and found ussually this:

So, in desperate effort to get rid of that leak, I removed most of those shift registered dynamic event VIs (where it was possible) and the leak disappeared. I double checked, I didnt manipulate the code anywhere else.

I made a simple example, that does not leak to demonstrate the architecture. I was expecting to get facepalmed with it.

If you think it is OK, I ll have to take a deeper look at it.

---

This would be the recommended method for dynamically registering/re-registering events.

[josborne]

My guess is still the same: That you are generating events faster than you are consuming them. Therefore you are building up a backlog of events in memory, which looks like a leak. And that leak went away when you optimized your code ( eg you improved your code to consume the events quicker and therefore no backlog was built up).

[Bublina]

If that would happen, there is quite easy way to figure it out, becouse once I have, in the end of the day after several hours testing, 100 MBs of events build up upon several or at least one event structure, I would not be able to close the application using the very same event queue instantly. Good suggestion, but it was not this. It would be also indicated by big processor load, which was 0.

I didn´t mention, that I do not use events for data processing like it was in that exampe i first provided (that was silly).