Compiled app with external DLL freezes PC

[alpov]

I am working on a measurement system with Ettus USRP, which requires a DLL wrapper between LabView and underlying driver (called UHD by Ettus). Everything works smoothly until I compile the app with Application Builder. The executable works well when running, but freezes the PC when it is closed.

I have simplified the testcase to DLL code at http://pastebin.com/7eEdHsn0. LabView VI has just two buttons, one for load_usrp() and one for unload_usrp() with previously obtained handle. This works well, hardware gets initialized and also properly closed. But when I try to close the app after unload_usrp(), the computer completely hangs up, including mouse cursor. Sometimes it gets back alive in ca. 15 seconds, at other times it requires hard reboot. I know it looks like some serious memory issue, but I can't find the cause.

Any ideas what can be wrong? It is suspicious that only compiled app has such problem and that it freezes the PC completely. What happens during DLL process detach? I have also created a simple C++ code to test the DLL (http://pastebin.com/B7PKAhDZ), no problem there. The underlying UHD hardware driver is quite well coded with boost::shared_ptr for pointer management, so I really hope there is no major memory leak there.

My setup: WinXP SP3 (tested both on a PC and on a clean WinXP installation in VMware), LabView RTE 2009 32-bit (also tested with 2009 SP1); compiled using LabView 2009 on Win7

Thanks,

Ales

[rolfk]

While I understand quite a bit about standard C, I have to admit my C++ is rather limited. But are you sure that destroying the trx object, will also properly deallocate the _usrp object in there and that deallocating that object will trigger an explicit destructor that closes any resources inside the driver? Your simple C test program is not a very convincing test for this as normal Windows process termination will tear down a lot of potential remaining resources anyhow. However LabVIEW process termination is quite a bit more complicated and a system lock somewhere could prevent LabVIEW from going through all its proper cleanup tasks.

[alpov]

I am pretty sure that the _usrp is destructed, this can be seen on external hardware. If I try to close the app *without* destructing trx, it is closed without any problem. Maybe some destructor of _usrp corrupts something. But I have no idea what tool can be used to track such issue.

What is the difference between calling the DLL from LabView and from compiled application? It is weird that only compiled app freezes the PC. Moreover, compiled app with full installation of LabView works OK, it hangs up only on PC with RTE only.

Ales

[rolfk]

If the desctructor of the object does some illegal activity, then everything is possible. LabVIEW is a huge application and takes up quite a bit of heap space. Therefore a pointer going havoc has a lot of opportunities to corrupt something without causing a protection fault of some kind, since the memory it accesses is actually valid process heap space. As I already said I have little experience with C++ porgramming and it could be that such a protection fault during process termination is actually ignored, since there is little the program, user or OS can do anyhow at that point. Or your C++ driver does explicitedly catch such exceptions during process termination, which would indicate a fundamental problem in the driver being hidden in that way. I know many people think different, but I'm a supporter of the idea: if something with memory is wrong crash and crash as early as possible. the whole idea of catching protection fault erors, while possible, is a horrondous thing. Once memory is corrupted there is no magic that can patch this back into a perfect state and the process should die as quickly as possible. (Of course that doesn't apply to my LabVIEW programs, they are on a very different level, and there it's not about memory corruption, but about dealing gracefully with bogus user input).

What I do have experience in, is calling normal C DLLs and I have seen all kinds of strange effects if such a DLL corrupts some memory. This corruption can be because of a bug in the DLL or in the configuration of the parameters to the DLL. My observed failures range from (in order from best to worst) immediate exception dialog, delayed exception dialog, exception or stalling at LabVIEW exit, or strange computational results elsewhere in the LabVIEW program, to nothing observable. And this can change because of seemingly small and unrelated changes to the application and also vary between IDE and built app, often with the built app tending to produce exceptions quicker and earlier. I assume this is because a built app uses a lot less memory so a bad pointer is more quickly triggering the CPU protection mode mechanisme.

[alpov]

Rolf, thanks for your extensive answer. It really seems to be some hidden bug in UHD driver. Today, I have tested the new NI-USRP driver and run into the same issue. So I forwarded this discussion to community support https://decibel.ni.com/content/thread/11048?tstart=0. I hope that some NI developer will be able to replicate this issue and find a solution.