GPIB ibdev memory leak on Linux

[twotymz]

Hi all.  This is my first post so please bare with me.

I'm noticing a memory leak in the call to ibdev in a simple multi-threaded application that I wrote.  My system is Red Hat Enterprise Linux WS 4 using the GPIB NI-488.2 library, version 2.5.1.

My application, in a loop, creates a thread that:

1. opens a handle to a device via ibdev

2. writes a short message ("AP\r\n") to the device

3. sets the device offline via ibonl

The mainloop, in psuedo-code, of my application looks like this:

 

while 1 :

  create thread

  wait for thread to complete

When I use valgrind, the memory profiler, to profile the memory usage of the application it reports a memory leak at the ibdev call.  It turns out that 28 bytes of memory are lost per call to ibdev.  If I remove the thread and just spin in the mainloop opening the device, writing the message and closing the device the memory leak goes away.

Has anyone else experienced/noticed this?  Is there something wrong with my logic here?  Am I missing something concerning threads and the GPIB driver?  I can post/email code or the valgrind output if anyone wants.

Thanks in advance for any advice/suggestions.

--twotymz

[Raj_V]

Hi Twotymz,

I came across this forum and it identifies a similar issue to what you have been seeing. Are you noticing any incorrect behavior with your application specifically? Also, what version of the GPIB drivers do you have? Perhaps downgrading to version 2.5 of the drivers is an option.

The link here identifies all the supported drivers for Linux and it 2.5 is the latest officially supported version of the GPIB drivers for RedHat EL WS4. 

[twotymz]

Thank you Raj_V for your reply.

No. I am not noticing an incorrect behavior in my application.  It works as designed and I am being careful to check return values and error codes on all ib* functions that I'm calling.

The specific problem I have is the fact that my application is expected to run continuously while handling a large volume of GPIB transactions where a device will be opened, a message is written to or read from the device and the device is set offline.  If I keep my current implementation using threads, then after a day or so I can no longer open the device because I'm out of memory.  My only recourse, at that point, is to restart the application which fixes the problem until I run out of memory again.

I double checked and I am using the lastest drivers (2.5) according to the link you posted.

I did come across the same forum post as you did before posting my issue.  I am not noticing the issue described in that post.  My ud (device handle) does start over when I restart the application.

Any other suggestions?  Thank you again for taking the time.

--twotymz

[Snowman 6008]

two,

In your pseudo code you are calling ibdev to open a connection to the device, are you closing the connection when you are finished? For every time you open a resource you must close it out or you will get a leak. 

[twotymz]

Snowman,

From what I can tell, to close the device I should call ibonl (ud, 0) which is what I'm doing.  Is there another way to close the device?

--twotymz

[Snowman 6008]

two,

For some reason, i missed your #3. Can you post a simple example of your program to the forums? 

[twotymz]

As requested I've attached the source code to my program.  Thanks in advanced.

--twotymz

[Snowman 6008]

two,

I can take a look at this as soon as i find a spare machine, and install red-hat.

• Does your program require any drivers other than 488.2 ? 
• Can  you let me know how you compiled this program
• Are there any other needed files (header file, libraries, etc. )

[twotymz]

Thank you Snowman for taking the time.  I really do appreciate it.

To build the program, you only need the 488.2 drivers and the pthreads library.  No other special headers or libraries required.  Here's the command line I used to compile it:

g++ leak.cpp -lgpibapi -lpthread -o leak

The command line assumes that the libgpibapi.so library is in your linker's path.  If it's not you might need to use the -L command line option to specifiy its path.

Thanks again!

--twotymz

[Raj_V]

hey twotymz,

I managed to download your code and am now in the process of getting the hardware setup with linux so I can test this issue out. I will keep you posted on whatever I find.