https://bugs.kde.org/show_bug.cgi?id=452274
--- Comment #4 from Nick Briggs <afraid-splicer...@icloud.com> --- It's different from valgrind-3.18.1-42b08ed5bd-20211015, where it typically dies with ==73265== Memcheck, a memory error detector ==73265== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==73265== Using Valgrind-3.18.1 and LibVEX; rerun with -h for copyright info ==73265== Command: /home/briggs/maiko/freebsd.386/ldex -timer 1000000 -g 1440x900 -sc 1440x900 -m 256 -t Medley_Interlisp /usr/home/briggs/medley/tmp/full.sysout ==73265== Parent PID: 73264 ==73265== ==73265== Syscall param sigprocmask(set) points to uninitialised byte(s) ==73265== at 0x7548D3F: _sigprocmask (in /lib/libc.so.7) ==73265== by 0x76992F9: ??? (src/lib/libthr/thread/thr_sig.c:288) ==73265== by 0x76988BD: ??? (src/lib/libthr/thread/thr_sig.c:246) ==73265== by 0x3819FB73: ??? (in /usr/local/libexec/valgrind/memcheck-x86-freebsd) ==73265== by 0x754709E: recvmsg (in /lib/libc.so.7) ==73265== by 0x765C3DE: ??? (in /usr/local/lib/libxcb.so.1.1.0) ==73265== by 0x765CF39: xcb_poll_for_event (in /usr/local/lib/libxcb.so.1.1.0) ==73265== by 0x73BD47F: ??? (in /usr/local/lib/libX11.so.6.4.0) ==73265== by 0x73BC69C: ??? (in /usr/local/lib/libX11.so.6.4.0) ==73265== by 0x73BC294: _XEventsQueued (in /usr/local/lib/libX11.so.6.4.0) ==73265== by 0x73BCCEE: _XFlush (in /usr/local/lib/libX11.so.6.4.0) ==73265== by 0x739F439: XFlush (in /usr/local/lib/libX11.so.6.4.0) ==73265== Address 0xfbbfdcec is on thread 1's stack ==73265== in frame #2, created by ??? (src/lib/libthr/thread/thr_sig.c:) ==73265== ==73265== Syscall param sigreturn(ucp) points to uninitialised byte(s) ==73265== at 0x75473FD: syscall (in /lib/libc.so.7) ==73265== by 0x76993AA: ??? (src/lib/libthr/thread/thr_sig.c:319) ==73265== by 0x76988BD: ??? (src/lib/libthr/thread/thr_sig.c:246) ==73265== by 0x3819FB73: ??? (in /usr/local/libexec/valgrind/memcheck-x86-freebsd) ==73265== by 0x754709E: recvmsg (in /lib/libc.so.7) ==73265== by 0x765C3DE: ??? (in /usr/local/lib/libxcb.so.1.1.0) ==73265== by 0x765CF39: xcb_poll_for_event (in /usr/local/lib/libxcb.so.1.1.0) ==73265== by 0x73BD47F: ??? (in /usr/local/lib/libX11.so.6.4.0) ==73265== by 0x73BC69C: ??? (in /usr/local/lib/libX11.so.6.4.0) ==73265== by 0x73BC294: _XEventsQueued (in /usr/local/lib/libX11.so.6.4.0) ==73265== by 0x73BCCEE: _XFlush (in /usr/local/lib/libX11.so.6.4.0) ==73265== by 0x739F439: XFlush (in /usr/local/lib/libX11.so.6.4.0) ==73265== Address 0xfbbfd9e0 is on thread 1's stack ==73265== in frame #1, created by ??? (src/lib/libthr/thread/thr_sig.c:) ==73265== ==73265== Invalid read of size 4 ==73265== at 0x769926B: ??? (src/lib/libthr/thread/thr_sig.c:262) ==73265== by 0x76988BD: ??? (src/lib/libthr/thread/thr_sig.c:246) ==73265== by 0x3819FB73: ??? (in /usr/local/libexec/valgrind/memcheck-x86-freebsd) ==73265== by 0x75471AE: sigprocmask (in /lib/libc.so.7) ==73265== by 0x74CEA84: setjmp (in /lib/libc.so.7) ==73265== Address 0x1bd97094 is not stack'd, malloc'd or (recently) free'd ==73265== ==73265== ==73265== Process terminating with default action of signal 11 (SIGSEGV): dumping core ==73265== Access not within mapped region at address 0x1BD97094 ==73265== at 0x769926B: ??? (src/lib/libthr/thread/thr_sig.c:262) ==73265== by 0x76988BD: ??? (src/lib/libthr/thread/thr_sig.c:246) ==73265== by 0x3819FB73: ??? (in /usr/local/libexec/valgrind/memcheck-x86-freebsd) ==73265== by 0x75471AE: sigprocmask (in /lib/libc.so.7) ==73265== by 0x74CEA84: setjmp (in /lib/libc.so.7) ==73265== If you believe this happened as a result of a stack ==73265== overflow in your program's main thread (unlikely but ==73265== possible), you can try to increase the size of the ==73265== main thread stack using the --main-stacksize= flag. ==73265== The main thread stack size used in this run was 16777216. ==73265== ==73265== HEAP SUMMARY: ==73265== in use at exit: 269,922,233 bytes in 692 blocks ==73265== total heap usage: 1,699 allocs, 1,007 frees, 270,522,703 bytes allocated ==73265== along with pid 73265 (memcheck-x86-freebs): sigreturn mc_flags fbbfe270 pid 73265 (memcheck-x86-freebs): sigreturn mc_flags fbbfe270 pid 73265 (memcheck-x86-freebs): sigreturn mc_flags 90909090 pid 73265 (memcheck-x86-freebs): sigreturn mc_flags 90909090 pid 73265 (memcheck-x86-freebs): sigreturn mc_flags 90909090 pid 73265 (memcheck-x86-freebs): sigreturn eflags = 0x0 pid 73265 (memcheck-x86-freebs): sigreturn mc_flags 1000 pid 73265 (memcheck-x86-freebs): sigreturn mc_flags 1000 Segmentation fault -- but per your request for trace syscalls, using the most recent version, yes it's using sys_poll, and yes, it's spewing: pid 73380 (memcheck-x86-freebs): sigreturn eflags = 0x200090 pid 73380 (memcheck-x86-freebs): sigreturn eflags = 0x200090 pid 73380 (memcheck-x86-freebs): sigreturn eflags = 0x200090 SYSCALL[73380,1](116) sys_gettimeofday ( 0xfbbfe82c, 0x0 )[sync] --> Success(0x0) SYSCALL[73380,1](209) sys_poll ( 0xfbbfe5e0, 1, -1 ) --> [async] ... valgrind: m_syswrap/syswrap-main.c:2130 (void vgPlain_client_syscall(ThreadId, UInt)): Assertion 'sci->status.what == SsIdle' failed. host stacktrace: ==73380== at 0x38116969: ??? (in /usr/home/briggs/valgrind/memcheck/memcheck-x86-freebsd) ==73380== by 0x38116C46: ??? (in /usr/home/briggs/valgrind/memcheck/memcheck-x86-freebsd) sched status: running_tid=1 Thread 1: status = VgTs_Runnable syscall 209 (lwpid 101239) ==73380== at 0x754AD3F: _sigprocmask (in /lib/libc.so.7) ==73380== by 0x77A32F9: ??? (src/lib/libthr/thread/thr_sig.c:288) ==73380== by 0x77A28BD: ??? (src/lib/libthr/thread/thr_sig.c:246) ==73380== by 0x381A05A3: ??? (in /usr/home/briggs/valgrind/memcheck/memcheck-x86-freebsd) ==73380== by 0x7548F3E: poll (in /lib/libc.so.7) ==73380== by 0x7768659: ??? (in /usr/local/lib/libxcb.so.1.1.0) ==73380== by 0x776993E: xcb_writev (in /usr/local/lib/libxcb.so.1.1.0) ==73380== by 0x73B6452: _XSend (in /usr/local/lib/libX11.so.6.4.0) ==73380== by 0x73B6CE3: _XFlush (in /usr/local/lib/libX11.so.6.4.0) ==73380== by 0x7399439: XFlush (in /usr/local/lib/libX11.so.6.4.0) ==73380== by 0x446379: clipping_Xbitblt (xbbt.c:55) ==73380== by 0x436E2D: flush_display_region (initdsp.c:303) ==73380== by 0x417682: bitblt_bitmap (bbtsub.c:834) ==73380== by 0x429787: OP_subrcall (subr.c:385) ==73380== by 0x41FE75: dispatch (xc.c:653) ==73380== by 0x43468B: start_lisp (main.c:612) ==73380== by 0x43428D: main (main.c:559) client stack range: [0xFBBFB000 0xFBBFEFFF] client SP: 0xFBBFD8D0 valgrind stack range: [0x52C6000 0x53C5FFF] top usage: 6488 of 1048576 Note: see also the FAQ in the source distribution. It contains workarounds to several common problems. In particular, if Valgrind aborted or crashed after identifying problems in your program, there's a good chance that fixing those problems will prevent Valgrind aborting or crashing, especially if it happened in m_mallocfree.c. If that doesn't help, please report this bug to: www.valgrind.org In the bug report, send all the above text, the valgrind version, and what OS and version you are using. Thanks. and yes, I re-ran autogen.sh, configure, (compiling with clang) and rebuilt it all. -rwxr-xr-x 1 briggs briggs 562723 Apr 4 12:36 configure -rwxr-xr-x 1 briggs briggs 170925 Apr 4 12:03 configure.ac -- You are receiving this mail because: You are watching all bug changes.
