by wintpe » Jun 19th, '12, 13:35
Did the program produce a core file? at the point of the memory corruption?
Malloc is a c function call that allocates a chunk of memory in ram and returns a pointer to it.
your program then uses that memory to store data, a bit like an array,.
what may have happened here is an incompatibility with versions of glib, that have caused malloc to write over another area memory not allocated to it, hence the term memory corruption has occured.
I think the only way you are going to get this to perform in a safe way, is to sandbox it into a chroot environment, where it only has access to compatible libraries. That does not guarrentee that its not going to occur because theres a point at which malloc will make a call to the kernel routines, and its maybe here that it fails.
In fact the line from your strace supports this
futex(0xb76bd3e0, FUTEX_WAIT_PRIVATE, 2, NULL) = ? ERESTARTSYS (To be restarted)
5880 --- {si_signo=SIGINT, si_code=SI_KERNEL, si_value={int=4131212846, ptr=0xf63d4e2e}} (Interrupt) ---
It maybe thats theres a newer version of the product that may be compiled against newer libraries, if so it would be worth trying it.
regards peter
Redhat 6 Certified Engineer (RHCE)
Sometimes my posts will sound short, or snappy, however its realy not my intention to offend, so accept my apologies in advance.