search for: si_addr

...gs up if we could > avoid the problem altogether (hence this email). > > It's also worth noting that the WnR bit needs special treatment for things > like atomic instructions and cache maintenance instructions which currently > appears to be missing. Would it be to bad to look at si_addr to spot kernel > addresses and handle them specially? We use this for preliminary classification of bugs, on the assumption that bad writes are scarier than bad reads. We don't care about si_addr permissions, what matters is the type of access requested by the faulting instruction, i.e. PC...

...just wary of faking things up if we could avoid the problem altogether (hence this email). It's also worth noting that the WnR bit needs special treatment for things like atomic instructions and cache maintenance instructions which currently appears to be missing. Would it be to bad to look at si_addr to spot kernel addresses and handle them specially? > Also, your patch looks like it would disable ESR context for all > faults on tagged addresses, too. Since Linux unconditionally enables > TBI, it should be safe to zero out the MSB before the address check. The tag is currently remove...

...ory sanitizer of LLVM 3.3. It's crashing during MSan initialization (__msan::InitShadow). Here's the strace output. mmap(0x400000000000, 35184372088831, PROT_NONE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x400000000000 --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_ACCERR, si_addr=0x55edf4b36720} --- +++ killed by SIGSEGV (core dumped) +++ Because of the -fsanitize=memory option, clang maps all segments in the 0x5555555????? range which is zero'ed out by this mmap. According to the Memory Sanitizer paper, the application is expected between 0x600000000000 and 0x7fffffff...

On Wed, Mar 7, 2018 at 7:48 AM, Dmitry Vyukov <dvyukov at google.com> wrote: > On Wed, Mar 7, 2018 at 4:39 PM, Andrey Ryabinin <aryabinin at virtuozzo.com> wrote: >> On 03/06/2018 08:58 PM, Will Deacon wrote: >>> Hi all, >>> >>> As part of some recent work to harden the Kernel Address Space Layout >>> Randomisation (KASLR) implementation in

...NLY|O_CLOEXEC) = 11 open("/usr/lib64/samba/ldb/update_keytab.so", O_RDONLY|O_CLOEXEC) = 11 open("/usr/lib64/samba/ldb/vlv.so", O_RDONLY|O_CLOEXEC) = 11 open("/usr/lib64/samba/ldb/wins_ldb.so", O_RDONLY|O_CLOEXEC) = 11 --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x8} --- +++ killed by SIGSEGV +++ # tail -16 /tmp/out10 open("/usr/lib64/samba/ldb/wins_ldb.so", O_RDONLY|O_CLOEXEC) = 11 read(11, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\20\r\0\0\0\0\0\0"..., 832) = 832 fstat(11, {st_mode=S_IFREG|0755, st_size=10912, ...}) = 0 mmap...

...> open("/usr/lib64/samba/ldb/update_keytab.so", O_RDONLY|O_CLOEXEC) = 11 > open("/usr/lib64/samba/ldb/vlv.so", O_RDONLY|O_CLOEXEC) = 11 > open("/usr/lib64/samba/ldb/wins_ldb.so", O_RDONLY|O_CLOEXEC) = 11 > --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x8} --- > +++ killed by SIGSEGV +++ > > # tail -16 /tmp/out10 > open("/usr/lib64/samba/ldb/wins_ldb.so", O_RDONLY|O_CLOEXEC) = 11 > read(11, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\20\r\0\0\0\0\0\0"..., 832) = 832 > fstat(11, {st_mode=S_IFREG|0755,...

...----------------------------------------------------------------------- The error log is : Current thread (0x00007f9e90006800): JavaThread "main" [_thread_in_native, id=5892, stack(0x00007f9e95472000,0x00007f9e95573000)] siginfo:si_signo=SIGSEGV: si_errno=0, si_code=1 (SEGV_MAPERR), si_addr=0x0000000000000018 Registers: RAX=0x0000000000000001, RBX=0x0000000000000030, RCX=0x0000000000000000, RDX=0x00007f9e900b7588 RSP=0x00007f9e95571580, RBP=0x0000000000000028, RSI=0x0000000000000000, RDI=0x0000000000000004 R8 =0x00007f9e69af9990, R9 =0x000000000000004f, R10=0x00007f9e69af9850, R...

