free(): invalid pointer error with FlexLM calling dlopen

[janahan]

Dear all,

I develop a Flex-enabled application which used to run perfectly at my client's site, until a few days ago.
For some reasons, the application now crashes during FlexLM calls.

I use FlexLM 11.13.1.2, on RedHat 6.
My client runs the application on a cluster.

The backtrace looks like this:

*** glibc detected *** my_app: free(): invalid pointer: 0x00002b90a1b6b788 ***
======= Backtrace: =========
/lib64/libc.so.6[0x3a29c75dee]
/lib64/libc.so.6[0x3a29c78c3d]
/lib64/ld-linux-x86-64.so.2[0x3a29405fb5]
/lib64/ld-linux-x86-64.so.2[0x3a29408815]
/lib64/ld-linux-x86-64.so.2[0x3a29412ef5]
/lib64/ld-linux-x86-64.so.2[0x3a2940e5e6]
/lib64/ld-linux-x86-64.so.2[0x3a2941299a]
/lib64/libdl.so.2[0x3a29800f66]
/lib64/ld-linux-x86-64.so.2[0x3a2940e5e6]
/lib64/libdl.so.2[0x3a2980129c]
/lib64/libdl.so.2(dlopen+0x31)[0x3a29800ee1]
my_app[0x5c50f5]

I tried to track down the problem using Valgrind, which gave the following information:

==31984== Invalid free() / delete / delete[] / realloc()
==31984== at 0x4A07430: free (vg_replace_malloc.c:446)
==31984== by 0x317F405FB4: open_path (in /lib64/ld-2.12.so)
==31984== by 0x317F408814: _dl_map_object (in /lib64/ld-2.12.so)
==31984== by 0x317F412EF4: dl_open_worker (in /lib64/ld-2.12.so)
==31984== by 0x317F40E5E5: _dl_catch_error (in /lib64/ld-2.12.so)
==31984== by 0x317F412999: _dl_open (in /lib64/ld-2.12.so)
==31984== by 0x317F800F65: dlopen_doit (in /lib64/libdl-2.12.so)
==31984== by 0x317F40E5E5: _dl_catch_error (in /lib64/ld-2.12.so)
==31984== by 0x317F80129B: _dlerror_run (in /lib64/libdl-2.12.so)
==31984== by 0x317F800EE0: dlopen@@GLIBC_2.2.5 (in /lib64/libdl-2.12.so)
==31984== by 0x5C50F4: Ox5126e281158e0801 (in my_app)
==31984== by 0x5C53E5: Ox5126e45247908c3d (in my_app)
==31984== Address 0x317f622f28 is not stack'd, malloc'd or (recently) free'd

At this point, I am stucked because I cannot know what Ox5126e281158e0801 stands for.
But I am pretty confident that it is a FlexLM API function, since it is obfuscated.

Any idea how I could debug this further?
Maybe there is a way to get the FlexLM functions human-readable in backtraces?

Janahan

[aparashar1]

Hello Janahan, May i advise you to create a support case on this and let an specialist look into this with further details? It would help if we can have a hands on the sample application and exact steps that lead to this observation. Regards, Abhay

[janahan]

Thank you for your quick answer.

I will file a new support case right now.

Janahan