LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

dynamic events memory leak

Highlighted

Hello,

 

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

 

Events.png

 

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

Download All
0 Kudos
Message 1 of 13
(1,520 Views)
Highlighted

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?

 

http://www.medicollector.com
0 Kudos
Message 2 of 13
(1,510 Views)
Highlighted

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.

0 Kudos
Message 3 of 13
(1,504 Views)
Highlighted

 

"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?

 

 

 

0 Kudos
Message 4 of 13
(1,501 Views)
Highlighted

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?

 

 

 

 

 

 

 

0 Kudos
Message 5 of 13
(1,494 Views)
Highlighted

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:

events2.png

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.

 

0 Kudos
Message 6 of 13
(1,480 Views)
Highlighted

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.

 

events3.png

 

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.

 

 

0 Kudos
Message 7 of 13
(1,477 Views)
Highlighted

@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:

events2.png

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.



Mark Yedinak
Certified LabVIEW Architect
LabVIEW Champion

"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot
0 Kudos
Message 8 of 13
(1,476 Views)
Highlighted
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).
http://www.medicollector.com
0 Kudos
Message 9 of 13
(1,457 Views)
Highlighted

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).

0 Kudos
Message 10 of 13
(1,445 Views)