[KScreen] [Bug 484233] New: Arrangement specific display settings. (for only this specific display arrangment)
https://bugs.kde.org/show_bug.cgi?id=484233 Bug ID: 484233 Summary: Arrangement specific display settings. (for only this specific display arrangment) Classification: Plasma Product: KScreen Version: 6.0.2 Platform: openSUSE OS: Linux Status: REPORTED Severity: wishlist Priority: NOR Component: common Assignee: kscreen-bugs-n...@kde.org Reporter: jba1...@gmail.com Target Milestone: --- SUMMARY: Please restore some type of arrangement specific display settings. I frequently plug my laptop into a docking monitor as a second display. Typically in kde5/gnome, I would reduce the display resolution from 1920x1200 to 1200x800 when docked, as it is too far away for native res to be comfortable. I find reducing the resolution is less buggy than fractional scaling when dragging items between displays at different scales. When unplugging my laptop from the dock, it should return to its native resolution. Unfortunately this change is disruptive enough that I had to go back to gnome. (chromium titlebar bug prevents using KDE 5.27 - Bug 469266). PS. Thank you all of the hard work put into Plasma 6! -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 445743] "The impossible happened: mutex is locked simultaneously by two threads" while using mutexes with priority inheritance and signals
https://bugs.kde.org/show_bug.cgi?id=445743 --- Comment #19 from Nick Briggs --- c.f. restart_syscall(2) in the Linux kernel -- https://man7.org/linux/man-pages/man2/restart_syscall.2.html -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 459392] warning: The macro `AC_PROG_CC_C99' is obsolete
https://bugs.kde.org/show_bug.cgi?id=459392 Nick Briggs changed: What|Removed |Added CC||afraid-splicer...@icloud.co ||m -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 445743] "The impossible happened: mutex is locked simultaneously by two threads" while using mutexes with priority inheritance and signals
https://bugs.kde.org/show_bug.cgi?id=445743 Nick Briggs changed: What|Removed |Added CC||afraid-splicer...@icloud.co ||m --- Comment #15 from Nick Briggs --- Also note: drd/tests/pth_mutex_signal when run under simple memcheck, fails because pthread_mutex_lock() returns EINTR, while POSIX says of it (and related functions) "These functions shall not return an error code of [EINTR]." -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 452274] memcheck crashes with Assertion 'sci->status.what == SsIdle' failed
https://bugs.kde.org/show_bug.cgi?id=452274 --- Comment #28 from Nick Briggs --- Looks good. Thanks! I'd suggest, though, using something other than " " in the test (write(2, " ", 1);) so that it's more obvious if the output doesn't match, rather than trying to count spaces ;-) Now on to the next problem where the X library chokes sometimes when SIGVTALRMs go off -- not sure that it's just valgrind though. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 452274] memcheck crashes with Assertion 'sci->status.what == SsIdle' failed
https://bugs.kde.org/show_bug.cgi?id=452274 --- Comment #26 from Nick Briggs --- > Now how to determine if we are in either of those functions? I think it's actually any of 4 functions: 3805cd30 R vgModuleLocal_blksys_setup 3805cd34 R vgModuleLocal_blksys_restart 3805cd38 R vgModuleLocal_blksys_complete 3805cd3c R vgModuleLocal_blksys_committed 3805cd40 R vgModuleLocal_blksys_finished It's checking outside_range = ip < ML_(blksys_setup) || ip >= ML_(blksys_finished) so being in any of blksys_setup, blksys_restart, blksys_complete, blksys_committed is supposed to be OK. 40 years ago I had to debug this sort of junk in my own assembler code with an in-circuit emulator. Things haven't improved much, have they! -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 452274] memcheck crashes with Assertion 'sci->status.what == SsIdle' failed
https://bugs.kde.org/show_bug.cgi?id=452274
--- Comment #22 from Nick Briggs ---
I threw in a VG_(printf):
@@ -3117,6 +3119,7 @@ VG_(fixup_guest_state_after_syscall_interrupted)(
ThreadId tid,
if (VG_(clo_trace_signals))
VG_(message)( Vg_DebugMsg,
" not in syscall at all: hmm, very suspicious\n" );
+ VG_(printf)("DEBUG: blksys_setup %ld ip %ld blksys_finished %ld\n",
ML_(blksys_setup), ip, ML_(blksys_finished));
/* Looks like we weren't in a syscall at all. Hmm. */
vg_assert(sci->status.what != SsIdle);
return;
and see:
DEBUG: vgPlain_client_syscall sysno 4
DEBUG: vgPlain_client_syscall sysno 4
DEBUG: vgPlain_client_syscall sysno 4
DEBUG: vgPlain_client_syscall sysno 4
DEBUG: blksys_setup 941235726 ip 941508929 blksys_finished 941235863
DEBUG: vgPlain_client_syscall sci->status.what 2
DEBUG: vgPlain_client_syscall sysno 1000
and that ip is in x86g_calculate_eflags_all_WRK !
--
You are receiving this mail because:
You are watching all bug changes.
[valgrind] [Bug 452274] memcheck crashes with Assertion 'sci->status.what == SsIdle' failed
https://bugs.kde.org/show_bug.cgi?id=452274 --- Comment #21 from Nick Briggs --- Here's what happens with --trace-signals=yes and using the write(...) as the thing to be interrupted: DEBUG: vgPlain_client_syscall sysno 4 DEBUG: vgPlain_client_syscall sysno 4 DEBUG: vgPlain_client_syscall sysno 4 DEBUG: vgPlain_client_syscall sysno 4 DEBUG: vgPlain_client_syscall sysno 4 DEBUG: vgPlain_client_syscall sysno 4 --12231-- async signal handler: signal=26, vgtid=100118, tid=1, si_code=65542, exitreason VgSrc_None --12231-- interrupted_syscall: tid=1, ip=0x381a1e02, restart=False, sres.isErr=False, sres.val=0 --12231-- not started: restarting --12231-- delivering signal 26 (SIGVTALRM):65542 to thread 1 --12231-- push_signal_frame (thread 1): signal 26 ==12231==at 0x7303DBD: _write (in /lib/libc.so.7) ==12231==by 0x730236E: write (in /lib/libc.so.7) ==12231==by 0x4018ED: main (in /var/tmp/vgtest2) DEBUG: vgPlain_client_syscall sysno 1000 --12231-- VG_(signal_return) (thread 1): EIP=0x7303dbd DEBUG: vgPlain_client_syscall sysno 4 DEBUG: vgPlain_client_syscall sysno 4 DEBUG: vgPlain_client_syscall sysno 4 --12231-- async signal handler: signal=26, vgtid=100118, tid=1, si_code=65542, exitreason VgSrc_None --12231-- interrupted_syscall: tid=1, ip=0x381e4921, restart=False, sres.isErr=False, sres.val=0 --12231-- not in syscall at all: hmm, very suspicious --12231-- delivering signal 26 (SIGVTALRM):65542 to thread 1 --12231-- push_signal_frame (thread 1): signal 26 ==12231==at 0x7303DBF: _write (in /lib/libc.so.7) ==12231==by 0x730236E: write (in /lib/libc.so.7) ==12231==by 0x4018ED: main (in /var/tmp/vgtest2) DEBUG: vgPlain_client_syscall sci->status.what 2 DEBUG: vgPlain_client_syscall sysno 1000 valgrind: m_syswrap/syswrap-main.c:2142 (void vgPlain_client_syscall(ThreadId, UInt)): Assertion 'sci->status.what == SsIdle' failed. host stacktrace: ==12231==at 0x38116B19: ??? (in /usr/home/briggs/valgrind/memcheck/memcheck-x86-freebsd) ==12231==by 0x38116DF6: ??? (in /usr/home/briggs/valgrind/memcheck/memcheck-x86-freebsd) sched status: running_tid=1 Thread 1: status = VgTs_Runnable syscall 1000 (lwpid 100118) ==12231==at 0x381A0821: ??? (in /usr/home/briggs/valgrind/memcheck/memcheck-x86-freebsd) ==12231==by 0x4018ED: main (in /var/tmp/vgtest2) client stack range: [0xFBBFC000 0xFBBFEFFF] client SP: 0xFBBFE1E8 valgrind stack range: [0x51BE000 0x52BDFFF] top usage: 5792 of 1048576 Where the "very suspicious" message is from coregrind/m_syswrap/syswrap-main.c -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 452274] memcheck crashes with Assertion 'sci->status.what == SsIdle' failed
https://bugs.kde.org/show_bug.cgi?id=452274
--- Comment #20 from Nick Briggs ---
I'm not sure why the write() would be flagged non-blocking.
You can replace the write(...) in the test with read(0, NULL, 0) and get the
same result.
I also tried
int fd = open("/tmp/dummy", O_WRONLY, O_CREAT);
if (fd != -1) close(fd);
and got the failure. I wonder if it's possible that it fails with any of the
syscalls that are in the list in sigaction's SA_RESTART (although actually
*using* SA_RESTART doesn't seem to affect the test case)
%
The affected system calls include open(2), read(2), write(2),
sendto(2), recvfrom(2), sendmsg(2) and recvmsg(2) on a communications
channel or a slow device (such as a terminal, but not a regular file) and
during a wait(2) or ioctl(2). However, calls that have already committed
are not restarted, but instead return a partial success (for example, a
short read count).
%
I've made it fail with read(), write(), open(), wait(), but neither stat() nor
usleep().
--
You are receiving this mail because:
You are watching all bug changes.
[valgrind] [Bug 452274] memcheck crashes with Assertion 'sci->status.what == SsIdle' failed
https://bugs.kde.org/show_bug.cgi?id=452274 --- Comment #17 from Nick Briggs --- Created attachment 148033 --> https://bugs.kde.org/attachment.cgi?id=148033=edit C source test case This test case provokes the problem. cc -O2 -pipe vgtest2.c -o vgtest2 Running under valgrind: [...] DEBUG: vgPlain_client_syscall sysno 4 DEBUG: vgPlain_client_syscall sysno 4 DEBUG: vgPlain_client_syscall sysno 4 DEBUG: vgPlain_client_syscall sci->status.what 2 DEBUG: vgPlain_client_syscall sysno 1000 valgrind: m_syswrap/syswrap-main.c:2142 (void vgPlain_client_syscall(ThreadId, UInt)): Assertion 'sci->status.what == SsIdle' failed. host stacktrace: ==95237==at 0x381169B9: ??? (in /usr/home/briggs/valgrind/memcheck/memcheck-x86-freebsd) ==95237==by 0x38116C96: ??? (in /usr/home/briggs/valgrind/memcheck/memcheck-x86-freebsd) sched status: running_tid=1 Thread 1: status = VgTs_Runnable syscall 1000 (lwpid 100137) ==95237==at 0x381A0601: ??? (in /usr/home/briggs/valgrind/memcheck/memcheck-x86-freebsd) ==95237==by 0x4018FD: main (in /var/tmp/vgtest2) client stack range: [0xFBBFC000 0xFBBFEFFF] client SP: 0xFBBFE1E8 valgrind stack range: [0x51BE000 0x52BDFFF] top usage: 5792 of 1048576 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 452274] memcheck crashes with Assertion 'sci->status.what == SsIdle' failed
https://bugs.kde.org/show_bug.cgi?id=452274 --- Comment #16 from Nick Briggs --- Red herring. Removing the SA_RESTART doesn't change anything. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 452274] memcheck crashes with Assertion 'sci->status.what == SsIdle' failed
https://bugs.kde.org/show_bug.cgi?id=452274
--- Comment #15 from Nick Briggs ---
In case it matters... I just looked at the maiko code that sets up the VTALRM
signal, notice the SA_RESTART in the flags.
struct itimerval timert;
struct sigaction timer_action;
timer_action.sa_handler = int_timer_service;
sigemptyset(_action.sa_mask);
timer_action.sa_flags = SA_RESTART;
if (sigaction(SIGVTALRM, _action, NULL) == -1) {
perror("sigaction: SIGVTALRM");
}
/* then attach a timer to it and turn it loose */
timert.it_interval.tv_sec = timert.it_value.tv_sec = 0;
timert.it_interval.tv_usec = timert.it_value.tv_usec = TIMER_INTERVAL;
setitimer(ITIMER_VIRTUAL, , NULL);
--
You are receiving this mail because:
You are watching all bug changes.
[valgrind] [Bug 452274] memcheck crashes with Assertion 'sci->status.what == SsIdle' failed
https://bugs.kde.org/show_bug.cgi?id=452274 --- Comment #14 from Nick Briggs --- I turned back on the trace syscalls and ran it again (also fixed up the msg about the state) -- DEBUG: vgPlain_client_syscall sysno 209 SYSCALL[94860,1](209) sys_poll ( 0xfbbfe5c0, 1, -1 ) --> [async] ... SYSCALL[94860,1](209) ... [async] --> Success(0x1) DEBUG: vgPlain_client_syscall sysno 121 SYSCALL[94860,1](121) sys_writev ( 7, 0xfbbfe6bc, 3 ) --> [async] ... SYSCALL[94860,1](121) ... [async] --> Success(0x48) DEBUG: vgPlain_client_syscall sysno 27 SYSCALL[94860,1]( 27) sys_recvmsg ( 7, 0xfbbfe5cc, 0 ) --> [async] ... SYSCALL[94860,1]( 27) ... [async] --> Failure(0x23) DEBUG: vgPlain_client_syscall sysno 209 SYSCALL[94860,1](209) sys_poll ( 0xfbbfe5c0, 1, -1 ) --> [async] ... SYSCALL[94860,1](209) ... [async] --> Success(0x1) DEBUG: vgPlain_client_syscall sysno 121 SYSCALL[94860,1](121) sys_writev ( 7, 0xfbbfe6bc, 3 ) --> [async] ... DEBUG: vgPlain_client_syscall sci->status.what 2 DEBUG: vgPlain_client_syscall sysno 340 valgrind: m_syswrap/syswrap-main.c:2142 (void vgPlain_client_syscall(ThreadId, UInt)): Assertion 'sci->status.what == SsIdle' failed. host stacktrace: ==94860==at 0x381169B9: ??? (in /usr/home/briggs/valgrind/memcheck/memcheck-x86-freebsd) ==94860==by 0x38116C96: ??? (in /usr/home/briggs/valgrind/memcheck/memcheck-x86-freebsd) sched status: running_tid=1 Thread 1: status = VgTs_Runnable syscall 340 (lwpid 100133) ==94860==at 0x754AD3F: _sigprocmask (in /lib/libc.so.7) ==94860==by 0x77A32F9: ??? (src/lib/libthr/thread/thr_sig.c:288) ==94860==by 0x77A28BD: ??? (src/lib/libthr/thread/thr_sig.c:246) ==94860==by 0x381A05F3: ??? (in /usr/home/briggs/valgrind/memcheck/memcheck-x86-freebsd) ==94860==by 0x754939E: writev (in /lib/libc.so.7) ==94860==by 0x7768808: ??? (in /usr/local/lib/libxcb.so.1.1.0) ==94860==by 0x776993E: xcb_writev (in /usr/local/lib/libxcb.so.1.1.0) ==94860==by 0x73B6452: _XSend (in /usr/local/lib/libX11.so.6.4.0) -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 452274] memcheck crashes with Assertion 'sci->status.what == SsIdle' failed
https://bugs.kde.org/show_bug.cgi?id=452274 --- Comment #13 from Nick Briggs --- DEBUG: vgPlain_client_syscall sysno 121 DEBUG: vgPlain_client_syscall sysno 27 DEBUG: vgPlain_client_syscall sysno 116 DEBUG: vgPlain_client_syscall sysno 116 DEBUG: vgPlain_client_syscall sysno 116 DEBUG: vgPlain_client_syscall sysno 240 DEBUG: vgPlain_client_syscall sysno 27 DEBUG: vgPlain_client_syscall sysno 116 DEBUG: vgPlain_client_syscall sysno 209 DEBUG: vgPlain_client_syscall sysno 121 DEBUG: vgPlain_client_syscall sysno 27 DEBUG: vgPlain_client_syscall sysno 209 DEBUG: vgPlain_client_syscall sysno 121 DEBUG: vgPlain_client_syscall sysno 27 DEBUG: vgPlain_client_syscall sysno 209 DEBUG: vgPlain_client_syscall sysno 121 DEBUG: vgPlain_client_syscall sysno 27 DEBUG: vgPlain_client_syscall sysno 209 DEBUG: vgPlain_client_syscall sysno 121 DEBUG: vgPlain_client_syscall sysno 27 DEBUG: vgPlain_client_syscall sysno 209 DEBUG: vgPlain_client_syscall 2 DEBUG: vgPlain_client_syscall sysno 340 valgrind: m_syswrap/syswrap-main.c:2142 (void vgPlain_client_syscall(ThreadId, UInt)): Assertion 'sci->status.what == SsIdle' failed. host stacktrace: ==94241==at 0x381169A9: ??? (in /usr/home/briggs/valgrind/memcheck/memcheck-x86-freebsd) ==94241==by 0x38116C86: ??? (in /usr/home/briggs/valgrind/memcheck/memcheck-x86-freebsd) sched status: running_tid=1 Thread 1: status = VgTs_Runnable syscall 340 (lwpid 100133) ==94241==at 0x754AD3F: _sigprocmask (in /lib/libc.so.7) ==94241==by 0x77A32F9: ??? (src/lib/libthr/thread/thr_sig.c:288) ==94241==by 0x77A28BD: ??? (src/lib/libthr/thread/thr_sig.c:246) ==94241==by 0x381A05E3: ??? (in /usr/home/briggs/valgrind/memcheck/memcheck-x86-freebsd) ==94241==by 0x7548F3E: poll (in /lib/libc.so.7) ==94241==by 0x7768659: ??? (in /usr/local/lib/libxcb.so.1.1.0) -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 452274] memcheck crashes with Assertion 'sci->status.what == SsIdle' failed
https://bugs.kde.org/show_bug.cgi?id=452274 --- Comment #12 from Nick Briggs --- It's easier for you to build maiko now than it used to be. See https://github.com/Interlisp/maiko but you also need a medley Interlisp release, https://github.com/interlisp/medley -- and it gets a bit tricky to get to the right place to cause this trouble. I'll go ahead and make the changes you asked for and report back. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 452274] memcheck crashes with Assertion 'sci->status.what == SsIdle' failed
https://bugs.kde.org/show_bug.cgi?id=452274 --- Comment #10 from Nick Briggs --- It's 2 (SsHandToKernel) when it crashes. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 452274] memcheck crashes with Assertion 'sci->status.what == SsIdle' failed
https://bugs.kde.org/show_bug.cgi?id=452274 --- Comment #7 from Nick Briggs --- It generates plenty of pid 79880 (memcheck-x86-freebs): sigreturn eflags = 0x24 pid 79880 (memcheck-x86-freebs): sigreturn eflags = 0x200094 pid 79880 (memcheck-x86-freebs): sigreturn eflags = 0x200094 pid 79880 (memcheck-x86-freebs): sigreturn eflags = 0x200084 pid 79880 (memcheck-x86-freebs): sigreturn eflags = 0x200084 pid 79880 (memcheck-x86-freebs): sigreturn eflags = 0x200084 but it still crashes with SYSCALL[79880,1]( 27) sys_recvmsg ( 7, 0xfbbfe5ec, 0 ) --> [async] ... SYSCALL[79880,1]( 27) ... [async] --> Failure(0x23) SYSCALL[79880,1](209) sys_poll ( 0xfbbfe5e0, 1, -1 ) --> [async] ... SYSCALL[79880,1](209) ... [async] --> Success(0x1) SYSCALL[79880,1](121) sys_writev ( 7, 0xfbbfe6dc, 3 ) --> [async] ... SYSCALL[79880,1](121) ... [async] --> Success(0x48) SYSCALL[79880,1]( 27) sys_recvmsg ( 7, 0xfbbfe5ec, 0 ) --> [async] ... SYSCALL[79880,1]( 27) ... [async] --> Failure(0x23) SYSCALL[79880,1](209) sys_poll ( 0xfbbfe5e0, 1, -1 ) --> [async] ... SYSCALL[79880,1](209) ... [async] --> Success(0x1) SYSCALL[79880,1](121) sys_writev ( 7, 0xfbbfe6dc, 3 ) --> [async] ... SYSCALL[79880,1](121) ... [async] --> Success(0x48) SYSCALL[79880,1]( 27) sys_recvmsg ( 7, 0xfbbfe5ec, 0 ) --> [async] ... SYSCALL[79880,1]( 27) ... [async] --> Failure(0x23) SYSCALL[79880,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: ==79880==at 0x38116979: ??? (in /usr/home/briggs/valgrind/memcheck/memcheck-x86-freebsd) ==79880==by 0x38116C56: ??? (in /usr/home/briggs/valgrind/memcheck/memcheck-x86-freebsd) sched status: running_tid=1 Thread 1: status = VgTs_Runnable syscall 209 (lwpid 100159) ==79880==at 0x754AD3F: _sigprocmask (in /lib/libc.so.7) ==79880==by 0x77A32F9: ??? (src/lib/libthr/thread/thr_sig.c:288) ==79880==by 0x77A28BD: ??? (src/lib/libthr/thread/thr_sig.c:246) ==79880==by 0x381A05B3: ??? (in /usr/home/briggs/valgrind/memcheck/memcheck-x86-freebsd) ==79880==by 0x7548F3E: poll (in /lib/libc.so.7) ==79880==by 0x7768659: ??? (in /usr/local/lib/libxcb.so.1.1.0) ==79880==by 0x776993E: xcb_writev (in /usr/local/lib/libxcb.so.1.1.0) ==79880==by 0x73B6452: _XSend (in /usr/local/lib/libX11.so.6.4.0) ==79880==by 0x73B6CE3: _XFlush (in /usr/local/lib/libX11.so.6.4.0) ==79880==by 0x7399439: XFlush (in /usr/local/lib/libX11.so.6.4.0) ==79880==by 0x446379: clipping_Xbitblt (xbbt.c:55) ==79880==by 0x436ECD: flush_display_lineregion (initdsp.c:346) ==79880==by 0x4194B0: newbltchar (bbtsub.c:1424) ==79880==by 0x429F67: OP_subrcall (subr.c:374) ==79880==by 0x41FE75: dispatch (xc.c:653) ==79880==by 0x43468B: start_lisp (main.c:612) ==79880==by 0x43428D: main (main.c:559) client stack range: [0xFBBFB000 0xFBBFEFFF] client SP: 0xFBBFD8D0 valgrind stack range: [0x52C6000 0x53C5FFF] top usage: 6488 of 1048576 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 452274] memcheck crashes with Assertion 'sci->status.what == SsIdle' failed
https://bugs.kde.org/show_bug.cgi?id=452274 --- Comment #4 from Nick Briggs --- 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 100 -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
[valgrind] [Bug 452274] New: memcheck crashes with Assertion 'sci->status.what == SsIdle' failed
https://bugs.kde.org/show_bug.cgi?id=452274 Bug ID: 452274 Summary: memcheck crashes with Assertion 'sci->status.what == SsIdle' failed Product: valgrind Version: 3.19 GIT Platform: FreeBSD Ports OS: FreeBSD Status: REPORTED Severity: crash Priority: NOR Component: memcheck Assignee: jsew...@acm.org Reporter: afraid-splicer...@icloud.com Target Milestone: --- SUMMARY Running the latest valgrind from git, valgrind-3.19.0.RC1-615731617b-20220404 on FreeBSD 13.0-RELEASE-p8 on i386 hardware generated an assertion failure: ==56733== Memcheck, a memory error detector ==56733== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==56733== Using Valgrind-3.19.0.RC1 and LibVEX; rerun with -h for copyright info ==56733== Command: /home/briggs/maiko/freebsd.386/ldex -timer 100 -g 1440x900 -sc 1440x900 -m 256 -t Medley_Interlisp /usr/home/briggs/medley/tmp/full.sysout ==56733== Parent PID: 56731 ==56733== valgrind: m_syswrap/syswrap-main.c:2130 (void vgPlain_client_syscall(ThreadId, UInt)): Assertion 'sci->status.what == SsIdle' failed. host stacktrace: ==56733==at 0x38116969: ??? (in /usr/home/briggs/valgrind/memcheck/memcheck-x86-freebsd) ==56733==by 0x38116C46: ??? (in /usr/home/briggs/valgrind/memcheck/memcheck-x86-freebsd) sched status: running_tid=1 Thread 1: status = VgTs_Runnable syscall 209 (lwpid 100366) ==56733==at 0x754AD3F: _sigprocmask (in /lib/libc.so.7) ==56733==by 0x77A32F9: ??? (src/lib/libthr/thread/thr_sig.c:288) ==56733==by 0x77A28BD: ??? (src/lib/libthr/thread/thr_sig.c:246) ==56733==by 0x381A05A3: ??? (in /usr/home/briggs/valgrind/memcheck/memcheck-x86-freebsd) ==56733==by 0x7548F3E: poll (in /lib/libc.so.7) ==56733==by 0x7768659: ??? (in /usr/local/lib/libxcb.so.1.1.0) ==56733==by 0x776993E: xcb_writev (in /usr/local/lib/libxcb.so.1.1.0) ==56733==by 0x73B6452: _XSend (in /usr/local/lib/libX11.so.6.4.0) ==56733==by 0x73B6CE3: _XFlush (in /usr/local/lib/libX11.so.6.4.0) ==56733==by 0x7399439: XFlush (in /usr/local/lib/libX11.so.6.4.0) ==56733==by 0x446379: clipping_Xbitblt (xbbt.c:55) ==56733==by 0x436ECD: flush_display_lineregion (initdsp.c:346) ==56733==by 0x4194B0: newbltchar (bbtsub.c:1424) ==56733==by 0x429F67: OP_subrcall (subr.c:374) ==56733==by 0x41FE75: dispatch (xc.c:653) ==56733==by 0x43468B: start_lisp (main.c:612) ==56733==by 0x43428D: main (main.c:559) client stack range: [0xFBBFB000 0xFBBFEFFF] client SP: 0xFBBFD8D0 valgrind stack range: [0x52C6000 0x53C5FFF] top usage: 6488 of 1048576 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 445032] valgrind/memcheck crash with SIGSEGV when SIGVTALRM timer used and libthr.so associated
https://bugs.kde.org/show_bug.cgi?id=445032 --- Comment #14 from Nick Briggs --- (In reply to Paul Floyd from comment #13) > The kernel messages are because now it 'works as unintended'. > > It's a bit annoying as this is the kernel writing to the console so you > can't redirect it to /dev/null. It's also a bit delicate because if the > eflags test gets fixed then the following CS test is do-or-die and will > cause a SIGBUS if it fails rather than just failing with a kernel message. Perhaps I should put in a request for a FreeBSD kernel option... sysctl kern.eflags.stfu=1 so one could acknowledge that one knows, but the kernel should stop whinging about it. ;-) -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 445032] valgrind/memcheck crash with SIGSEGV when SIGVTALRM timer used and libthr.so associated
https://bugs.kde.org/show_bug.cgi?id=445032 --- Comment #12 from Nick Briggs --- I've rebuilt based on the latest git version, and concur that the SIGSEGV is fixed. Now it just offers up a continuous stream of "sigreturn eflags..." % grep memcheck-x86 /tmp/out | sort | uniq -c 93 pid 68162 (memcheck-x86-freebs): sigreturn eflags = 0x20 77 pid 68162 (memcheck-x86-freebs): sigreturn eflags = 0x24 46 pid 68162 (memcheck-x86-freebs): sigreturn eflags = 0x200010 4 pid 68162 (memcheck-x86-freebs): sigreturn eflags = 0x200011 31 pid 68162 (memcheck-x86-freebs): sigreturn eflags = 0x200014 43 pid 68162 (memcheck-x86-freebs): sigreturn eflags = 0x200044 4 pid 68162 (memcheck-x86-freebs): sigreturn eflags = 0x200055 224 pid 68162 (memcheck-x86-freebs): sigreturn eflags = 0x200080 12 pid 68162 (memcheck-x86-freebs): sigreturn eflags = 0x200081 240 pid 68162 (memcheck-x86-freebs): sigreturn eflags = 0x200084 52 pid 68162 (memcheck-x86-freebs): sigreturn eflags = 0x200085 20 pid 68162 (memcheck-x86-freebs): sigreturn eflags = 0x200090 12 pid 68162 (memcheck-x86-freebs): sigreturn eflags = 0x200091 20 pid 68162 (memcheck-x86-freebs): sigreturn eflags = 0x200094 82 pid 68162 (memcheck-x86-freebs): sigreturn eflags = 0x200095 70 pid 68162 (memcheck-x86-freebs): sigreturn eflags = 0x200801 128 pid 68162 (memcheck-x86-freebs): sigreturn eflags = 0x200805 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 445032] valgrind/memcheck crash with SIGSEGV when SIGVTALRM timer used and libthr.so associated
https://bugs.kde.org/show_bug.cgi?id=445032 --- Comment #8 from Nick Briggs --- I compiled a debug version of libthr.so.3 which produces this stack trace on failure: ``` $ valgrind ./vgtest-thr ==56575== Memcheck, a memory error detector ==56575== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==56575== Using Valgrind-3.18.1 and LibVEX; rerun with -h for copyright info ==56575== Command: ./vgtest-thr ==56575== ==56575== Invalid read of size 4 ==56575==at 0x720526B: ??? (src/lib/libthr/thread/thr_sig.c:262) ==56575==by 0x72048BD: ??? (src/lib/libthr/thread/thr_sig.c:246) ==56575==by 0x3819FB73: ??? (in /usr/local/libexec/valgrind/memcheck-x86-freebsd) ==56575==by 0x73B973E: sleep (in /lib/libc.so.7) ==56575==by 0x4018F2: main (in /var/tmp/vgtest-thr) ==56575== Address 0x0 is not stack'd, malloc'd or (recently) free'd ==56575== ``` thr_sig.c:246 is within `thr_sighandler(int sig, siginfo_t *info, void *_ucp)` where it calls `handle_signal(, sig, info, ucp);` which immediately dies on ``` /* add previous level mask */ SIGSETOR(actp->sa_mask, ucp->uc_sigmask); ``` -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 445032] valgrind/memcheck crash with SIGSEGV when SIGVTALRM timer used and libthr.so associated
https://bugs.kde.org/show_bug.cgi?id=445032 --- Comment #7 from Nick Briggs --- No ASLR in use here -- I've got the default settings: ``` $ sysctl -a | grep aslr kern.elf32.aslr.stack_gap: 3 kern.elf32.aslr.honor_sbrk: 1 kern.elf32.aslr.pie_enable: 0 kern.elf32.aslr.enable: 0 vm.aslr_restarts: 0 ``` -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 445032] valgrind/memcheck crash with SIGSEGV when SIGVTALRM timer used and libthr.so associated
https://bugs.kde.org/show_bug.cgi?id=445032 --- Comment #3 from Nick Briggs --- It doesn't fail in a VirtualBox running FreeBSD 13.0 on hardware that reports out as: CPU: Intel(R) Core(TM)2 Duo CPU T9800 @ 2.93GHz (2918.76-MHz 686-class CPU) Origin="GenuineIntel" Id=0x1067a Family=0x6 Model=0x17 Stepping=10 Features=0x1783fbbf Features2=0x82209 AMD Features2=0x1 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 445032] valgrind/memcheck crash with SIGSEGV when SIGVTALRM timer used and libthr.so associated
https://bugs.kde.org/show_bug.cgi?id=445032 --- Comment #2 from Nick Briggs --- I was running this on CPU: Intel(R) Pentium(R) M processor 1.70GHz (966.40-MHz 686-class CPU) Origin="GenuineIntel" Id=0x6d6 Family=0x6 Model=0xd Stepping=6 Features=0xafe9f9bf Features2=0x180 I can try the VirtualBox route also and see if it's reproducible here, on different Intel hardware -- was your test case on AMD or Intel? -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 445032] New: valgrind/memcheck crash with SIGSEGV when SIGVTALRM timer used and libthr.so associated
https://bugs.kde.org/show_bug.cgi?id=445032 Bug ID: 445032 Summary: valgrind/memcheck crash with SIGSEGV when SIGVTALRM timer used and libthr.so associated Product: valgrind Version: unspecified Platform: FreeBSD Ports OS: FreeBSD Status: REPORTED Severity: crash Priority: NOR Component: memcheck Assignee: jsew...@acm.org Reporter: afraid-splicer...@icloud.com Target Milestone: --- Created attachment 143251 --> https://bugs.kde.org/attachment.cgi?id=143251=edit C test case for valgrind segmentation fault SUMMARY A program which uses an interval timer (e.g., ITIMER_VIRTUAL w/ SIGVTALRM handler), linked with libthr.so, will take a SIGSEGV when run under valgrind STEPS TO REPRODUCE 1. Compile provided sample, vgtest.c -- cc is FreeBSD clang version 11.0.1 cc -pthread /var/tmp/vgtest.c -o /var/tmp/vgtest 2. Run it under valgrind valgrind /var/tmp/vgtest 3. Compiling the same test case without -pthread option runs without error. OBSERVED RESULT $ ldd /var/tmp/vgtest /var/tmp/vgtest: libthr.so.3 => /lib/libthr.so.3 (0x20442000) libc.so.7 => /lib/libc.so.7 (0x2046b000) $ valgrind /var/tmp/vgtest ==28547== Memcheck, a memory error detector ==28547== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==28547== Using Valgrind-3.18.1 and LibVEX; rerun with -h for copyright info ==28547== Command: /var/tmp/vgtest ==28547== ==28547== Invalid read of size 4 ==28547==at 0x71FFB9B: ??? (in /lib/libthr.so.3) ==28547==by 0x71FF16F: ??? (in /lib/libthr.so.3) ==28547==by 0x3819FB73: ??? (in /usr/local/libexec/valgrind/memcheck-x86-freebsd) ==28547==by 0x72B973E: sleep (in /lib/libc.so.7) ==28547==by 0x4018F2: main (in /var/tmp/vgtest) ==28547== Address 0x0 is not stack'd, malloc'd or (recently) free'd ==28547== ==28547== ==28547== Process terminating with default action of signal 11 (SIGSEGV): dumping core ==28547== Access not within mapped region at address 0x0 ==28547==at 0x71FFB9B: ??? (in /lib/libthr.so.3) ==28547==by 0x71FF16F: ??? (in /lib/libthr.so.3) ==28547==by 0x3819FB73: ??? (in /usr/local/libexec/valgrind/memcheck-x86-freebsd) ==28547==by 0x72B973E: sleep (in /lib/libc.so.7) ==28547==by 0x4018F2: main (in /var/tmp/vgtest) ==28547== If you believe this happened as a result of a stack ==28547== overflow in your program's main thread (unlikely but ==28547== possible), you can try to increase the size of the ==28547== main thread stack using the --main-stacksize= flag. ==28547== The main thread stack size used in this run was 16777216. ==28547== ==28547== HEAP SUMMARY: ==28547== in use at exit: 724 bytes in 2 blocks ==28547== total heap usage: 2 allocs, 0 frees, 724 bytes allocated ==28547== ==28547== LEAK SUMMARY: ==28547==definitely lost: 0 bytes in 0 blocks ==28547==indirectly lost: 0 bytes in 0 blocks ==28547== possibly lost: 0 bytes in 0 blocks ==28547==still reachable: 724 bytes in 2 blocks ==28547== suppressed: 0 bytes in 0 blocks ==28547== Rerun with --leak-check=full to see details of leaked memory ==28547== ==28547== For lists of detected and suppressed errors, rerun with: -s ==28547== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 1 from 1) Segmentation fault $ EXPECTED RESULT $ valgrind /var/tmp/vgtest ==28579== Memcheck, a memory error detector ==28579== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==28579== Using Valgrind-3.18.1 and LibVEX; rerun with -h for copyright info ==28579== Command: /var/tmp/vgtest ==28579== ==28579== ==28579== HEAP SUMMARY: ==28579== in use at exit: 0 bytes in 0 blocks ==28579== total heap usage: 0 allocs, 0 frees, 0 bytes allocated ==28579== ==28579== All heap blocks were freed -- no leaks are possible ==28579== ==28579== For lists of detected and suppressed errors, rerun with: -s ==28579== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 1 from 1) SOFTWARE/OS VERSIONS $ uname -a FreeBSD flap.gateway.sonic.net 13.0-RELEASE-p4 FreeBSD 13.0-RELEASE-p4 #0: Tue Aug 24 18:58:48 UTC 2021 r...@amd64-builder.daemonology.net:/usr/obj/usr/src/i386.i386/sys/GENERIC i386 $ valgrind --version valgrind-3.18.1 (also occurs with valgrind compiled from the latest git sources, commit 3950c5d661ee09526cddcf24daf5fc22bc83f70c) ADDITIONAL INFORMATION Your software version fields could do with an update -- most recent listed is 3.15 but valgrind is at 3.18.1 released, and 3.19.0 in git. Might be related to https://github.com/paulfloyd/freebsd_valgrind/issues/137 -- You are receiving this mail because: You are watching all bug changes.
[frameworks-solid] [Bug 415474] Crash while closing the "Energy Information" window
https://bugs.kde.org/show_bug.cgi?id=415474 --- Comment #5 from Briggs --- Kubuntu 20.04 Sorry if this is redundant Application: System Settings Module (kcmshell5), signal: Segmentation fault Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [Current thread is 1 (Thread 0x7f5fc9d6f800 (LWP 1552))] Thread 4 (Thread 0x7f5fbb338700 (LWP 1556)): #0 futex_wait_cancelable (private=, expected=0, futex_word=0x5572207e8aac) at ../sysdeps/unix/sysv/linux/futex-internal.h:80 #1 __pthread_cond_wait_common (abstime=0x0, clockid=0, mutex=0x5572207e8a58, cond=0x5572207e8a80) at pthread_cond_wait.c:508 #2 __pthread_cond_wait (cond=0x5572207e8a80, mutex=0x5572207e8a58) at pthread_cond_wait.c:638 #3 0x7f5fbb81ea6b in ?? () from /usr/lib/x86_64-linux-gnu/dri/i965_dri.so #4 0x7f5fbb81e67b in ?? () from /usr/lib/x86_64-linux-gnu/dri/i965_dri.so #5 0x7f5fccfad669 in start_thread (arg=) at pthread_create.c:479 #6 0x7f5fcf695333 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Thread 3 (Thread 0x7f5fc3d4b700 (LWP 1554)): #0 0x7f5fcf688c3f in __GI___poll (fds=0x7f5fbc011e60, nfds=1, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29 #1 0x7f5fcc46b0ce in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #2 0x7f5fcc46b203 in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #3 0x7f5fce128943 in QEventDispatcherGlib::processEvents(QFlags) () from /lib/x86_64-linux-gnu/libQt5Core.so.5 #4 0x7f5fce0cf8bb in QEventLoop::exec(QFlags) () from /lib/x86_64-linux-gnu/libQt5Core.so.5 #5 0x7f5fcdf087f5 in QThread::exec() () from /lib/x86_64-linux-gnu/libQt5Core.so.5 #6 0x7f5fcf0d3efa in ?? () from /lib/x86_64-linux-gnu/libQt5DBus.so.5 #7 0x7f5fcdf09a42 in ?? () from /lib/x86_64-linux-gnu/libQt5Core.so.5 #8 0x7f5fccfad669 in start_thread (arg=) at pthread_create.c:479 #9 0x7f5fcf695333 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Thread 2 (Thread 0x7f5fc8ebd700 (LWP 1553)): #0 0x7f5fcf688c3f in __GI___poll (fds=0x7f5fc8ebcca8, nfds=1, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29 #1 0x7f5fccc8dc1a in ?? () from /lib/x86_64-linux-gnu/libxcb.so.1 #2 0x7f5fccc8f87a in xcb_wait_for_event () from /lib/x86_64-linux-gnu/libxcb.so.1 #3 0x7f5fc96c61c8 in ?? () from /lib/x86_64-linux-gnu/libQt5XcbQpa.so.5 #4 0x7f5fcdf09a42 in ?? () from /lib/x86_64-linux-gnu/libQt5Core.so.5 #5 0x7f5fccfad669 in start_thread (arg=) at pthread_create.c:479 #6 0x7f5fcf695333 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Thread 1 (Thread 0x7f5fc9d6f800 (LWP 1552)): [KCrash Handler] #6 0x7f5fc3f54414 in ?? () from /lib/x86_64-linux-gnu/libKF5Solid.so.5 #7 0x7f5fc3f49bdd in ?? () from /lib/x86_64-linux-gnu/libKF5Solid.so.5 #8 0x7f5fc3f49d4d in ?? () from /lib/x86_64-linux-gnu/libKF5Solid.so.5 #9 0x7f5fc3f4b357 in ?? () from /lib/x86_64-linux-gnu/libKF5Solid.so.5 #10 0x7f5fc3f4cfcd in ?? () from /lib/x86_64-linux-gnu/libKF5Solid.so.5 #11 0x7f5fcdf0ee81 in QThreadStorageData::finish(void**) () from /lib/x86_64-linux-gnu/libQt5Core.so.5 #12 0x7f5fce0d30d1 in QCoreApplicationPrivate::cleanupThreadData() () from /lib/x86_64-linux-gnu/libQt5Core.so.5 #13 0x7f5fce4ac974 in QGuiApplicationPrivate::~QGuiApplicationPrivate() () from /lib/x86_64-linux-gnu/libQt5Gui.so.5 #14 0x7f5fceae434d in QApplicationPrivate::~QApplicationPrivate() () from /lib/x86_64-linux-gnu/libQt5Widgets.so.5 #15 0x7f5fce104a27 in QObject::~QObject() () from /lib/x86_64-linux-gnu/libQt5Core.so.5 #16 0x7f5fce0d2e8e in QCoreApplication::~QCoreApplication() () from /lib/x86_64-linux-gnu/libQt5Core.so.5 #17 0x7f5fceae649e in QApplication::~QApplication() () from /lib/x86_64-linux-gnu/libQt5Widgets.so.5 #18 0x7f5fcf76e7c5 in kdemain () from /lib/x86_64-linux-gnu/libkdeinit5_kcmshell5.so #19 0x7f5fcf59a1e3 in __libc_start_main (main=0x55721f17a060, argc=2, argv=0x7ffe4d6d0738, init=, fini=, rtld_fini=, stack_end=0x7ffe4d6d0728) at ../csu/libc-start.c:308 #20 0x55721f17a09e in _start () [Inferior 1 (process 1552) detached] -- You are receiving this mail because: You are watching all bug changes.
[frameworks-solid] [Bug 415474] Crash while closing the "Energy Information" window
https://bugs.kde.org/show_bug.cgi?id=415474 Briggs changed: What|Removed |Added CC||jba1...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 406654] Pointless "Make sure that AppStream is properly set up on your system" message
https://bugs.kde.org/show_bug.cgi?id=406654 --- Comment #13 from Briggs --- (In reply to Aleix Pol from comment #12) > @Briggs, can you confirm it's properly set up? i.e. can you run > "appstreamcli refresh" on your system and tell us if it succeeds and removes > the error? I'm very sorry. I no longer have it installed. -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 413872] RPMs that are downloaded manually from untrusted sources can't be installed due to "bad PGP signature"
https://bugs.kde.org/show_bug.cgi?id=413872 Briggs changed: What|Removed |Added CC||jba1...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 377645] rfe: support for installing packages with no or unknown keys
https://bugs.kde.org/show_bug.cgi?id=377645 Briggs changed: What|Removed |Added CC||jba1...@gmail.com --- Comment #5 from Briggs --- I get this issue on a fresh install of Fedora 31 KDE -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 406654] Pointless "Make sure that AppStream is properly set up on your system" message
https://bugs.kde.org/show_bug.cgi?id=406654 Briggs changed: What|Removed |Added CC||jba1...@gmail.com --- Comment #11 from Briggs --- (In reply to Briggs from comment #10) > Created attachment 124687 [details] > Discover "Appstream" error I get this on a fresh install of Fedora31 KDE -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 406654] Pointless "Make sure that AppStream is properly set up on your system" message
https://bugs.kde.org/show_bug.cgi?id=406654 --- Comment #10 from Briggs --- Created attachment 124687 --> https://bugs.kde.org/attachment.cgi?id=124687=edit Discover "Appstream" error -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 404190] Bad Visibility of checkboxes in brush settings menu
https://bugs.kde.org/show_bug.cgi?id=404190 --- Comment #2 from Derek Briggs --- (In reply to Nate Graham from comment #1) > What theme are you using? The default theme. It is visible in the screenshot I attached. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 404190] Bad Visibility of checkboxes in brush settings menu
https://bugs.kde.org/show_bug.cgi?id=404190 Derek Briggs changed: What|Removed |Added CC||channelnumbe...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 404190] New: Bad Visibility of checkboxes in brush settings menu
https://bugs.kde.org/show_bug.cgi?id=404190 Bug ID: 404190 Summary: Bad Visibility of checkboxes in brush settings menu Product: krita Version: 4.1.7 Platform: Archlinux Packages OS: Linux Status: REPORTED Severity: minor Priority: NOR Component: Usability Assignee: krita-bugs-n...@kde.org Reporter: channelnumbe...@gmail.com Target Milestone: --- Created attachment 117976 --> https://bugs.kde.org/attachment.cgi?id=117976=edit Screenshot of menu with low visibility checkboxes Using the brush settings menu, I find the checkboxes very difficult to see. I was trying to add a texture to my brush, and couldn't figure out that I had to click the checkbox, because I couldn't see the checkbox. I've included a screenshot of the checkboxes I am talking about. In my opinion, these should be larger, and or the background color of the checkbox, should be a color, that contrasts the rest of the menu more than it currently does. STEPS TO REPRODUCE 1. Open the brush settings dialog menu SOFTWARE/OS VERSIONS I've observed this issue in versions 4.0.4 and 4.1.7, running on Windows 7, and Arch Linux, respectively. -- You are receiving this mail because: You are watching all bug changes.
[yakuake] [Bug 396834] New: Folding animation glitchy - 90% shows visual corruption, 100% shows missing tabs
https://bugs.kde.org/show_bug.cgi?id=396834 Bug ID: 396834 Summary: Folding animation glitchy - 90% shows visual corruption, 100% shows missing tabs Product: yakuake Version: 3.0.5 Platform: Ubuntu Packages OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: general Assignee: h...@kde.org Reporter: s...@jacobbriggs.com Target Milestone: --- Created attachment 114105 --> https://bugs.kde.org/attachment.cgi?id=114105=edit Fullscreen - missing tab menus I've tried with different themes and with/without windows manager to perform the animation. When using yakuake with a gnome panel there are visual glitches. At 100% I lose the tab selection as if its not filling the screen. At 90% there is corruption/overlay issues. This is only after the retraction animation, if i resize or perform any menu action the window re-renders correctly. -- You are receiving this mail because: You are watching all bug changes.
[yakuake] [Bug 396834] Folding animation glitchy - 90% shows visual corruption, 100% shows missing tabs
https://bugs.kde.org/show_bug.cgi?id=396834 --- Comment #1 from Jacob Briggs --- Created attachment 114106 --> https://bugs.kde.org/attachment.cgi?id=114106=edit 90%, visual glitch -- You are receiving this mail because: You are watching all bug changes.
