LabWindows/CVI

cancel
Showing results for 
Search instead for 
Did you mean: 

Release version of program crashes

I have a multithreaded program that runs fine in the debugger.  When I run the release version of the program, however, it crashes.  The offending code is the following:

 

static int CVICALLBACK gui_proc (void *functionData)
{
    /* until the program is terminating */
        
        if (gui_run)
        {
            gui_run_main();
        } else Sleep (500);
    }

}

 

The function gui_proc is running in its own thread.  The variable gui_run is set true by another thread when a "RUN" button is pressed on a GUI panel.  The call to gui_run_main is not successful, as it doesn't appear that even the first statement in this function is executed.

 

Also, when I try to run the program after the crash, I have to restart the Parker motion controller I am communicating with via Ethernet (although I can successfully ping its IP address at this point).  I've attached the error message from the Event Viewer, if that helps.

 

Thanks.

0 Kudos
Message 1 of 23
(4,568 Views)

Hi Double_D,

 

First, I want to clarify one thing... is there a typo in the code snippet that you posted? It looks like there should be a while loop that is missing. The closing bracket is there, but not the declaration of the loop.

 

Also, one other consideration... it seems that you need some method of preventing the loop from continuing to run after gui_run is set to true. (Perhaps this is already handled in the missing loop declaration, but I wanted to check).

 

Please let us know back about these questions... maybe they will provide a starting point for some continued discussion.

 

Best Regards,

 

John M

National Instruments
Applications Engineer
0 Kudos
Message 2 of 23
(4,534 Views)

John,

 

I deleted a small diagnostic section of the code when I posted the message and inadvertently deleted the while statement, too.

Here is the correct code:

 

static int CVICALLBACK gui_proc (void *functionData)
{
    /* until the program is terminating */
    while ( run) {
        
        if (gui_run)
        {
            gui_run_main();
        } else Sleep (500);
    }

    
}

0 Kudos
Message 3 of 23
(4,519 Views)

Thanks for clarifying that Double_D, one more followup... it seems that you need some method of preventing the loop from continuing to run after gui_run is set to true. Is there anything else going on that would keep this from being the case? Also, please share with us a little more about where this piece of code fits into the rest of your application. Maybe some more context will help shed some additional light for us.

National Instruments
Applications Engineer
0 Kudos
Message 4 of 23
(4,497 Views)

John,

 

Sorry for the delay in replying, but I have been out of the office for a few days. 

 

I have attached the text of the gui_run_main function for your perusal.  When the user presses the "RUN" button on the user interface, gui_run is set true and gui_run_main is called.  The thread stays in gui_run_main until the number of samples to be processed (selected by the user) is complete.  gui_run is then set to false at the end of this routine and gui_proc returns to its "sleep" state, waiting for the next set of samples to be run.

 

As far as what else might be going on at this time, I will have to do some more digging.  This is code I inherited from a student who was working on this project, so my knowledge about program details is somewhat limited.

 

 

0 Kudos
Message 5 of 23
(4,423 Views)

Hi, Double_D

 

if i understand correctly , you have use two threads in you program. one is for UI , another is for dedicate function. however, i saw you use a variable gui_run as a flag to pass the information between UI and you function.  therefore, it may have the change that both thread access the variable gui_run at the same time.  i am not sure it will result in crash.  just try to prevent this and test it again.

 

 

hope can help!

 

B.R

Gerry

0 Kudos
Message 6 of 23
(4,392 Views)

sorry , wrong typing

 

should be

 

therefore, it may have the chance that both thread access the variable gui_run at the same time.  i am not sure it will result in crash.  just try to prevent this and test it again.

0 Kudos
Message 7 of 23
(4,391 Views)

Gerry,

 

While the program is indeed multi-threaded, there is no possible conflict regarding the gui_run variable.  When gui_run is set true by clicking the button on the user interface, the gui_run_main function is called.  When all samples have been processed, gui_run is set false.  The only way to change the state of gui_run would be to click the RUN button while gui_run_main is running, but the panel containing that button is not visible after RUN is clicked.

 

One thing I would like to emphasize is that this code ALWAYS works in the debugger, but NEVER works as a release version executable.

0 Kudos
Message 8 of 23
(4,371 Views)

Hi Double_D,

 

After reading back through the thread again, it seems that you have called gui_proc in a separate thread, and it sits in the while loop the entire time your program runs, polling to see if gui_run is true. When it is, it executes the gui_run_main function, and goes back to polling again.

 

Perhaps a better approach than polling for a condition, would be to launch the gui_run_main function in its own thread directly from the "RUN" button's callback. This way, you create a new thread each time you need it, and the thread is disposed of each time that function is finished. In general, this would be a more robust solution than continually polling from a second thread. Unless there is some other factor preventing an approach like this, I would suggest this as a next step.

 

John M

National Instruments
Applications Engineer
0 Kudos
Message 9 of 23
(4,336 Views)

John,

 

I modified the code per your suggestion.  The RUN button callback function previously called a function __gui_run(void).  This function simply set gui_run = 1 and gui_run_main was then called by the polling routine.  I commented out the __gui_run call in the callback and created a new thread pool and thread for gui_run_main (in the callback) and scheduled it with the Cmt... function.  I'm still having the same issue as before, though, as the program runs fine in the debugger but crashes when I run the release version.  I'm wondering if the program is crashing in the callback function itself, i.e., before it even attempts to call gui_run_main.  I'll do some more troubleshooting work tomorrow, but it's difficult without the tools provided by the debugger.

0 Kudos
Message 10 of 23
(4,309 Views)