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.
https://bugs.kde.org/show_bug.cgi?id=459392
Nick Briggs changed:
What|Removed |Added
CC||afraid-splicer...@icloud.co
https://bugs.kde.org/show_bug.cgi?id=445743
Nick Briggs changed:
What|Removed |Added
CC||afraid-splicer...@icloud.co
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
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
38
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,
"
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
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_
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&action=edit
C source test case
This test case provokes the problem.
cc -O2 -pipe vgtest2.c -o vgtest2
Running under v
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.
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
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] ...
SYSC
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
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 t
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.
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
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 a
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
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
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
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'
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_restar
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=0x10
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
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
25 matches
Mail list logo
