DataAct Incorporated  

home  I  store  I  about us  I  contact
Innovative Control and Acquisition Solutions

LabVIEW™ Toolkits and Applications

 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister   ProfileProfile   MessagesMessages   Log inLog in 

The time now is Sat Sep 04, 2010 2:33 am
All times are UTC + 0

 Forum index » Products » Toolkits » dqGOOP Toolkit » Bug Reporting
LabVIEW race condition with named queue bug
Post new topic   Reply to topic Page 1 of 1 [5 Posts] Mark the topic unread ::  View previous topic :: View next topic
Author Message
brian175
Site Admin


Joined: 09 Jun 2005
Posts: 104
Location: Rochester, NY
PostPosted: Wed Nov 09, 2005 3:31 pm    Post subject:   LabVIEW race condition with named queue bug
Subject description: Bug to be aware of when using dqGOOP 		Reply with quote  Mark this post and the followings unread
First, thanks to Mike Matthes of Ball Aerospace & Technologies Corp for bringing this bug to our attention. Below are some quotes from email correspondence that we exchanged discussing this bug:

Mike Matthes wrote:
I recently came across your queue GOOP framework and think it is a great solution. It is very simple and I’m impressed with your benchmarks.

I wanted to warn you of a queue bug I’ve recently found using an Obtain queue to lookup a named queue. This is a race condition that I ran across – in my case it was locking LabView every 4-6 hours. I was not using dqGOOP at the time, but it is a very similar implementation.

NI is aware of this bug and R&D is currently working the issue. It will hopefully be fixed in 8.0.1…

I’m running 7.1.1 right now, but this has also been verified to happen in 8.0.

I just wanted you to be aware…keep up the good work!


Mike Matthes wrote:
I did run this on 7.1 and experienced the lockup. This is a strange bug – NI had trouble replicating at first, but I’ve recreated it on 5 different machines. NI finally did replicate it – I never did figure out why they had trouble at first. Several others here at Ball have also recreated the problem. Some things I’ve noticed are:

1) Hyperthreading – on a computer that supports this, the bug happens when HT is on, but not when off (change in the BIOS).

2) Multi-threading – if you turn off multi-threading in Labview itself (under options), then the bug disappears.

I believe this is some sort of mutex hang down in the depths of Labview with it’s queue manager.


The attached VI was also provided by Mike to demonstrate the problem. **WARNING** if you run this VI it will LOCK UP LabVIEW so be sure to save and close your work first!

queue lockup check.vi
 Description:
VI (version=7.1.1) demonstrating bug with named queues. **WARNING** if you run this VI it will LOCK UP LabVIEW so be sure to save and close your work first!

Download
 Filename:  queue lockup check.vi
 Filesize:  69.07 KB
 Downloaded:  173 Time(s)
Back to top
View user's profile Send private message Send e-mail Visit poster's website
brian175
Site Admin


Joined: 09 Jun 2005
Posts: 104
Location: Rochester, NY
PostPosted: Wed Nov 09, 2005 6:54 pm    Post subject: Re: LabVIEW race condition with named queue bug
Subject description: Possible workaround 		Reply with quote  Mark this post and the followings unread
I haven't spent a lot of time looking into this bug, but the example that demonstrates the bug is a very extreme case of obtain reference (by name), enqueue, and then close reference. I modified the example by moving the obtain and close reference outside of the upper two loops and LabVIEW did not lock up (see "queue lockup check(reuse refnum).vi" attachment). While this did not crash my LabVIEW, please make sure that you close and save your work BEFORE running.

A possible workaround for this would be to keep the reference alive and reuse it instead of obtaining a new one each time. The other attachment (Reuse named queue reference.vi) shows one technique for this. This VI would be used in place of the obtain queue.

Reuse named queue reference.vi
 Description:
This VI shows a technique for reusing a reference. It could be modified with a name string array and reference array to allow for multiple names to be looked up.

Download
 Filename:  Reuse named queue reference.vi
 Filesize:  17.83 KB
 Downloaded:  162 Time(s)
queue lockup check(reuse refnum).vi
 Description:
Bug appears to be caused by frequent obtain/closing of named queue reference. This VI doesn't crash (at least for the few minutes that I ran it).

Download
 Filename:  queue lockup check(reuse refnum).vi
 Filesize:  69.95 KB
 Downloaded:  162 Time(s)
Back to top
View user's profile Send private message Send e-mail Visit poster's website
brian175
Site Admin


Joined: 09 Jun 2005
Posts: 104
Location: Rochester, NY
PostPosted: Mon Nov 21, 2005 7:29 pm    Post subject: Bug should be fixed in the next release of LabVIEW
Subject description: Will it be 8.0.1 or 8.1.0? 		Reply with quote  Mark this post and the followings unread
William Brown, from Ball Aerospace & Technologies Corp, has forwarded this message from NI about the bug that was found by Mike.
Brian from NI wrote:
It was good to talk to you last week in Golden.
I'm sorry you ran into this problem. I have confirmed that we've fixed the bug internally, so it will make it into our next release. I don't know when we'll do our next release--if we have enough severe issues like this, you'll probably see an 8.0.1 within a few months. (And if we find a particularly severe problem, we could release something almost immediately.) Otherwise, we'll probably have an 8.1 sometime next year.
Thanks for the kind words about LabVIEW. I'll pass them along to the rest of the development team.

Brian
Back to top
View user's profile Send private message Send e-mail Visit poster's website
Francisco Posada
Guest
PostPosted: Wed Jan 25, 2006 4:27 pm    Post subject: Increased CPU usage by using Obtain and and Close reference Reply with quote  Mark this post and the followings unread
Hello all,

I have created an application that uses the dqGOOP to set and pass data. Because my application is multy-threading (and I cannot wire easily my references), every time that I pass data, I obtain and close a a queue reference. At the begining, my application has a CPU usage of 1 or 2 %. After 10 hours, the CPU usage of my application increases to 100%. The software gets blocked. My question is: Has this bug something to do with the increasing of the CPU usage?.

Thanks a lot in advance for the answer to this question?
Back to top
brian175
Site Admin


Joined: 09 Jun 2005
Posts: 104
Location: Rochester, NY
PostPosted: Wed Jan 25, 2006 7:45 pm    Post subject: Re: Increased CPU usage by using Obtain and and Close refere Reply with quote  Mark this post and the followings unread
Francisco Posada wrote:
Hello all,

I have created an application that uses the dqGOOP to set and pass data. Because my application is multy-threading (and I cannot wire easily my references), every time that I pass data, I obtain and close a a queue reference. At the begining, my application has a CPU usage of 1 or 2 %. After 10 hours, the CPU usage of my application increases to 100%. The software gets blocked. My question is: Has this bug something to do with the increasing of the CPU usage?.

Thanks a lot in advance for the answer to this question?


If your app is crashing due to this bug, you should be able to fix the problem by looking at the solution posted earlier in this thread. Instead of open/close a reference, you only obtain it once and reuse it in a shift register. If this doesn't solve the problem, then I would look for some other memory leak. Let us know how it turns out.

Brian
Back to top
View user's profile Send private message Send e-mail Visit poster's website
Display posts from previous:   
Post new topic   Reply to topic Page 1 of 1 [5 Posts] Mark the topic unread ::  View previous topic :: View next topic
 Forum index » Products » Toolkits » dqGOOP Toolkit » Bug Reporting
Jump to:  

You can post new topics in this forum
You can reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You can attach files in this forum
You can download files in this forum


Copyright © 2006 DataAct Incorporated
Powered by phpBB