https://bugs.kde.org/show_bug.cgi?id=495261
--- Comment #20 from Matthew Woehlke <[email protected]> --- I have a new/different backtrace: #0 __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44 #1 0x00007ffff5a81f63 in __pthread_kill_internal (threadid=<optimized out>, signo=6) at pthread_kill.c:89 #2 0x00007ffff5a27f3e in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26 #3 0x00007ffff5a0f6d0 in __GI_abort () at abort.c:77 #4 0x00007ffff5a106f3 in __libc_message_impl (fmt=fmt@entry=0x7ffff5bc24ec "%s\n") at ../sysdeps/posix/libc_fatal.c:134 #5 0x00007ffff5a8c035 in malloc_printerr (str=str@entry=0x7ffff5bc5768 "free(): invalid next size (fast)") at malloc.c:5829 #6 0x00007ffff5a8e63a in _int_free_chunk (av=<optimized out>, p=<optimized out>, size=<optimized out>, have_lock=have_lock@entry=0) at malloc.c:4611 #7 0x00007ffff5a91352 in _int_free (av=<optimized out>, p=<optimized out>, have_lock=0) at malloc.c:4699 #8 __GI___libc_free (mem=<optimized out>) at malloc.c:3476 #9 0x00007ffff6151dd8 in QMetaCallEvent::~QMetaCallEvent (this=0x7ffcd9651600) at /usr/src/debug/qt6-qtbase-6.9.3-1.fc42.x86_64/src/corelib/kernel/qobject.cpp:610 #10 0x00007ffff6151e45 in QMetaCallEvent::~QMetaCallEvent (this=0x7ffcd9651600) at /usr/src/debug/qt6-qtbase-6.9.3-1.fc42.x86_64/src/corelib/kernel/qobject.cpp:615 #11 0x00007ffff60fd470 in std::default_delete<QEvent>::operator() (this=<optimized out>, __ptr=0x7ffcd9651600) at /usr/include/c++/15/bits/unique_ptr.h:87 #12 std::unique_ptr<QEvent, std::default_delete<QEvent> >::~unique_ptr (this=<synthetic pointer>) at /usr/include/c++/15/bits/unique_ptr.h:399 #13 QCoreApplicationPrivate::sendPostedEvents (receiver=0x0, event_type=0, data=0x5555555b0dd0) at /usr/src/debug/qt6-qtbase-6.9.3-1.fc42.x86_64/src/corelib/kernel/qcoreapplication.cpp:1896 #14 0x00007ffff6410caf in postEventSourceDispatch (s=0x5555555f2930) at /usr/src/debug/qt6-qtbase-6.9.3-1.fc42.x86_64/src/corelib/kernel/qeventdispatcher_glib.cpp:246 I suspect `tzset` is a red herring. It looks to me like heap corruption... which, unfortunately, means it could be happening who-knows-where. I fired up an instance under valgrind that is probably going to run for a long, long time before parsing finishes, and may or may not find anything. -- You are receiving this mail because: You are watching all bug changes.
