LabWindows/CVI

cancel
Showing results for 
Search instead for 
Did you mean: 

Software crashes with [FATAL] [GetUILSpace] [..\james\ui_tag.c:739] Assertion failed: uiData->uilSpace != 0

As the title says, my software crashes and the Windows Event Viewer mainly shows this message.

This error seems to happen daily, sometimes multiple times a day.

 

Then the follow-up error event is a generic Application Error with error code 0xc0000005

My guess is that I cause a nullpointer exception *somewhere* or some sort of memory leak, the problem is that I don't understand that error at all.

 

Has anyone had that kind of error aswell? Does it tell me that the error had something to do with some UI function or is this just a follow-up error of a bigger problem?

 

0 Kudos
Message 1 of 13
(1,354 Views)

Hello,

if you suspect one of your own pointers may be on the loose, then activate extended debugging and the resource tracker, run your program, close it properly and check for any remaining or lost data blocks. Don't rest until the window is empty !

0 Kudos
Message 2 of 13
(1,280 Views)

Hi, thanks for your answer and sorry for the following long message

 

I double checked every memory block and handle that showed up in the box, they get free'd properly and also all the memory blocks that got allocated get re-used until the software closes, so there are no "dynamic" allocations while the software is running.

 

An additional issue is that whenever there is some kind of event happening, like moving the mouse or pressing keys, the whole UI gets super choppy and a couple of my threads (I have about 7 background threads running) get slowed down aswell. The computer that this software is running on has a 3rd gen i3 processor so that doesn't really help aswell.

The thing is that all the UI callbacks that I have only process COMMIT events and if they do, they only set a couple of flags and maybe call SetCtrlAttribute and that's it, so I really don't understand how moving the mouse could kill the performance that much.

 

What I can probably safely say is that this crash (and maybe the choppy UI) has to do with some sort of UI event or callback.

My software starts up background threads and then runs "RunUserInterface(...)", no other thread uses anything like "ProcessSystemEvents". Is that how it's supposed to be?

If yes, then does the main thread that ran RunUserInterface handle *all* CVICALLBACK functions? Because I'm using a DAQmx card aswell and have a couple callbacks set up for it too, the initialization of the card happens in another background thread though and I wasn't sure which thread handles the DAQmx callbacks.

 

Some of the DAQmx callbacks need to get a threadlock, if the UI thread handles the DAQmx callbacks aswell and at some point has to wait a bit longer for the threadlock, would that hang and crash the software?

 

Yesterday I've disabled the DAQmx card code and the software didn't crash for hours, but the choppy UI whenever some input happens still occurs.

0 Kudos
Message 3 of 13
(1,260 Views)

@PSflow wrote: [...] If yes, then does the main thread that ran RunUserInterface handle *all* CVICALLBACK functions? [...]

Yes. Normally the way you should (*) architect your program is:

  • all user interface stuff in main thread
  • all hardware init in main thread
  • forced threaded callbacks such as async timers and hardware events should do as little as possible: copy the data to a ring buffer, set up a flag and call PostDeferedCall() to let the heavy lifting happen in the main thread.

(*) Of course that's not customary and the UIR can indeed run multithreaded. But the way above keeps things simple and I assure you it will stay responsive even with a lot of panels and hardware (my record is 200 panels, 30 timers and hundreds of all kind of hardware devices...)

0 Kudos
Message 4 of 13
(1,251 Views)

Alright, currently my background threads also access UI stuff via SetCtrlAttribute(x, y, ATTR_CTRL_VAL, ...) and one thread also draws bitmaps every second or so, so I'll probably have to move this UI stuff to a single thread, right?

 

Also, I did some testing on my own machine and it seems like the choppyness occurs after I've already caused a certain amount of events:
1. Start Software (I did that in Debug mode, that way it happens faster)

2. Move cursor around the main panel, not clicking or typing anything at all

3. After a couple of minutes of moving the cursor around, the UI (and probably one or more background threads) get extremely choppy

4. Let the cursor rest for a couple of minutes, the moment I stop moving the software runs as expected

5. Move the cursor and the choppyness starts again instantly.

 

