0

I've written a shared library in C/C++ for MATLAB to create an API for a Monochrome camera.

The code works, but I have some odd issues with memory management (basically the MATLAB functions for freeing/dynamically allocating aren't too reliable). Additionally I have some other really low level things I'd like to debug like looking at values of register holding raw camera buffer.

I can write standalone C Code and launch it with GDB, however a child process will crash the software as only 1 thread is allowed to open a connection to camera at a time. If I don't set break points within the code interacting with device all is fine. But I want to stop the program say after acquiring image buffer, but before copying the data into MATLAB output, the child process spawned by the debugger causes everything to lock up.

Anyone know how I might address this?

Edit: "Unreliable" is not a good wording. Basically, I retrieve an image buffer from camera (which is dynamically allocated because image bitdepth is variable). This array is created/destroyed with mxMalloc and mxDestroyArray which works okay if I have MATLAB_MEM_MGR enabled. This is part of what I would like to debug inside MEX. The other is comparing the raw byte values of the image buffer before coming back to matlab.

Additional Clarification: The error I get in GDB is actually a GenICam error for RESOURCE_IN_USE. My intuition is because the parent process hasn't released the camera resources, the child thread started actually causes issues if that makes sense.

Scott
  • 23
  • 4
  • 1
    This answer may help: https://stackoverflow.com/a/41053352/50617 – Employed Russian Jun 07 '21 at 19:03
  • “the MATLAB functions for freeing/dynamically allocating aren't too reliable” — I doubt they are unreliable, rather, they are perfectly consistent. You might have misunderstood some details about how they work. Which arrays are cleared automatically and which aren’t is not always clearly documented. – Cris Luengo Jun 08 '21 at 01:14
  • What platform are you on? – Cris Luengo Jun 08 '21 at 01:15
  • I've never written a MEX before, but if you are still using 'cl' on Windows then I think I have just the product for you. It's a C/C++ memory debugger. As Cris points out, it is unlikely malloc() or equivalent is unreliable. – Leif Strand Jun 08 '21 at 17:56
  • Sorry just saw these. I am on Windows. Using mxMalloc and mxDestroyArray worked perfectly for two weeks, and suddenly the same unchanged code started causing access violations. I enabled MEM_MGR and the problem went away? – Scott Jun 09 '21 at 13:14

1 Answers1

1

On Windows, it seems somewhat dangerous to switch from VC++ to MinGW-w64 for a MEX, as you can easily wind up with the classic Windows bug of having multiple copies of libc. See the warning here, "Do not link to library files compiled with non-MinGW compilers". A MEX built with 'gcc' will pull in malloc() and free() from msvcrt.dll, whereas any DLLs you link against that were built with 'cl' will pull in ucrtbase.dll instead. That could easily lead to crashes, if for instance gcc-compiled code calls free() on a block allocated using malloc() in cl-compiled code.

The gdb.exe installed by MATLAB does seem to behave somewhat strangely, especially when I press Control-C. It doesn't like Cygwin terminals either. It does spawn a weird 'gdborig' helper process. Finally, I kept seeing a Microsoft A/V tool, mpcmdrun, firing off as I was playing with it. You might try the newer gdb installed by MSYS2 (although I may have seen A/V there as well).

Indeed, some random child process probably inherited the device connection handle, causing the lock-up. But that child process might be something else... not be the extra one created by that silly old version of gdb (7.11.1).

Leif Strand
  • 296
  • 3
  • 6
  • Oh this is interesting! I am building with cl and the duplicate libc copies sounds very possible. Accidental ret2libc lol? Didnt even know this was a thing! – Scott Jun 09 '21 at 13:18
  • I work on a commercial C/C++ debugging tool... we've seen the multiple libc thing many times. It's so easy to do by accident -- /MT(d) vs. /MD(d), etc. Although MATLAB MEX debugging is new to me. I was playing with it all day yesterday. There is no limit to the number of copies of {m,re}alloc/free() you can have in a Win32 process. MATLAB even has its own copy of ucrtbase.dll. By extension, there is no limit to the number of heaps you can have. A Win32 API like HeapAlloc() even has the 'heap' as an explicit argument. Contrast this with Unix/Linux, where there is generally only one heap. – Leif Strand Jun 09 '21 at 14:50
  • I just noticed their note about dlltool. I would rebuild everything with GCC instead, – Leif Strand Jun 10 '21 at 14:55