I have a C application that I cross-compile for Windows from Fedora Linux:
$ x86_64-w64-mingw32-gcc --version
x86_64-w64-mingw32-gcc (GCC) 6.2.0 20160822 (Fedora MinGW 6.2.0-1.fc24)
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
The application uses atexit to register a teardown routine:
https://github.com/jdolan/Objectively/blob/master/Sources/Objectively/Class.c#L74
On some Windows systems, the registration of the atexit handler causes a crash:
Starting program: C:\Users\jay\Desktop\Quetoo\bin\quetoo.exe
[New Thread 2900.0xa48]
[New Thread 2900.0x9a4]
[New Thread 2900.0x310]
[New Thread 2900.0xcfc]
warning: HEAP[quetoo.exe]:
warning: Invalid address specified to RtlSizeHeap( 0000000002DD0000, 000000000010ED30 )
Program received signal SIGTRAP, Trace/breakpoint trap.
0x00007ff8c7cdfa56 in ntdll!RtlpNtMakeTemporaryKey () from C:\Windows\SYSTEM32\ntdll.dll
(gdb) bt
#0 0x00007ff8c7cdfa56 in ntdll!RtlpNtMakeTemporaryKey () from C:\Windows\SYSTEM32\ntdll.dll
#1 0x00007ff8c7cb1075 in ntdll!memset () from C:\Windows\SYSTEM32\ntdll.dll
#2 0x00007ff8c7cdf7c0 in ntdll!RtlpNtMakeTemporaryKey () from C:\Windows\SYSTEM32\ntdll.dll
#3 0x00007ff8c799a620 in msvcrt!.dllonexit () from C:\Windows\system32\msvcrt.dll
#4 0x000000006c28c91d in mingw_onexit () from C:\Users\jay\Desktop\Quetoo\bin\libObjectively-0.dll
#5 0x000000006c28c979 in atexit () from C:\Users\jay\Desktop\Quetoo\bin\libObjectively-0.dll
#6 0x000000006c28ca09 in __do_global_ctors () from C:\Users\jay\Desktop\Quetoo\bin\libObjectively-0.dll
#7 0x000000006c28136a in __DllMainCRTStartup (hDllHandle=0x6c280000, dwReason=1, lpreserved=0x25afb00)
at ../crt/crtdll.c:200
#8 0x00007ff8c7c04fc8 in ntdll!RtlActivateActivationContextUnsafeFast () from C:\Windows\SYSTEM32\ntdll.dll
#9 0x00007ff8c7c61d7a in ntdll!RtlAreBitsSet () from C:\Windows\SYSTEM32\ntdll.dll
#10 0x00007ff8c7c61bbf in ntdll!RtlAreBitsSet () from C:\Windows\SYSTEM32\ntdll.dll
#11 0x00007ff8c7c61bdd in ntdll!RtlAreBitsSet () from C:\Windows\SYSTEM32\ntdll.dll
#12 0x00007ff8c7c7fd6d in ntdll!EtwEventProviderEnabled () from C:\Windows\SYSTEM32\ntdll.dll
#13 0x00007ff8c7cb14f3 in ntdll!memset () from C:\Windows\SYSTEM32\ntdll.dll
#14 0x00007ff8c7c66a0e in ntdll!LdrInitializeThunk () from C:\Windows\SYSTEM32\ntdll.dll
#15 0x0000000000000000 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
(gdb)
This particular system is a fresh install of Windows 10. I tried running the application as an Administrator, with the same result.
Is there a different version of the msvcrt I should provide? Kinda stumped here.
Related
I have a compiled source code executable which has redefined malloc() with a custom function CustMalloc() using macro substitution.
As seen from the below backtrace, the compiled source code executable is supposed to be dynamically linked with libMRegAccess.so and libusb-1.0.so.0 shared objects. Both these shared objects were independently compiled and they have no means of knowing the above macro substitution during their compilation.
Now, bsd-asprintf.c I presume is a linux source file and the call to asprintf() and vasprintf() are called from the libusb-1.0.so.0 shared object when executing, which in turn tries to call malloc().
I'm unable to understand why the custom function CustMalloc() is getting called instead of the actual malloc().
FYI, the semaphore that is required in this backtrace is not yet created and hence the crash. The expectation is that the CustMalloc() should not be invoked in this code flow as the call is being made from an independently built shared object.
Program received signal SIGSEGV, Segmentation fault.
[Switching to LWP 1269]
0x0000007fb7f896cc in __new_sem_wait_fast () from /lib//libpthread.so.0
(gdb) bt
#0 0x0000007fb7f896cc in __new_sem_wait_fast () from /lib//libpthread.so.0
#1 0x0000007fb7f898fc in sem_wait##GLIBC_2.17 () from /lib//libpthread.so.0
#2 0x0000000001b09000 in SemTake (SemId=0x0) at <compiled_source_code.c>
#3 0x0000000000d6cffc in ContextLock () at <compiled_source_code.c>
#4 0x0000000000d993e4 in CustMalloc (size=128) at <compiled_source_code.c>
#5 0x0000000001c88a2c in vasprintf (str=0x7fb5eaf5f8, fmt=0x7fb7e8a640 "usb%s", ap=...) at bsd-asprintf.c:61
#6 0x0000000001c88c50 in asprintf (str=0x7fb5eaf5f8, fmt=0x7fb7e8a640 "usb%s") at bsd-asprintf.c:120
#7 0x0000007fb7e853cc in linux_enumerate_device () from /usr/lib/libusb-1.0.so.0
#8 0x0000007fb7e854c4 in sysfs_scan_device () from /usr/lib/libusb-1.0.so.0
#9 0x0000007fb7e85b80 in op_init () from /usr/lib/libusb-1.0.so.0
#10 0x0000007fb7e7dd1c in libusb_init () from /usr/lib/libusb-1.0.so.0
#11 0x0000007fb7ea65fc in cyusb_open(unsigned short, unsigned short) () from /usr/lib/libMRegAccess.so
#12 0x0000007fb7ea33f4 in InitDefaultUSBConn () from /usr/lib/libMRegAccess.so
#13 0x0000007fb7ea58e0 in openDefaultUSBDriver () from /usr/lib/libMRegAccess.so
#14 0x00000000010ddd94 in InitDrv () at <compiled_source_code.c>
#15 ... at <compiled_source_code.c>
#16 ... at <compiled_source_code.c>
#17 ... at <compiled_source_code.c>
#18 ... at <compiled_source_code.c>
#19 0x0000007fb7f80fd0 in start_thread () from /lib//libpthread.so.0
#20 0x0000007fb7d8cf60 in ?? () from /lib//libc.so.6
I'm unable to understand why the custom function CustMalloc() is getting called instead of the actual malloc()
This appears to be happening because you compiled and linked bsd-asprintf.c (with your macro redefinition) into your main executable.
You can tell that asprintf and CustMalloc are part of your binary, because their addresses are very different from other library routines (such as linux_enumerate_device or sem_wait).
If you want to know where asprintf is defined (which archive library or object file it comes from), relink your executable with -Wl,-y,asprintf flag, and the linker will tell you.
I'm trying to trace my segmentation fault using gdb and I'm unable to find the exact line where the fault is happening.
(gdb) backtrace
#0 0x00110402 in __kernel_vsyscall ()
#1 0x007a5690 in raise () from /lib/libc.so.6
#2 0x007a6f91 in abort () from /lib/libc.so.6
#3 0x007dd9eb in __libc_message () from /lib/libc.so.6
#4 0x007e59aa in _int_free () from /lib/libc.so.6
#5 0x007e90f0 in free () from /lib/libc.so.6
#6 0x080dc4e7 in CRYPTO_free ()
#7 0x08c36668 in ?? ()
#8 0x08c44bac in ?? ()
#9 0x08100168 in BN_free ()
#10 0x00000009 in ?? ()
#11 0x08c44ba8 in ?? ()
#12 0x08108c07 in BN_MONT_CTX_free ()
#13 0xffffffff in ?? ()
#14 0x08c36630 in ?? ()
#15 0x08112697 in RSA_eay_finish ()
#16 0x08c4c110 in ?? ()
#17 0x08c36630 in ?? ()
#18 0x081150af in RSA_free ()
#19 0xffffffff in ?? ()
#20 0x00000009 in ?? ()
#21 0x0821870d in ?? ()
#22 0x000000dd in ?? ()
#23 0x08c4c110 in ?? ()
#24 0x08c35e98 in ?? ()
#25 0x08136893 in EVP_PKEY_free ()
#26 0xffffffff in ?? ()
#27 0x0000000a in ?? ()
#28 0x08226017 in ?? ()
#29 0x00000189 in ?? ()
#30 0x007e90f0 in free () from /lib/libc.so.6
#31 0x00000000 in ?? ()
(gdb)
How do I get rid of the ?? () and get a more precise solution? Thank you.
First, getting the complete stack trace here will likely not help you: any crash inside free implementation is due to heap corruption. Here we have heap corruption that GLIBC has already detected and told you about on the console.
Knowing where the corrupted block is being freed usually doesn't help to find where the block was corrupted; use specialized tools like Valgrind or AddressSanitizer for that.
Second, you are not getting file/line info because the crash is happening inside libc.so.6, and you have not installed debuginfo symbols for it. How to install debuginfo depends on your Linux distribution, which you have not told us about.
Last, the reason you have an "apparently corrupt" stack with addresses that don't correspond to any symbols is likely that the calls are coming from hand-coded assembly code (from libopenssl.a), which doesn't use frame pointers and doesn't have correct unwind descriptors. GDB needs one or the other to produce correct stack trace.
Compile your project with -g -O0 flag. Without -g flag the gcc compiler will strip all the symbol out and that's why you cannot see any symbol. If you want debug 3rd party library then you should configure it with --with-debug or other debug option.
Yeah it looks like your stack is corrupted. The way I would approach this is to run the program under a memory profiler like valgrind. Watch out for double free, writing arrays out-of-bounds, and conditional jumps.
Our 32-bit server application statically embeds tcl 8.4.11. On Red Hat Linux 6.5 64-bit we're encountering crashes / core dumps. The failure looks like
alloc: invalid block: 0xf6f00f58: 88 f6 0
At the bottom of the question, I've documented two different core dumps we've seen.
We've isolated a potential root cause to a TCL object shared between two threads concurrently running separate TCL interpreter instances. We think it's because TCL object is passed to Tcl_IncrRefCount / Tcl_DecrRefCount from these concurrently executing TCL interpreters.
Are Tcl_IncrRefCount / Tcl_DecrRefCount thread safe when TCL is compiled threaded?
Are TCL objects shared by TCL interpreter instances? Is there any way to disable TCL object sharing across interpreter instances?
Is the situation any better in TCL version 8.6.3?
(gdb) bt
#0 __kernel_vsyscall () at arch/x86/vdso/vdso32/sysenter.S:49
#1 0x001b7871 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#2 0x001b914a in abort () at abort.c:92
#3 0x080f611c in Tcl_PanicVA ()
#4 0x080f613b in Tcl_Panic ()
#5 0x0810133c in Ptr2Block ()
#6 0x08100e04 in TclpFree ()
#7 0x080b46a7 in Tcl_Free ()
#8 0x08100686 in FreeStringInternalRep ()
#9 0x080fdac1 in ResetObjResult ()
#10 0x080fd316 in Tcl_GetStringResult ()
#11 0x0808aaad in run_tcl_proc (pDevice=0x8e0ba08, pInterp=0x8d798c0, iNumArgs=2, objv=0x115434c, bIsCommand=0 '\000', pCommand=0x0)
#12 0x08093672 in Tcl_begin_next_state (pDevice=0x8e0ba08, iNextState=RunPoll, pCommand=0x0)
#13 0x08093759 in Tcl_port_thread (dummy=0x8d1cab8)
#14 0x008bcb39 in start_thread (arg=0x1154b70) at pthread_create.c:301
#15 0x0026fc2e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:133
(gdb)
(gdb) bt
#0 __kernel_vsyscall () at arch/x86/vdso/vdso32/sysenter.S:49
#1 0x00395871 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#2 0x0039714a in abort () at abort.c:92
#3 0x080f611c in Tcl_PanicVA ()
#4 0x080f613b in Tcl_Panic ()
#5 0x0810133c in Ptr2Block ()
#6 0x08100e04 in TclpFree ()
#7 0x080b46a7 in Tcl_Free ()
#8 0x080d21b6 in TclExecuteByteCode ()
#9 0x080d1bc1 in TclCompEvalObj ()
#10 0x080fbd5c in TclObjInterpProc ()
#11 0x080b026a in TclEvalObjvInternal ()
#12 0x080d2716 in TclExecuteByteCode ()
#13 0x080d1bc1 in TclCompEvalObj ()
#14 0x080fbd5c in TclObjInterpProc ()
#15 0x080b026a in TclEvalObjvInternal ()
#16 0x080b0517 in Tcl_EvalObjv ()
#17 0x0808aa02 in run_tcl_proc (pDevice=0x94a2500, pInterp=0xac2bba0, iNumArgs=2, objv=0x11b034c, bIsCommand=0 '\000', pCommand=0x0)
#18 0x08093672 in Tcl_begin_next_state (pDevice=0x94a2500, iNextState=RunPoll, pCommand=0x0)
#19 0x08093759 in Tcl_port_thread (dummy=0x9365e98)
#20 0x00356b39 in start_thread (arg=0x11b0b70) at pthread_create.c:301
#21 0x0044dc2e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:133
(gdb)
The calls Tcl_IncrRefCount (actually a simple macro) and Tcl_DecrRefCount (a complicated macro) are sort of thread safe, but only because each Tcl_Obj should only ever be accessed from the thread that created it; parallel calls to T_IRC and T_DRC are fine, so long as they're on different values. The plus side of this is that accesses don't need locking (and the memory manager for Tcl_Obj structures takes advantage of this).
Note that multi-threaded access is not a good plan at all unless you're very careful, since even reader operations like Tcl_GetIntFromObj can write to the underlying structure if a type transformation needs to be applied. These operations are not locked. Doing it at all needs very intimate knowledge of the current type of the value — not something that you're usually encouraged to think about in Tcl in the first place, though tcl::unsupported::representation can be helpful with probing this in 8.6 — and some very careful interlocking between the threads so that one isn't writing while the other is peeking. Don't do this at all, while not 100% accurate, is the approach least likely to lead to headaches.
You probably ought to read more about how you're supposed to do it. The ActiveState blog has a reasonable introduction.
I have ubuntu 12.04 Linux on my PC and mono-complete package "Mono JIT compiler version 2.10.8.1 (Debian 2.10.8.1-1ubuntu2.2)".
I am going to run one .NET binary using mono and got SIGSEGV signal after running that binary and mono is going to be crashed after that.
I have also got some gdb debug messages on command prompt whihc i have mentioned below.
Thread 2 (Thread 0xb28ffb40 (LWP 20460)) :
#0 0xb7796424 in __kernel_vsyscall ()
#1 0xb77329db in read () from /lib/i386-linux-gnu/libpthread.so.0
#2 0x080e18e7 in read (__nbytes=1024, __buf=0xb2e0867c, __fd=<optimized out>) at /usr/include/i386-linux-gnu/bits/unistd.h:45
#3 mono_handle_native_sigsegv (signal=11, ctx=0xb2e08bcc) at mini-exceptions.c:2208
#4 0x081209fc in mono_arch_handle_altstack_exception (sigctx=0xb2e08bcc, fault_addr=0x0, stack_ovf=0) at exceptions-x86.c:1223
#5 0x0806094d in mono_sigsegv_signal_handler (_dummy=11, info=0xb2e08b4c, context=0xb2e08bcc) at mini.c:5909
#6 <signal handler called>
#7 0xb48881dc in ?? ()
#8 0xb2bcba6b in bulk_interrupt_read_thread (arguments=0xb4888108) at testusb.c:1596
#9 0xb772bd4c in start_thread () from /lib/i386-linux-gnu/libpthread.so.0
#10 0xb766adde in clone () from /lib/i386-linux-gnu/libc.so.6
Thread 1 (Thread 0xb757a700 (LWP 20449)) :
#0 0xb7796424 in __kernel_vsyscall ()
#1 0xb765c690 in poll () from /lib/i386-linux-gnu/libc.so.6
#2 0xb2c2c984 in ?? ()
#3 0xb2c2bdb0 in ?? ()
#4 0xb2c2e2d4 in ?? ()
#5 0xb2c4e770 in ?? ()
#6 0xb2c4b86c in ?? ()
#7 0xb2c4b527 in ?? ()
#8 0xb2e14518 in ?? ()
#9 0xb2e139a8 in ?? ()
#10 0xb2e13648 in ?? ()
#11 0xb58e3f84 in ?? ()
#12 0xb58e403e in ?? ()
#13 0x08064c2c in mono_jit_runtime_invoke (method="GTechUtility.Program:Main ()", obj=0x0, params=0xbfab491c, exc=0x0) at mini.c:5791
#14 0x081a422f in mono_runtime_invoke (method="GTechUtility.Program:Main ()", obj=0x0, params=0xbfab491c, exc=0x0) at object.c:2755
#15 0x081a7025 in mono_runtime_exec_main (method="GTechUtility.Program:Main ()", args=0x3be00, exc=0x0) at object.c:3938
#16 0x080bb80b in main_thread_handler (user_data=<synthetic pointer>) at driver.c:1003
#17 mono_main (argc=2, argv=0xbfab4ae4) at driver.c:1855
#18 0x0805998f in mono_main_with_options (argv=0xbfab4ae4, argc=2) at main.c:66
#19 main (argc=2, argv=0xbfab4ae4) at main.c:97
=================================================================
Got a SIGSEGV while executing native code.
This usually indicates a fatal error in the mono runtime or one of the native libraries used by your
application.
=================================================================
Aborted (core dumped)
Please let me know if any one have idea about this issue.
Try this: Disable increasing amounts of your own/application code until the error goes away. Then refine, with smaller steps, to see which part/line of your code is causing this.
If in the end, there is absolutely no own/application code left, play with the configuration, version, compiler options, of the libraries you're using.
Sorry I can't give you a detailed answer, but I HTH. Good luck!
I've been trying to debug a memory corruption problem with Perl 5 and XML::LibXML (which I now maintain). Now here's what I'm getting:
shlomif#lap:~/progs/perl/cpan/XML/LibXML/bugs/perl-xml-libxml-bugs/XML-LibXML-reader-segfault$ make test
XML_CATALOG_FILES="`pwd`/sgml-lib/catalog.xml" perl find_ascii_quotes.pl index.html
*** glibc detected *** perl: corrupted double-linked list: 0x0000000001474b40 ***
^Cmake: *** [test] Interrupt
And then the Perl process gets stuck and won't return to the shell. The thing is, the fact that the Perl process gets halted interrupts my flow, and I'm looking for a way for the process to just crash or whatever instead of hanging there. GDB reports the stuff below. One can find the code in question in its Mercurial repository (just run "make test"), and I'm on Mandriva Linux development (Cooker) on x86-64.
ader-segfault$ gdb --command=cmds.gdb /usr/bin/perl
GNU gdb (GDB) 7.1-5 (Mandriva Linux release 2011.0)
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-mandriva-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/bin/perl...
warning: the debug information found in "/usr/lib/debug//usr/bin/perl5.12.3.debug" does not match "/usr/bin/perl" (CRC mismatch).
warning: the debug information found in "/usr/lib/debug/usr/bin/perl5.12.3.debug" does not match "/usr/bin/perl" (CRC mismatch).
(no debugging symbols found)...done.
warning: the debug information found in "/usr/lib/debug//usr/lib/perl5/5.12.3/x86_64-linux-thread-multi/CORE/libperl.so.debug" does not match "/usr/lib/perl5/5.12.3/x86_64-linux-thread-multi/CORE/libperl.so" (CRC mismatch).
warning: the debug information found in "/usr/lib/debug/usr/lib/perl5/5.12.3/x86_64-linux-thread-multi/CORE/libperl.so.debug" does not match "/usr/lib/perl5/5.12.3/x86_64-linux-thread-multi/CORE/libperl.so" (CRC mismatch).
[Thread debugging using libthread_db enabled]
warning: the debug information found in "/usr/lib/debug//usr/lib/perl5/5.12.3/x86_64-linux-thread-multi/auto/Encode/Encode.so.debug" does not match "/usr/lib/perl5/5.12.3/x86_64-linux-thread-multi/auto/Encode/Encode.so" (CRC mismatch).
warning: the debug information found in "/usr/lib/debug/usr/lib/perl5/5.12.3/x86_64-linux-thread-multi/auto/Encode/Encode.so.debug" does not match "/usr/lib/perl5/5.12.3/x86_64-linux-thread-multi/auto/Encode/Encode.so" (CRC mismatch).
warning: the debug information found in "/usr/lib/debug//usr/lib/perl5/5.12.3/x86_64-linux-thread-multi/auto/Data/Dumper/Dumper.so.debug" does not match "/usr/lib/perl5/5.12.3/x86_64-linux-thread-multi/auto/Data/Dumper/Dumper.so" (CRC mismatch).
warning: the debug information found in "/usr/lib/debug/usr/lib/perl5/5.12.3/x86_64-linux-thread-multi/auto/Data/Dumper/Dumper.so.debug" does not match "/usr/lib/perl5/5.12.3/x86_64-linux-thread-multi/auto/Data/Dumper/Dumper.so" (CRC mismatch).
warning: the debug information found in "/usr/lib/debug//usr/lib/perl5/5.12.3/x86_64-linux-thread-multi/auto/IO/IO.so.debug" does not match "/usr/lib/perl5/5.12.3/x86_64-linux-thread-multi/auto/IO/IO.so" (CRC mismatch).
warning: the debug information found in "/usr/lib/debug/usr/lib/perl5/5.12.3/x86_64-linux-thread-multi/auto/IO/IO.so.debug" does not match "/usr/lib/perl5/5.12.3/x86_64-linux-thread-multi/auto/IO/IO.so" (CRC mismatch).
warning: the debug information found in "/usr/lib/debug//usr/lib/perl5/vendor_perl/5.12.3/x86_64-linux-thread-multi/auto/XML/LibXML/LibXML.so.debug" does not match "/usr/lib/perl5/vendor_perl/5.12.3/x86_64-linux-thread-multi/auto/XML/LibXML/LibXML.so" (CRC mismatch).
warning: the debug information found in "/usr/lib/debug/usr/lib/perl5/vendor_perl/5.12.3/x86_64-linux-thread-multi/auto/XML/LibXML/LibXML.so.debug" does not match "/usr/lib/perl5/vendor_perl/5.12.3/x86_64-linux-thread-multi/auto/XML/LibXML/LibXML.so" (CRC mismatch).
*** glibc detected *** /usr/bin/perl: corrupted double-linked list: 0x0000000000b83440 ***
^C
Program received signal SIGINT, Interrupt.
0x00007ffff6abe12e in __lll_lock_wait_private () from /lib64/libc.so.6
Missing debug package(s), you should install: perl-debug-5.12.3-8.x86_64
(gdb) bt
#0 0x00007ffff6abe12e in __lll_lock_wait_private () from /lib64/libc.so.6
#1 0x00007ffff6a4f7a1 in _L_lock_9854 () from /lib64/libc.so.6
#2 0x00007ffff6a4d6eb in malloc () from /lib64/libc.so.6
#3 0x00007ffff6a43d6d in __libc_message () from /lib64/libc.so.6
#4 0x00007ffff6a49bfa in malloc_printerr () from /lib64/libc.so.6
#5 0x00007ffff6a49f38 in malloc_consolidate.part.3 () from /lib64/libc.so.6
#6 0x00007ffff6a4a749 in _int_free () from /lib64/libc.so.6
#7 0x00007ffff4e8b0e0 in xmlHashFree__internal_alias (table=0xb2db40,
f=0x7ffff4e98e00 <xmlFreeAttribute>) at hash.c:324
#8 0x00007ffff4e82e42 in xmlFreeDtd__internal_alias (cur=0x633310)
at tree.c:1126
#9 0x00007ffff4e8259a in xmlFreeDoc__internal_alias (cur=0x635100)
at tree.c:1227
#10 0x00007ffff51e75a5 in PmmREFCNT_dec ()
from /usr/lib/perl5/vendor_perl/5.12.3/x86_64-linux-thread-multi/auto/XML/LibXML/LibXML.so
#11 0x00007ffff51c4f65 in XS_XML__LibXML__Node_DESTROY ()
from /usr/lib/perl5/vendor_perl/5.12.3/x86_64-linux-thread-multi/auto/XML/LibXML/LibXML.so
#12 0x00007ffff7b1d60d in Perl_pp_entersub ()
from /usr/lib/perl5/5.12.3/x86_64-linux-thread-multi/CORE/libperl.so
#13 0x00007ffff7ab9242 in Perl_call_sv ()
from /usr/lib/perl5/5.12.3/x86_64-linux-thread-multi/CORE/libperl.so
---Type <return> to continue, or q <return> to quit---
#14 0x00007ffff7b22cfa in Perl_sv_clear ()
from /usr/lib/perl5/5.12.3/x86_64-linux-thread-multi/CORE/libperl.so
#15 0x00007ffff7b23552 in Perl_sv_free2 ()
from /usr/lib/perl5/5.12.3/x86_64-linux-thread-multi/CORE/libperl.so
#16 0x00007ffff7b2314d in Perl_sv_clear ()
from /usr/lib/perl5/5.12.3/x86_64-linux-thread-multi/CORE/libperl.so
#17 0x00007ffff7b23552 in Perl_sv_free2 ()
from /usr/lib/perl5/5.12.3/x86_64-linux-thread-multi/CORE/libperl.so
#18 0x00007ffff51a6ad9 in XS_XML__LibXML__Reader__DESTROY ()
from /usr/lib/perl5/vendor_perl/5.12.3/x86_64-linux-thread-multi/auto/XML/LibXML/LibXML.so
#19 0x00007ffff7b1d60d in Perl_pp_entersub ()
from /usr/lib/perl5/5.12.3/x86_64-linux-thread-multi/CORE/libperl.so
#20 0x00007ffff7b14d70 in Perl_runops_standard ()
from /usr/lib/perl5/5.12.3/x86_64-linux-thread-multi/CORE/libperl.so
#21 0x00007ffff7ab9083 in Perl_call_sv ()
from /usr/lib/perl5/5.12.3/x86_64-linux-thread-multi/CORE/libperl.so
#22 0x00007ffff7b22cfa in Perl_sv_clear ()
from /usr/lib/perl5/5.12.3/x86_64-linux-thread-multi/CORE/libperl.so
#23 0x00007ffff7b23552 in Perl_sv_free2 ()
from /usr/lib/perl5/5.12.3/x86_64-linux-thread-multi/CORE/libperl.so
#24 0x00007ffff7b4a45f in Perl_leave_scope ()
from /usr/lib/perl5/5.12.3/x86_64-linux-thread-multi/CORE/libperl.so
---Type <return> to continue, or q <return> to quit---
#25 0x00007ffff7b15ad2 in Perl_pp_unstack ()
from /usr/lib/perl5/5.12.3/x86_64-linux-thread-multi/CORE/libperl.so
#26 0x00007ffff7b14d70 in Perl_runops_standard ()
from /usr/lib/perl5/5.12.3/x86_64-linux-thread-multi/CORE/libperl.so
#27 0x00007ffff7abed6e in perl_run ()
from /usr/lib/perl5/5.12.3/x86_64-linux-thread-multi/CORE/libperl.so
#28 0x0000000000400e29 in main ()
(gdb)
You can control the behaviour of glibc's memory checking with the MALLOC_CHECK_ environment variable. If you set this to '3' then it will print a message and abort() on any detected error.
See glibc's heap consistency checking documentation for for information - this actually might help you debug the error as enabling MALLOC_CHECK_ will perform consistency checks more often than it does by default (and hence catch the error sooner).
You may also want to look into Valgrind (if you haven't already) to assist in finding your corruption issue.
Your heap is getting corrupted. The corruption is almost certainly happening sometime earlier -- possibly much earlier -- because you are writing to memory you did not properly allocate (e.g., writing past the end of a malloc'd block).
You can try setting the MALLOC_CHECK_ environment variable to detect the problem sooner, but honestly your best bet is to use a tool like Purify or valgrind to catch the bad memory access at the moment it happens.