Not triggering events makes the UI / software run perfectly fine almost the instant I stop moving my cursor for example.

As I wrote, I am not reacting to any kind of cursor (movement) events, this choppyness occurs even if I just move around the panel (avoiding controls) and my panel doesn't even have a callback function.

 

I think it's important to note that I'm using CVI2017, is this some kind of known issue in this CVI version or might I actually do something wrong in my program?

0 Kudos
Message 5 of 13
(1,247 Views)

I understand that seems conceited, but I would double check that there is no callback function that triggers on all events: that process activity raising when you move the mouse makes me think that some function is reacting on mouse events, possibly because of an incorrect event handling that does not filter EVENT_MOUSE_MOVE and similar events out.



Proud to use LW/CVI from 3.1 on.

My contributions to the Developer Community
________________________________________
If I have helped you, why not giving me a kudos?
0 Kudos
Message 6 of 13
(1,231 Views)

Sadly I've double checked every (UI) callback already, I really only react to EVENT_COMMIT.

 

One interesting thing I've found out:

 

I have set up two virtual machines (both Windows 10), one with CVI 2017 Runtime and the other with CVI 2020 Runtime, both having the exact same executable (debug build) with the respectable dependency DLLs.

The 2017 VM basically shows the exact same performance issue as I have described. It starts out smooth and the more I'm moving the mouse, the slower it gets and it does not "recover" when I let the mouse rest.

Interestingly enough, I currently haven't been able to reproduce this on the VM with the 2020 runtime. Or even if the issue persists, I couldn't seem to really "see" it after about 90minutes of constant mouse movement (I have set up a program that runs a recording of my mouse movement)

 

So the current status is:

- Every thread that does update the UI in some way uses SetCtrlAttribute instead of SetCtrlVal, though it's important to know that when the software runs on my work machine, almost all of the background threads get shut down or do nothing due to missing hardware. There is basically only one or two background threads running, letting an LED blink to tell me that they're alive.

- CVI 2017 (Shared) Runtime has this performance issue, depending on the PC hardware the time it takes to be noticable ranges from 1 - 5 minutes of mouse movement, after that it doesn't calm down and the UI (and probably the background threads) only run smooth when I let the mouse rest, any kind of movement instantly throws it back to the choppyness

- CVI 2020 (Shared) Runtime currently has not shown me this issue. I will, however, let my mouse recording run for the next couple of hours just to be safe.

 

Let's say there really was a bug in the 2017 runtime that could cause this (depending on how "bad" you program your software).

Are we allowed to just use a newer runtime on the customer PCs even though we only have developer licenses for CVI 2017?

0 Kudos
Message 7 of 13
(1,226 Views)

@PSflow wrote:

Are we allowed to just use a newer runtime on the customer PCs even though we only have developer licenses for CVI 2017?


Nope. Can't do that. Runtime engines must match.

 

About your prog, and since it looks like some CPU issue, why don't you pass it through the Profiler ? It will most likely tell you what is using all the CPU. Just enable it in [Options][Build Options] and manage your various threads with CVIProfSetCurrentThreadProfiling()

0 Kudos
Message 8 of 13
(1,194 Views)

@gdargaud wrote:

@PSflow wrote:

Are we allowed to just use a newer runtime on the customer PCs even though we only have developer licenses for CVI 2017?


Nope. Can't do that. Runtime engines must match.

 

About your prog, and since it looks like some CPU issue, why don't you pass it through the Profiler ? It will most likely tell you what is using all the CPU. Just enable it in [Options][Build Options] and manage your various threads with CVIProfSetCurrentThreadProfiling()


Well I have read on the forum that the runtime engines themselves are backwards compatible, do you mean regarding licensing? I haven't found anything about needing a license for e.g. the 2020 runtime. There is no prompt for licensing when installing the runtime anyway..

 

Regarding the profiler, thanks for the tip. I will re-run my tests on both VMs with the profiler activated.

0 Kudos
Message 9 of 13
(1,189 Views)

It's not just a licensing problem, it's a linking problem. Function signatures may not match and it'll either refuse to run outright (if you use InitCVIRTE) or will crash when calling certain functions.

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