LV silent crash with threading and oop on LV2009 f2

[User002]

I have an oop application using a threading abstraction class. When I run my test program for about 5 seconds it crashes and LV quits without any error message at all, it just dies silently.

The application is attaced and I tried to strip it down as far as I could and still being able to reproduce the crash. Just unzip the project and find the Program:Main.vi and run it.

Could this be a LV issue?

Thankful for help.

/Roger

[muks]

A bug?

[User002]

muks, thanks, but I think this is something different, this program exits silently. I have no probes as in the thread you linked.

Basically all I have done is implementing a thread class (ThreadingBase.lvclass) with a "Work.vi" method that all child classes (Thread1.class) can implement. Then I have a queue-based call by reference abstraction class (ExcecutionBase.lvclass) that the threading class inherit.

Anyone ? 🙂

/Roger

[User002]

Anyone able to reproduce it?

The program requires nothing except than vanilla LV2009 🙂

/Roger

[User002]

Hi again, 🙂 

I got this crash reproduced on my colleagues machine. So I guess its not isolated to my machine.

Any NI engineer looking into this now? 

/Roger 

[User002]

Bump!

Anyone? 😉

/Roger

[Ben]

1) I saw it crash (confirmed)

2) I putan indicator on the iteration term and noticed it crashed after 650 times.

3) Put a or gate and stop loop if gtr than 650.

4) Code stopped with no error

5) Changed stop to 700

6) Now I get an error message having to do with your queues.

7) the VI (from vi.lib) named "Details Display Dialog.vi" show the erro but it has stopped as shown here.

Why is there a flat seq structure used in that code? (I should know better than to look at the code.

Ben

[Ben · Accepted solution]

I changed your code as shown here and got no crash.

 

Are you sure your first version should have been wired like it was? It looks like you where shoving the wrong class back into the queue. LV can tolerate this right up until it is time to deallocate the buffer and then it can get confused.

Does that help you?

I'll ca ll this a bug for now since I saw that poor behaviour of the VIs in VI.lib.

Ben

[User002]

Ben, thanks. I put the wrong object there on purpose. I was reworking some in my executionBase class and wanted to simplify it's lock/unlock methods.  Then I started notice these crashes.

I guess that's bad LV behaviour if the dev environment exits without any messages?

/Roger

[Ben]

---

RogerI wrote:

Ben, thanks. I put the wrong object there on purpose. I was reworking some in my executionBase class and wanted to simplify it's lock/unlock methods.  Then I started notice these crashes.

I guess that's bad LV behaviour if the dev environment exits without any messages?

/Roger

---

Yes sir!

I ran into a very similar crash myself but in that case I was playing games with type casting and screwed up.

You situation is very similar but there was what I will call "an implied type cast" when you wired the wrong type of class. Since yours is a typical type of mistake, this puts the ownership back on NI to protect labVIEW from LabVIEW.

Ben