On Fri, 13 Jun 2008 12:09:04 +0100, Bhat, Ajit wrote: > Thanks but same application runs on Linux 4 ES? Memory deallocation corruption can depend on memory usage, stack usage, other run-time side-effects. Is it the same architecture (x86_64) on both installations? Same version of glibc? If not, why not? And in either case, which version of glibc is it? > Stack trace is - > > #0 0x0000003468f2e21d in raise () from /lib64/tls/libc.so.6 > (gdb) where > #0 0x0000003468f2e21d in raise () from /lib64/tls/libc.so.6 > #1 0x0000003468f2fa1e in abort () from /lib64/tls/libc.so.6 > #2 0x0000003468f63291 in __libc_message () from /lib64/tls/libc.so.6 > #3 0x0000003468f686b2 in malloc_consolidate () from > /lib64/tls/libc.so.6 > #4 0x0000003468f68c3a in _int_free () from /lib64/tls/libc.so.6 > #5 0x0000003468f691f6 in free () from /lib64/tls/libc.so.6 > #6 0x0000003468f30c69 in exit () from /lib64/tls/libc.so.6 > #7 0x0000003468f1c402 in __libc_start_main () from /lib64/tls/libc.so.6 > #8 0x0000000000584a8a in _start () Not sure this is correct. What application do you refer to? -- redhat-list mailing list unsubscribe mailto:redhat-list-request@xxxxxxxxxx?subject=unsubscribe https://www.redhat.com/mailman/listinfo/redhat-list