On Mon, 2017-02-13 at 10:00 +1100, Tom Robinson via samba wrote: > On 12/02/17 03:13, Rowland Penny via samba wrote: > > On Fri, 10 Feb 2017 12:34:23 +1100 > > Tom Robinson via samba <samba at lists.samba.org> wrote: > > > > > I've grabbed samba 4.5.4 and customised an existing rpm spec > > > file. > > > Still some issues there. > >

...= 0 setresuid(0, 0, -1) = 0 geteuid() = 0 getegid() = 0 geteuid() = 0 write(1, "pop_sec_ctx (0, 0) - sec_ctx_sta"..., 43) = 43 --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0} --- write(1, "================================"..., 64) = 64 write(1, "INTERNAL ERROR: Signal 11 in pid"..., 46) = 46 write(1, "Please read the Trouble-Shooting"..., 60) = 60 write(1, "================================"..., 64) = 64 write(1, "PANIC (pi...

...ucode = <value optimized out> code = 0 type = 1 addr = <value optimized out> ksi = {ksi_link = {tqe_next = 0xffffff80e7d408dc, tqe_prev = 0x60}, ksi_info = {si_signo = 96, si_errno = 0, si_code = 0, si_pid = 0, si_uid = 41125008, si_status = -512, si_addr = 0xfffffe00027388f0, si_value = {sival_int = 3, sival_ptr = 0x3, sigval_int = 3, sigval_ptr = 0x3}, _reason = {_fault = {_trapno = 40}, _timer = {_timerid = 40, _overrun = 0}, _mesgq = {_mqd = 40}, _poll = {_band = 40}, __spare__ = {__spare1__ = 40, __spare2__ = {-405535488, -128, -213781066...

...t; ucode = <value optimized out> code = 0 type = 12 addr = <value optimized out> ksi = {ksi_link = {tqe_next = 0xfffffe000553ac00, tqe_prev = 0xfffffe000b0af000}, ksi_info = {si_signo = -1833355440, si_errno = -128, si_code = -2140661293, si_pid = -1, si_uid = 0, si_status = 0, si_addr = 0xfffffe0000000000, si_value = {sival_int = -1833355392, sival_ptr = 0xffffff8092b93780, sigval_int = -1833355392, sigval_ptr = 0xffffff8092b93780}, _reason = {_fault = {_trapno = -2138032854}, _timer = {_timerid = -2138032854, _overrun = -1}, _mesgq = {_mqd = -2138032854}, _poll = {_...

...= 0 munmap(0x7f46579c7000, 4096) = 0 socket(PF_NETLINK, SOCK_RAW, 12) = -1 EPROTONOSUPPORT (Protocol not supported) write(2, "Memory allocation failure\n", 26Memory allocation failure ) = 26 --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0} --- +++ killed by SIGSEGV (core dumped) +++ Segmentation fault (core dumped) Is there anything I've missed? Should I upgrade kernel or some library? Thanks, Vaclav -- Configure bugmail: https://bugzilla.netfilter.org/userprefs.cgi?tab=email ------- You are receiving this mail because: -...

On 7.3.2019 23.37, A. Schulze via dovecot wrote: > > Am 07.03.19 um 17:33 schrieb Aki Tuomi via dovecot: > >>> test-http-client-errors.c:2989: Assert failed: FALSE >>> connection timed out ................................................. : FAILED > Hello Aki, > >> Are you running with valgrind or on really slow system? > I'm not aware my buildsystem

...= 0 > geteuid() = 0 > getegid() = 0 > geteuid() = 0 > write(1, "pop_sec_ctx (0, 0) - sec_ctx_sta"..., 43) = 43 > --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0} --- > write(1, "================================"..., 64) = 64 > write(1, "INTERNAL ERROR: Signal 11 in pid"..., 46) = 46 > write(1, "Please read the Trouble-Shooting"..., 60) = 60 > write(1, "================================"..., 64) = 64 >...

Migration from 3.6.25-0ubuntu0.12.04.10 to 4.x with passdb backend = ldapsam Hi. I tried to migrate my storage(smb) server to more newer version, but faced with 'segfaults", after(in progress) client authenticating, when samba tries to start a new smbd instance (as i understand). I saw client authentication success, which interrupts in following places: In case with

..._sigaction(SIGALRM, {sa_handler=0x7f3eeef9899b, sa_mask=[], sa_flags=SA_RESTORER|SA_SIGINFO, sa_restorer=0x7f3eee4297c0}, NULL, 8) = 0 openat(AT_FDCWD, "/proc/sys/crypto/fips_enabled", O_RDONLY) = -1 ENOENT (No such file or directory) --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0xffffffffeee4f200} --- +++ killed by SIGSEGV +++ Segmentation fault thunderstorm /usr/libexec/dovecot # gdb: thunderstorm /var/core # gdb auth core.auth.18428 GNU gdb (Gentoo 8.1.1 p1) 8.1.1 Copyright (C) 2018 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http:/...

...; }' | clang -c -xc - -o /tmp/x2.o $ clang -o /tmp/x /tmp/x1.o /tmp/x2.o And, hey, let's run it and see it crash... $ gdb /tmp/x ... (gdb) run Starting program: /tmp/x Program received signal SIGSEGV, Segmentation fault. 0x0000000000400486 in main () (gdb) p $_siginfo._sifields._sigfault.si_addr $1 = (void *) 0x600 (gdb) x/i $pc => 0x400486 <main+6>: movl $0x5,0x600 Yep, crashed writing to 0x600, the invalid address we expected. On Fri, May 3, 2019 at 5:06 PM Snider, Todd <t-snider at ti.com<mailto:t-snider at ti.com>> wrote: Hi James, Can you explain further the...

...dler=0x7f3eeef9899b, sa_mask=[], > sa_flags=SA_RESTORER|SA_SIGINFO, sa_restorer=0x7f3eee4297c0}, NULL, 8) > = 0 > openat(AT_FDCWD, "/proc/sys/crypto/fips_enabled", O_RDONLY) = -1 > ENOENT (No such file or directory) > --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, > si_addr=0xffffffffeee4f200} --- > +++ killed by SIGSEGV +++ > Segmentation fault > thunderstorm /usr/libexec/dovecot # > > > gdb: > > thunderstorm /var/core # gdb auth core.auth.18428 > GNU gdb (Gentoo 8.1.1 p1) 8.1.1 > Copyright (C) 2018 Free Software Foundation, Inc. > Li...

...$ gdb /tmp/x >> >> ... >> >> (gdb) run >> >> Starting program: /tmp/x >> >> >> >> Program received signal SIGSEGV, Segmentation fault. >> >> 0x0000000000400486 in main () >> >> (gdb) p $_siginfo._sifields._sigfault.si_addr >> >> $1 = (void *) 0x600 >> >> (gdb) x/i $pc >> => 0x400486 <main+6>: movl $0x5,0x600 >> >> Yep, crashed writing to 0x600, the invalid address we expected. >> >> >> >> On Fri, May 3, 2019 at 5:06 PM Snider, Todd <t-s...

...mask=[], >> sa_flags=SA_RESTORER|SA_SIGINFO, sa_restorer=0x7f3eee4297c0}, NULL, 8) >> = 0 >> openat(AT_FDCWD, "/proc/sys/crypto/fips_enabled", O_RDONLY) = -1 >> ENOENT (No such file or directory) >> --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, >> si_addr=0xffffffffeee4f200} --- >> +++ killed by SIGSEGV +++ >> Segmentation fault >> thunderstorm /usr/libexec/dovecot # >> >> >> gdb: >> >> thunderstorm /var/core # gdb auth core.auth.18428 >> GNU gdb (Gentoo 8.1.1 p1) 8.1.1 >> Copyright (C) 201...