QHYCCD

Possible Memory Leak in qhyccd.dll

Re: Possible Memory Leak in qhyccd.dll
« Reply #15 on: January 31, 2021, 03:45:47 AM »
Found out this thread only today, as, if anything, I'm usually only checking the linux SDK forum.

So, I'm not doing this in windows, nor in LabVIEW, but YES, according to my experience there seems to be a serious resource leak on exit.

FWIW, I'm doing this in matlab, and under linux. And I'm doing that for work, not for hobby. I have a couple of decades of experience in LabVIEW as well, and have reasons to suppose that calling functions from a dynamic library via CLFN or via matlab callib() boils down to pretty much the same.

My working hypothesis is that on both platforms the .dll or the .so define a function called when the library is loaded, which allocates some resources, which are not properly cleared when the library is unloaded.

If you haven't tried it yet, I've seen that calling the undocumented QHYCCDQuit() before ReleaseQHYCCDResource() may improve exit stability.

I think that somewhere I have also attached trace dumps of the crashes. Beyond that, it is not to me to debug closed code.

Re: which SDK -- well pretty much all of them till 20.8.2020. Have to assess eventually the latest ones, but alas, is this a red queen race?

Re: Possible Memory Leak in qhyccd.dll
« Reply #16 on: February 01, 2021, 01:10:05 PM »
Enrico,
The latest SDK versions no longer generate the memory leak issue for my Labview app.  Thanks for mentioning the undocumented QHYCCDQuit().  If this issue arises for me again I will remember this call.

Peter

ma_rs

Re: Possible Memory Leak in qhyccd.dll
« Reply #17 on: February 02, 2021, 01:04:15 AM »
QHYCCDQuit() is related to an uncompleted API, You can use it before release  SDK library.
After SDK version 21.02.01, that uncompleted API has been banded, so you should not have to use QHYCCDQuit() anymore. (will do nothing if you still execute that)

My suggestion is : continue to  use your current version of SDK, and also check this link [https://www.qhyccd.com/html/prepub/log_en.html#!log_en.md]
There will be some short demo, recommended execute sequence and device event demo published here.
You can also send email to my@qhyccd.com, tell me what coding language are you using, I will try to publish that version first. And also other SDK questions is welcomed

Re: Possible Memory Leak in qhyccd.dll
« Reply #18 on: February 07, 2021, 09:00:32 AM »
(completely OT at this point in this thread...)

Tried today the latest sdk_linux64_21.02.01, and I still see obscure but repeatable segfaults after ReleaseQHYCCDResource(). Same segfaults also tampering with the usb cable or with the 12V cable, causing temporary disconnections, but there, libusb may be involved.

As per which language, check the link I posted above.

Attached one message which was sent to support in september.

Quote
Technical Background

Setup is Ubuntu 18, we have been testing a lot of your versions of the SDK, up to 20.8.26.

We are working in a multiple camera setup. Cameras may be connected and disconnected many times during the lifetime of the caller application. Cameras may disconnect because of electromagnetic interference (EMI), power or cable failure, etc., and we need robust ways to handle disconnects and remediate.

Questions

* We find no function in the SDK for determining if an opened camera [OpenQHYCCD(CameraName);  InitQHYCCD(camhandle)] is still reachable. Parameters can be read with GetQHYCCDParam() with a formerly valid camhandle, even if the cable of the camera has been pulled.

* Calling ScanQHYCCD() after communication with a camera is opened, makes that camera unreachable.

* We find no function in the SDK for determining how many cameras have been opened. Knowing that at least one camera is opened is necessary, to prevent calling ReleaseQHYCCDResource() too early.

* The caller application segfaults with the following trace if a camera is opened [OpenQHYCCD(CameraName);  InitQHYCCD(camhandle)], closed [CloseQHYCCD(camhandle)] and reopened again. This gives wrong indication for the camera situation.

  Stack Trace (from fault):

  [  0] 0x00007f1266346de6     /lib/x86_64-linux-gnu/libusb-1.0.so.0+00044518 libusb_control_transfer+00000086
  [  1] 0x00007f12642f8949     /usr/local/lib/libqhyccd.so+00780617 _ZN6QHYCAM7vendTXDEPvhPht+00000229
  [  2] 0x00007f12642fa5b2     /usr/local/lib/libqhyccd.so+00787890 _ZN6QHYCAM10LowLevelA0EPvhtth+00000196
  [  3] 0x00007f12643c1ad5     /usr/local/lib/libqhyccd.so+01604309 _ZN10QHY600BASE12InitChipRegsEPv+00000277
  [  4] 0x00007f12642e9d25     /usr/local/lib/libqhyccd.so+00720165 InitQHYCCD+00000411
  ...

* The caller application segfaults if libqhyccd.so is released before all cameras are closed and ReleaseQHYCCDResource() is called. What resource is left allocated under the carpet?

* Please explain the function QHYCCDQuit(). We have seen application crashes if it is not called when a camera is closed. On the other hand, the function has no argument specifying which camera connection is terminated.

Your assistance in resolving these issues will be highly appreciated.