From owner-freebsd-hackers@freebsd.org Sun Jul 2 02:42:20 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DFA0AD9A4AD for ; Sun, 2 Jul 2017 02:42:20 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-15.reflexion.net [208.70.210.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A56C27BC18 for ; Sun, 2 Jul 2017 02:42:20 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 10371 invoked from network); 2 Jul 2017 02:42:13 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 2 Jul 2017 02:42:13 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.1) with SMTP; Sat, 01 Jul 2017 22:42:13 -0400 (EDT) Received: (qmail 27971 invoked from network); 2 Jul 2017 02:42:13 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 2 Jul 2017 02:42:13 -0000 Received: from [192.168.1.114] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 8EF97EC893D; Sat, 1 Jul 2017 19:42:12 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: head -r320521 (e.g.): another powerpc64 problem: programs using fgets crash trying to store address over code instead of into __cleanup_info__ Message-Id: Date: Sat, 1 Jul 2017 19:42:11 -0700 To: Konstantin Belousov , FreeBSD PowerPC ML , FreeBSD Current , freebsd-hackers@freebsd.org X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jul 2017 02:42:21 -0000 [Note: this is from a amd64 -> powerpc64 cross-build based on system clang 4 instead of gcc 4.2.1. I'm building a gcc 4.2.1 based system currently so that I can test a more standard configuration. But I'm one of the ones that experiments with finding things to report for clang targeting powerpc64 and powerpc.] powerpc64 is having programs crash with an attempt to store addresses over code instead of into __cleanup_info__ when fgets is used. ntpd is an example. As is sshd (although I've looked at its details less). Building up the context for this claim. . . public declaration: struct _pthread_cleanup_info { __uintptr_t pthread_cleanup_pad[8]; }; private declaration: struct pthread_cleanup { struct pthread_cleanup *prev; void (*routine)(void *); void *routine_arg; int onheap; }; ntpd and sshd die with segmentation faults in: void __pthread_cleanup_push_imp(void (*routine)(void *), void *arg, struct _pthread_cleanup_info *info) { struct pthread *curthread =3D _get_curthread(); struct pthread_cleanup *newbuf; newbuf =3D (void *)info; newbuf->routine =3D routine; newbuf->routine_arg =3D arg; newbuf->onheap =3D 0; newbuf->prev =3D curthread->cleanup; curthread->cleanup =3D newbuf; } at the statement: newbuf->routine =3D routine; But it turns out that the bt is like: __pthread_cleanup_push_imp(routine=3D0x507b1248 = <__stdio_cancel_cleanup>, arg=3D0x0, info=3D0x509eaaf4) __pthread_cleanup_push_imp_int(p0=3D0x507b1248,p1=3D0x0) fgets (buf=3D0x51415000 "", n=3D511, fp=3D0x507d4c40) . . . Note the 2 arguments to __pthread_cleanup_push_imp_int when called from fgets but the 3 arguemnts to __pthread_cleanup_push_imp . . . fgets uses FLOCK_CANCELSAFE(fp) : #define FLOCKFILE_CANCELSAFE(fp) = \ { = \ struct _pthread_cleanup_info __cleanup_info__; = \ if (__isthreaded) { = \ _FLOCKFILE(fp); = \ ___pthread_cleanup_push_imp( = \ __stdio_cancel_cleanup, (fp), = \ &__cleanup_info__); = \ } else { = \ ___pthread_cleanup_push_imp( = \ __stdio_cancel_cleanup, NULL, = \ &__cleanup_info__); = \ } = \ { #define FUNLOCKFILE_CANCELSAFE() = \ (void)0; = \ } = \ ___pthread_cleanup_pop_imp(1); = \ } where here the NULL case is in use. 3 arguments. But: STUB_FUNC2(__pthread_cleanup_push_imp, PJT_CLEANUP_PUSH_IMP, void, = void*, void *); which is use of: #define STUB_FUNC2(name, idx, ret, p0_type, p1_type) \ static ret FUNC_EXP(name)(p0_type, p1_type) __used; \ static ret FUNC_INT(name)(p0_type, p1_type) __used; \ WEAK_REF(FUNC_EXP(name), name); \ WEAK_REF(FUNC_INT(name), __CONCAT(_, name)); \ typedef ret (*FUNC_TYPE(name))(p0_type, p1_type); \ static ret FUNC_EXP(name)(p0_type p0, p1_type p1) \ { \ FUNC_TYPE(name) func; \ func =3D (FUNC_TYPE(name))__thr_jtable[idx][0]; \ return (func(p0, p1)); \ } \ static ret FUNC_INT(name)(p0_type p0, p1_type p1) \ { \ FUNC_TYPE(name) func; \ func =3D (FUNC_TYPE(name))__thr_jtable[idx][1]; \ return (func(p0, p1)); \ } so only 2 arguments to func (i.e., __pthread_cleanup_push_imp here). Compared to: ___pthread_cleanup_push_imp( = \ __stdio_cancel_cleanup, NULL, = \ &__cleanup_info__); = \ As a result junk is used instead of &__cleanup_info__. On powerpc64 it happens to be the address of ___pthread_cleanup_push_imp that happens to be in r5 (normally the third argument) at the time. So: newbuf->routine =3D routine; tries to replace the first instruction of ___pthread_cleanup_push_imp . As far as I can tell what should be used is: =20 #define STUB_FUNC3(name, idx, ret, p0_type, p1_type, p2_type) \ static ret FUNC_EXP(name)(p0_type, p1_type, p2_type) __used; \ static ret FUNC_INT(name)(p0_type, p1_type, p2_type) __used; \ WEAK_REF(FUNC_EXP(name), name); \ WEAK_REF(FUNC_INT(name), __CONCAT(_, name)); \ typedef ret (*FUNC_TYPE(name))(p0_type, p1_type, p2_type); \ static ret FUNC_EXP(name)(p0_type p0, p1_type p1, p2_type p2) \ { \ FUNC_TYPE(name) func; \ func =3D (FUNC_TYPE(name))__thr_jtable[idx][0]; \ return (func(p0, p1, p2)); \ } \ static ret FUNC_INT(name)(p0_type p0, p1_type p1, p2_type p2) \ { \ FUNC_TYPE(name) func; \ func =3D (FUNC_TYPE(name))__thr_jtable[idx][1]; \ return (func(p0, p1, p2)); \ } with the p2_type being: struct _pthread_cleanup_info * but I'm not expert in this code. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-hackers@freebsd.org Sun Jul 2 03:33:52 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 95C73D9B88B for ; Sun, 2 Jul 2017 03:33:52 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-15.reflexion.net [208.70.210.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 518007D899 for ; Sun, 2 Jul 2017 03:33:51 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 28434 invoked from network); 2 Jul 2017 03:33:50 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 2 Jul 2017 03:33:50 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.1) with SMTP; Sat, 01 Jul 2017 23:33:50 -0400 (EDT) Received: (qmail 2110 invoked from network); 2 Jul 2017 03:33:50 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 2 Jul 2017 03:33:50 -0000 Received: from [192.168.1.114] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id A4495EC9366; Sat, 1 Jul 2017 20:33:49 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: head -r320521 (e.g.): another powerpc64 problem: programs using fgets crash trying to store address over code instead of into __cleanup_info__ Date: Sat, 1 Jul 2017 20:33:49 -0700 References: To: FreeBSD PowerPC ML , FreeBSD Current , freebsd-hackers@freebsd.org In-Reply-To: Message-Id: <87FABF66-3023-47E4-8F8F-6E76B7B84046@dsl-only.net> X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jul 2017 03:33:52 -0000 [I've now got a route to get information from the old PowerMac so-called "Quad Core" despite sshd being broken. So I add gdb output material as evidence to go with the more source code level analysis from before.] On 2017-Jul-1, at 7:42 PM, Mark Millard wrote: > [Note: this is from a amd64 -> powerpc64 cross-build based > on system clang 4 instead of gcc 4.2.1. I'm building a > gcc 4.2.1 based system currently so that I can test > a more standard configuration. But I'm one of the ones > that experiments with finding things to report for > clang targeting powerpc64 and powerpc.] >=20 > powerpc64 is having programs crash with an attempt > to store addresses over code instead of into > __cleanup_info__ when fgets is used. ntpd is an > example. As is sshd (although I've looked at > its details less). >=20 > Building up the context for this claim. . . >=20 > public declaration: >=20 > struct _pthread_cleanup_info { > __uintptr_t pthread_cleanup_pad[8]; > }; >=20 > private declaration: >=20 > struct pthread_cleanup { > struct pthread_cleanup *prev; > void (*routine)(void *); > void *routine_arg; > int onheap; > }; >=20 > ntpd and sshd die with segmentation faults in: >=20 > void > __pthread_cleanup_push_imp(void (*routine)(void *), void *arg, > struct _pthread_cleanup_info *info) > { > struct pthread *curthread =3D _get_curthread(); > struct pthread_cleanup *newbuf; >=20 > newbuf =3D (void *)info; > newbuf->routine =3D routine; > newbuf->routine_arg =3D arg; > newbuf->onheap =3D 0; > newbuf->prev =3D curthread->cleanup; > curthread->cleanup =3D newbuf; > } >=20 > at the statement: newbuf->routine =3D routine; >=20 > But it turns out that the bt is like: >=20 > __pthread_cleanup_push_imp(routine=3D0x507b1248 = <__stdio_cancel_cleanup>, arg=3D0x0, info=3D0x509eaaf4) > __pthread_cleanup_push_imp_int(p0=3D0x507b1248,p1=3D0x0) > fgets (buf=3D0x51415000 "", n=3D511, fp=3D0x507d4c40) > . . . >=20 > Note the 2 arguments to __pthread_cleanup_push_imp_int when called > from fgets but the 3 arguemnts to __pthread_cleanup_push_imp . . . >=20 > fgets uses FLOCK_CANCELSAFE(fp) : >=20 > #define FLOCKFILE_CANCELSAFE(fp) = \ > { = \ > struct _pthread_cleanup_info __cleanup_info__; = \ > if (__isthreaded) { = \ > _FLOCKFILE(fp); = \ > ___pthread_cleanup_push_imp( = \ > __stdio_cancel_cleanup, (fp), = \ > &__cleanup_info__); = \ > } else { = \ > ___pthread_cleanup_push_imp( = \ > __stdio_cancel_cleanup, NULL, = \ > &__cleanup_info__); = \ > } = \ > { > #define FUNLOCKFILE_CANCELSAFE() = \ > (void)0; = \ > } = \ > ___pthread_cleanup_pop_imp(1); = \ > } >=20 > where here the NULL case is in use. 3 arguments. >=20 > But: >=20 > STUB_FUNC2(__pthread_cleanup_push_imp, PJT_CLEANUP_PUSH_IMP, void, = void*, void *); >=20 > which is use of: >=20 > #define STUB_FUNC2(name, idx, ret, p0_type, p1_type) \ > static ret FUNC_EXP(name)(p0_type, p1_type) __used; \ > static ret FUNC_INT(name)(p0_type, p1_type) __used; \ > WEAK_REF(FUNC_EXP(name), name); \ > WEAK_REF(FUNC_INT(name), __CONCAT(_, name)); \ > typedef ret (*FUNC_TYPE(name))(p0_type, p1_type); \ > static ret FUNC_EXP(name)(p0_type p0, p1_type p1) \ > { \ > FUNC_TYPE(name) func; \ > func =3D (FUNC_TYPE(name))__thr_jtable[idx][0]; \ > return (func(p0, p1)); \ > } \ > static ret FUNC_INT(name)(p0_type p0, p1_type p1) \ > { \ > FUNC_TYPE(name) func; \ > func =3D (FUNC_TYPE(name))__thr_jtable[idx][1]; \ > return (func(p0, p1)); \ > } >=20 > so only 2 arguments to func (i.e., __pthread_cleanup_push_imp > here). >=20 > Compared to: >=20 > ___pthread_cleanup_push_imp( = \ > __stdio_cancel_cleanup, NULL, = \ > &__cleanup_info__); = \ >=20 > As a result junk is used instead of &__cleanup_info__. > On powerpc64 it happens to be the address of > ___pthread_cleanup_push_imp that happens to be > in r5 (normally the third argument) at the time. >=20 > So: >=20 > newbuf->routine =3D routine; >=20 > tries to replace the first instruction of > ___pthread_cleanup_push_imp . >=20 > As far as I can tell what should be used is: >=20 > #define STUB_FUNC3(name, idx, ret, p0_type, p1_type, p2_type) \ > static ret FUNC_EXP(name)(p0_type, p1_type, p2_type) __used; \ > static ret FUNC_INT(name)(p0_type, p1_type, p2_type) __used; \ > WEAK_REF(FUNC_EXP(name), name); \ > WEAK_REF(FUNC_INT(name), __CONCAT(_, name)); \ > typedef ret (*FUNC_TYPE(name))(p0_type, p1_type, p2_type); \ > static ret FUNC_EXP(name)(p0_type p0, p1_type p1, p2_type p2) \ > { \ > FUNC_TYPE(name) func; \ > func =3D (FUNC_TYPE(name))__thr_jtable[idx][0]; \ > return (func(p0, p1, p2)); \ > } \ > static ret FUNC_INT(name)(p0_type p0, p1_type p1, p2_type p2) \ > { \ > FUNC_TYPE(name) func; \ > func =3D (FUNC_TYPE(name))__thr_jtable[idx][1]; \ > return (func(p0, p1, p2)); \ > } >=20 > with the p2_type being: struct _pthread_cleanup_info * >=20 > but I'm not expert in this code. The backtrace for ntpd : Loaded symbols for /libexec/ld-elf.so.1 #0 __pthread_cleanup_push_imp (routine=3D0x50649248 = <__stdio_cancel_cleanup>, arg=3D0x0, info=3D0x50403af4) at = /usr/src/lib/libthr/thread/thr_clean.c:57 57 newbuf->routine =3D routine; (gdb) bt #0 __pthread_cleanup_push_imp (routine=3D0x50649248 = <__stdio_cancel_cleanup>, arg=3D0x0, info=3D0x50403af4) at = /usr/src/lib/libthr/thread/thr_clean.c:57 #1 0x0000000050603cbc in __pthread_cleanup_push_imp_int (p0=3D0x50649248,= p1=3D0x0) at /usr/src/lib/libc/gen/_pthread_stubs.c:283 #2 0x00000000505850a0 in vfprintf_l (fp=3D0x5066cc40, locale=3D, fmt0=3D0x50618523 "<%d>", ap=3D0xffffffffffffc150 "") at = printfcommon.h:75 #3 0x000000005058b034 in fprintf (fp=3D0x50649248, fmt=3D0x50403af4 = "`") at /usr/src/lib/libc/stdio/fprintf.c:55 #4 0x00000000505d22e0 in vsyslog (pri=3D, = fmt=3D0x50618523 "<%d>", ap=3D0xffffffffffffc150 "") at = /usr/src/lib/libc/gen/syslog.c:171 #5 0x00000000505d2138 in syslog (pri=3D1348768328, fmt=3D0x0) at = /usr/src/lib/libc/gen/syslog.c:128 #6 0x0000000010095eb8 in 00000016.plt_call.OBJ_sn2nid () #7 0x00000000100965e0 in 00000016.plt_call.OBJ_sn2nid () #8 0x000000001004624c in ntpdmain (argc=3D0, argv=3D) at /usr/src/contrib/ntp/ntpd/ntpd.c:602 #9 0x0000000010046020 in main (argc=3D1348768328, argv=3D0x0) at = /usr/src/contrib/ntp/ntpd/ntpd.c:394 #10 0x0000000010008b5c in 00000016.plt_call.OBJ_sn2nid () #11 0x00000000500e2b70 in .text () at = /usr/src/libexec/rtld-elf/powerpc64/rtld_start.S:104 Note the expected use of r5 in the below. 0x50403af4 <__pthread_cleanup_push_imp>: nop 0x50403af8 <__pthread_cleanup_push_imp+4>: ld r6,18288(r2) 0x50403afc <__pthread_cleanup_push_imp+8>: cmpldi r6,0 0x50403b00 <__pthread_cleanup_push_imp+12>: beq- 0x50403b10 = <__pthread_cleanup_push_imp+28> 0x50403b04 <__pthread_cleanup_push_imp+16>: mr r6,r13 0x50403b08 <__pthread_cleanup_push_imp+20>: ld r6,-28680(r6) 0x50403b0c <__pthread_cleanup_push_imp+24>: b 0x50403b14 = <__pthread_cleanup_push_imp+32> 0x50403b10 <__pthread_cleanup_push_imp+28>: li r6,0 0x50403b14 <__pthread_cleanup_push_imp+32>: std r3,8(r5) 0x50403b18 <__pthread_cleanup_push_imp+36>: li r3,0 0x50403b1c <__pthread_cleanup_push_imp+40>: std r4,16(r5) 0x50403b20 <__pthread_cleanup_push_imp+44>: stw r3,24(r5) 0x50403b24 <__pthread_cleanup_push_imp+48>: ld r3,552(r6) 0x50403b28 <__pthread_cleanup_push_imp+52>: std r3,0(r5) 0x50403b2c <__pthread_cleanup_push_imp+56>: std r5,552(r6) 0x50403b30 <__pthread_cleanup_push_imp+60>: blr 0x50403b34 <__pthread_cleanup_push_imp+64>: .long 0x0 0x50403b38 <__pthread_cleanup_push_imp+68>: .long 0x0 0x50403b3c <__pthread_cleanup_push_imp+72>: .long 0x0 But note the use of r5 in the below: r5=3D=3D0x50403af4 results, replacing any potential r5 from the call to __pthread_cleanup_push_imp_int . Also r5's value is replaced without accessing or recording the value it the __pthread_cleanup_push_imp_int's start. r5 0x50403af4 1346386676 0x50603c80 <__pthread_cleanup_push_imp_int>: mflr r0 0x50603c84 <__pthread_cleanup_push_imp_int+4>: std r31,-8(r1) 0x50603c88 <__pthread_cleanup_push_imp_int+8>: std r0,16(r1) 0x50603c8c <__pthread_cleanup_push_imp_int+12>: stdu r1,-128(r1) 0x50603c90 <__pthread_cleanup_push_imp_int+16>: mr r31,r1 0x50603c94 <__pthread_cleanup_push_imp_int+20>: nop 0x50603c98 <__pthread_cleanup_push_imp_int+24>: std r2,40(r1) 0x50603c9c <__pthread_cleanup_push_imp_int+28>: ld r5,-22408(r2) 0x50603ca0 <__pthread_cleanup_push_imp_int+32>: ld r5,968(r5) 0x50603ca4 <__pthread_cleanup_push_imp_int+36>: ld r6,8(r5) 0x50603ca8 <__pthread_cleanup_push_imp_int+40>: ld r11,16(r5) 0x50603cac <__pthread_cleanup_push_imp_int+44>: ld r5,0(r5) 0x50603cb0 <__pthread_cleanup_push_imp_int+48>: mr r2,r6 0x50603cb4 <__pthread_cleanup_push_imp_int+52>: mtctr r5 0x50603cb8 <__pthread_cleanup_push_imp_int+56>: bctrl 0x50603cbc <__pthread_cleanup_push_imp_int+60>: ld r2,40(r1) 0x50603cc0 <__pthread_cleanup_push_imp_int+64>: addi r1,r1,128 0x50603cc4 <__pthread_cleanup_push_imp_int+68>: ld r0,16(r1) 0x50603cc8 <__pthread_cleanup_push_imp_int+72>: ld r31,-8(r1) 0x50603ccc <__pthread_cleanup_push_imp_int+76>: mtlr r0 0x50603cd0 <__pthread_cleanup_push_imp_int+80>: blr 0x50603cd4 <__pthread_cleanup_push_imp_int+84>: .long 0x0 0x50603cd8 <__pthread_cleanup_push_imp_int+88>: .long 0x0 0x50603cdc <__pthread_cleanup_push_imp_int+92>: .long 0x0 As the above code is set up for passing 2 arguments to __pthread_cleanup_push_imp (in r3 and r4) the above code uses r5 as a scratch register to hold the computed address of __pthread_cleanup_push_imp. This is not what __pthread_cleanup_push_imp is designed for in its use of r5. But in the below r5 was expected to be passed in to __pthread_cleanup_push_imp_int even though __pthread_cleanup_push_imp_int ignores the r5 value that is supplied. 0x505da750 : mflr r0 0x505da754 : std r31,-8(r1) 0x505da758 : std r0,16(r1) 0x505da75c : stdu r1,-256(r1) 0x505da760 : mr r31,r1 . . . 0x505da7b8 : bl 0x5048a9a0 = <00000017.plt_call._flockfile> 0x505da7bc : ld r2,40(r1) 0x505da7c0 : nop 0x505da7c4 : addi r5,r31,112 0x505da7c8 : mr r4,r29 0x505da7cc : b 0x505da7dc 0x505da7d0 : nop 0x505da7d4 : addi r5,r31,112 0x505da7d8 : li r4,0 0x505da7dc : ld r3,-23664(r2) 0x505da7e0 : bl 0x50603c80 = <__pthread_cleanup_push_imp_int> 0x505da7e4 : nop . . . Conclusion: __pthread_cleanup_push_imp_int should expect and handle 3 arguments and propagate all 3 to __pthread_cleanup_push_imp, not using r5 for the address of __pthread_cleanup_push_imp . I'll only give the backtrace for sshd. Also I've removed the garbage text shown for appname=3D in #8 and just used ". . .". Note that #0 through #2 are very similar to the above for ntpd: same problem for sshd. #0 __pthread_cleanup_push_imp (routine=3D0x507b1248 = <__stdio_cancel_cleanup>, arg=3D0x0, info=3D0x509eaaf4) at = /usr/src/lib/libthr/thread/thr_clean.c:57 #1 0x000000005076bcbc in __pthread_cleanup_push_imp_int (p0=3D0x507b1248,= p1=3D0x0) at /usr/src/lib/libc/gen/_pthread_stubs.c:283 #2 0x00000000507427e4 in fgets (buf=3D0x51415000 "", n=3D511, = fp=3D0x507d4c40) from /lib/libc.so.7 #3 0x00000000504e5268 in file_gets (bp=3D, = buf=3D0x507d4c40 "", size=3D0) at = /usr/src/crypto/openssl/crypto/bio/bss_file.c:461 #4 0x00000000504f0678 in BIO_gets (b=3D, = in=3D0x51415000 "", inl=3D) at = /usr/src/crypto/openssl/crypto/bio/bio_lib.c:303 #5 0x000000005047eaa8 in def_load_bio (conf=3D0x51415000, = in=3D0x5140e000, line=3D0x507d4c40) at = /usr/src/crypto/openssl/crypto/conf/conf_def.c:260 #6 0x000000005047f5b4 in def_load (conf=3D, = name=3D, line=3D0x51415000) at = /usr/src/crypto/openssl/crypto/conf/conf_def.c:207 #7 0x000000005047e518 in NCONF_load (conf=3D0x507b1248, file=3D0x0, = eline=3D0x509eaaf4) at = /usr/src/crypto/openssl/crypto/conf/conf_lib.c:265 #8 0x000000005041e97c in CONF_modules_load_file (filename=3D, appname=3D0x507c3da0 ". . .",=20 flags=3D1363206144) at = /usr/src/crypto/openssl/crypto/conf/conf_mod.c:179 #9 0x00000000503ce39c in OPENSSL_config (config_name=3D0x51415000 "") = at /usr/src/crypto/openssl/crypto/conf/conf_sap.c:90 #10 0x00000000500e6200 in Fssh_ssh_OpenSSL_add_all_algorithms () at = /usr/src/crypto/openssh/openbsd-compat/openssl-compat.c:78 #11 0x000000001000e0e0 in main (ac=3D0, av=3D) at = /usr/src/crypto/openssh/sshd.c:1553 #12 0x000000001000d4bc in 00000016.plt_call.Fssh_scan_scaled () #13 0x0000000050057b70 in .text () at = /usr/src/libexec/rtld-elf/powerpc64/rtld_start.S:104 =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-hackers@freebsd.org Sun Jul 2 03:41:00 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5378BD9BB73; Sun, 2 Jul 2017 03:41:00 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BDB837DDF1; Sun, 2 Jul 2017 03:40:59 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id v623eqH4040937 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 2 Jul 2017 06:40:53 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua v623eqH4040937 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id v623eq4j040934; Sun, 2 Jul 2017 06:40:52 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 2 Jul 2017 06:40:52 +0300 From: Konstantin Belousov To: Mark Millard Cc: FreeBSD PowerPC ML , FreeBSD Current , freebsd-hackers@freebsd.org Subject: Re: head -r320521 (e.g.): another powerpc64 problem: programs using fgets crash trying to store address over code instead of into __cleanup_info__ Message-ID: <20170702034052.GE1935@kib.kiev.ua> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.8.3 (2017-05-23) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jul 2017 03:41:00 -0000 On Sat, Jul 01, 2017 at 07:42:11PM -0700, Mark Millard wrote: > powerpc64 is having programs crash with an attempt > to store addresses over code instead of into > __cleanup_info__ when fgets is used. ntpd is an > example. As is sshd (although I've looked at > its details less). Yes, I think you are right. I also see how this worked on amd64, where I tested the change. Try this. diff --git a/lib/libc/gen/_pthread_stubs.c b/lib/libc/gen/_pthread_stubs.c index 18a23216d50..fcf7ff04fed 100644 --- a/lib/libc/gen/_pthread_stubs.c +++ b/lib/libc/gen/_pthread_stubs.c @@ -279,10 +279,11 @@ STUB_FUNC2(pthread_kill, PJT_KILL, int, void *, int) STUB_FUNC2(pthread_setcancelstate, PJT_SETCANCELSTATE, int, int, void *) STUB_FUNC2(pthread_setcanceltype, PJT_SETCANCELTYPE, int, int, void *) STUB_FUNC(pthread_testcancel, PJT_TESTCANCEL, void) -STUB_FUNC1(__pthread_cleanup_pop_imp, PJT_CLEANUP_POP_IMP, int, int) -STUB_FUNC2(__pthread_cleanup_push_imp, PJT_CLEANUP_PUSH_IMP, void, void*, void *); -STUB_FUNC1(_pthread_cancel_enter, PJT_CANCEL_ENTER, int, int) -STUB_FUNC1(_pthread_cancel_leave, PJT_CANCEL_LEAVE, int, int) +STUB_FUNC1(__pthread_cleanup_pop_imp, PJT_CLEANUP_POP_IMP, void, int) +STUB_FUNC3(__pthread_cleanup_push_imp, PJT_CLEANUP_PUSH_IMP, void, void *, + void *, void *); +STUB_FUNC1(_pthread_cancel_enter, PJT_CANCEL_ENTER, void, int) +STUB_FUNC1(_pthread_cancel_leave, PJT_CANCEL_LEAVE, void, int) static int stub_zero(void) From owner-freebsd-hackers@freebsd.org Sun Jul 2 04:53:57 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B97C5D9D400 for ; Sun, 2 Jul 2017 04:53:57 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-15.reflexion.net [208.70.210.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 686DC7FECE for ; Sun, 2 Jul 2017 04:53:56 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 8037 invoked from network); 2 Jul 2017 04:58:12 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 2 Jul 2017 04:58:12 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.1) with SMTP; Sun, 02 Jul 2017 00:53:55 -0400 (EDT) Received: (qmail 26071 invoked from network); 2 Jul 2017 04:53:55 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 2 Jul 2017 04:53:55 -0000 Received: from [192.168.1.114] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id B9F90EC81E6; Sat, 1 Jul 2017 21:53:54 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: head -r320521 (e.g.): another powerpc64 problem: programs using fgets crash trying to store address over code instead of into __cleanup_info__ From: Mark Millard In-Reply-To: <20170702034052.GE1935@kib.kiev.ua> Date: Sat, 1 Jul 2017 21:53:54 -0700 Cc: FreeBSD PowerPC ML , FreeBSD Current , freebsd-hackers@freebsd.org, bob prohaska Content-Transfer-Encoding: quoted-printable Message-Id: <63F748A7-9750-4065-B268-6E19A6BEC829@dsl-only.net> References: <20170702034052.GE1935@kib.kiev.ua> To: Konstantin Belousov X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jul 2017 04:53:57 -0000 On 2017-Jul-1, at 8:40 PM, Konstantin Belousov = wrote: > On Sat, Jul 01, 2017 at 07:42:11PM -0700, Mark Millard wrote: >> powerpc64 is having programs crash with an attempt >> to store addresses over code instead of into >> __cleanup_info__ when fgets is used. ntpd is an >> example. As is sshd (although I've looked at >> its details less). >=20 > Yes, I think you are right. I also see how this worked on amd64, > where I tested the change. >=20 > Try this. >=20 > diff --git a/lib/libc/gen/_pthread_stubs.c = b/lib/libc/gen/_pthread_stubs.c > index 18a23216d50..fcf7ff04fed 100644 > --- a/lib/libc/gen/_pthread_stubs.c > +++ b/lib/libc/gen/_pthread_stubs.c > @@ -279,10 +279,11 @@ STUB_FUNC2(pthread_kill, PJT_KILL, int, void *, = int) > STUB_FUNC2(pthread_setcancelstate, PJT_SETCANCELSTATE, int, int, void = *) > STUB_FUNC2(pthread_setcanceltype, PJT_SETCANCELTYPE, int, int, void *) > STUB_FUNC(pthread_testcancel, PJT_TESTCANCEL, void) > -STUB_FUNC1(__pthread_cleanup_pop_imp, PJT_CLEANUP_POP_IMP, int, int) > -STUB_FUNC2(__pthread_cleanup_push_imp, PJT_CLEANUP_PUSH_IMP, void, = void*, void *); > -STUB_FUNC1(_pthread_cancel_enter, PJT_CANCEL_ENTER, int, int) > -STUB_FUNC1(_pthread_cancel_leave, PJT_CANCEL_LEAVE, int, int) > +STUB_FUNC1(__pthread_cleanup_pop_imp, PJT_CLEANUP_POP_IMP, void, int) > +STUB_FUNC3(__pthread_cleanup_push_imp, PJT_CLEANUP_PUSH_IMP, void, = void *, > + void *, void *); > +STUB_FUNC1(_pthread_cancel_enter, PJT_CANCEL_ENTER, void, int) > +STUB_FUNC1(_pthread_cancel_leave, PJT_CANCEL_LEAVE, void, int) >=20 > static int > stub_zero(void) That fixed the issue for my powerpc64 context. For examples: sshd and ntpd are running. I'll go rebuild the rest of my contexts now. Thanks! =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-hackers@freebsd.org Sun Jul 2 15:34:14 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 20BA4DA81E3 for ; Sun, 2 Jul 2017 15:34:14 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from smtp.digiware.nl (smtp.digiware.nl [IPv6:2001:4cb8:90:ffff::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E18B76E928 for ; Sun, 2 Jul 2017 15:34:13 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from router.digiware.nl (localhost.digiware.nl [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id 78B71433D0; Sun, 2 Jul 2017 17:34:08 +0200 (CEST) X-Virus-Scanned: amavisd-new at digiware.com Received: from smtp.digiware.nl ([127.0.0.1]) by router.digiware.nl (router.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JCCPAU0iFCke; Sun, 2 Jul 2017 17:34:07 +0200 (CEST) Received: from [192.168.10.67] (opteron [192.168.10.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.digiware.nl (Postfix) with ESMTPSA id B11EC433CF for ; Sun, 2 Jul 2017 17:34:07 +0200 (CEST) To: FreeBSD Hackers From: Willem Jan Withagen Subject: Reporting missing calls..... Message-ID: Date: Sun, 2 Jul 2017 17:34:05 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jul 2017 15:34:14 -0000 Hi, I spent the larger part of the weekend finding out why my ceph daemons were crashing without much logging, tracebacks or cores... Turns out I got bitten by the fact that 11.1 does introduce fdatasync, which is used by ceph. Compilation is on a server that I also test the RC's on, so there fdatasync was available. But the jails were not upgraded, and missed fdatasync. So that is definitely a pilot error on my end. But it would have helped me enormously if the late binding error got logged in something like /var/log/messages.... Especially since these are daemons, which can for quite some time before a call to fdatasync is made, it took me quite some time to actually run the daemon in the foreground and see this little pesky line about missing fdatasync. Would it be hard to add this to the code, or did I just mis other signs? --WjW From owner-freebsd-hackers@freebsd.org Tue Jul 4 00:32:24 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 66AAA9F2A06 for ; Tue, 4 Jul 2017 00:32:24 +0000 (UTC) (envelope-from zbeeble@gmail.com) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F01C32C53 for ; Tue, 4 Jul 2017 00:32:23 +0000 (UTC) (envelope-from zbeeble@gmail.com) Received: by mail-wm0-x235.google.com with SMTP id f67so68893724wmh.1 for ; Mon, 03 Jul 2017 17:32:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=GVTonobnwOlZXr8LdhQnkfmQjAKiqsYHDObevTh/usk=; b=fJQ9WkuBj+Vh0zwv+8zb/XhqYjfRba7pNlV092cH3Wsa2clXuGT3uc8sfn6or46wgn v1wrFhWGwLWKVtRelOiAUVFZ5rTTUiKz7G7vj1BL/6b8mHsdmj6E12ouMo/OwkZPVR/m 2QUHdOgo8/JC8RzvCZai/dD2Qf9kxjmVkUSfiU2zr3SZ80oZmtcVgICZTWzIUXJLElbC jA2C/ZTugpulnT+5Y9R0Y8YIDXAnOSeS+sUo+ipZimDqD4o7GucCAmCDGE23g85Hh1US A6+L1qmxP1IswVKsMcStXDQNSBeywn1qZfGNNf9M6/Ennr21lT8u5Is2TAWGLEYKE5T9 Zcag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=GVTonobnwOlZXr8LdhQnkfmQjAKiqsYHDObevTh/usk=; b=dwYAo2J4br+43uvcNwlmdRXSJGFripUfVqSg/JhPIKE6OBkyw6JRih/t/LeEickVlK 9bijd/+660LEN5ZK09stuB0/a2I7kq7tk31EkiTXxWSPlmQKtzBBNpVyKpbkZy4Fdx3c b5qEjXpipfyaSNmGKrjup+x8ys3MNPGOSiQfRwY3/Mr1ADc1idkb0oZoyEZVMgv3wH8G Aw4XqlCNy4dX4tpQz9I5qIdFzSmrFHlfy1EtKytO0nm2o/V9yYdboHoHDWDnGzPJa4tF u7L3Osk3HaI+jYglSAL/2YJoODLU6GbSsQlsYW5B3beKLEu/p64ARuXSpUmtFim/uc1S Ciuw== X-Gm-Message-State: AKS2vOxLztqlsnzFWkAPFmTQUVsIfqwfaq7dbl7rWhYNTbmROcyUUVdu Ml1gM9YLKY70sGX7pkL0PjCFhJ7qUA== X-Received: by 10.80.222.67 with SMTP id a3mr16632171edl.32.1499128341259; Mon, 03 Jul 2017 17:32:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.183.176 with HTTP; Mon, 3 Jul 2017 17:32:20 -0700 (PDT) From: Zaphod Beeblebrox Date: Mon, 3 Jul 2017 20:32:20 -0400 Message-ID: Subject: How to diagnose hang just before reboot... To: FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jul 2017 00:32:24 -0000 So... I've got an 11-STABLE machine that is ZFS only, but the march of zeros competes and the geoms destroy themselves... then it just sits there with that on the screen ... not rebooting. What do I twiddle to diagnose the cause (this didn't happen before a bunch of changes... so I'm not sure who is the culprit). From owner-freebsd-hackers@freebsd.org Wed Jul 5 13:58:48 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7F31ADABC05 for ; Wed, 5 Jul 2017 13:58:48 +0000 (UTC) (envelope-from tcberner@gmail.com) Received: from mail-yb0-f177.google.com (mail-yb0-f177.google.com [209.85.213.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 402D381836 for ; Wed, 5 Jul 2017 13:58:47 +0000 (UTC) (envelope-from tcberner@gmail.com) Received: by mail-yb0-f177.google.com with SMTP id f194so13043398yba.3 for ; Wed, 05 Jul 2017 06:58:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=ci2So/S40CKjp4UG7bSCoBOeSeSvdXZj+OZTNgokJEQ=; b=mBeMlUeeqiJRGARzpdtxrpGR72QzuyyZF45r8ybtrOFFy+mztAB8+UlMoXpViSqvOl wEdnob1W6ZV4ZndAVNKl46X6CUM6dy7ZhwKf68hUCXlfcoP7xKYfTSAGnSvS6rUWMA1W rUaIWs97WQ9IfSjkpa6SwsAQXnc8enwa7yeoSYWFIP86+jzgdPNO1fLlsxd0IzRHY6bp Zq1rL+nbzIbu8BXwxAtLW0dxHrfmDlH3tQuwPvuLFyFVeq7NndM/n1yXeAZqANPGZfbM s3cHSUNwec16PsH5k9tsKmHWGozRPvF6plzjWQL4KXus3RdQqIl2VZzn++b42TdVKn8U TNRg== X-Gm-Message-State: AIVw111ryFa3+2odRrbTINxqntAcLudTQaeNgbx1iUhCMKFMnluKlU+9 MEftTOMNFqkhmNlXJ9k= X-Received: by 10.37.41.65 with SMTP id p62mr15155782ybp.36.1499259885982; Wed, 05 Jul 2017 06:04:45 -0700 (PDT) Received: from mail-yb0-f178.google.com (mail-yb0-f178.google.com. [209.85.213.178]) by smtp.gmail.com with ESMTPSA id d139sm6215788ywe.40.2017.07.05.06.04.45 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Jul 2017 06:04:45 -0700 (PDT) Received: by mail-yb0-f178.google.com with SMTP id 84so71876082ybe.0 for ; Wed, 05 Jul 2017 06:04:45 -0700 (PDT) X-Received: by 10.37.164.66 with SMTP id f60mr9650894ybi.23.1499259885501; Wed, 05 Jul 2017 06:04:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.86.3 with HTTP; Wed, 5 Jul 2017 06:04:45 -0700 (PDT) From: "Tobias C. Berner" Date: Wed, 5 Jul 2017 15:04:45 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: How to use kevent to monitor removal of a socket-file To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 13:58:48 -0000 Hi there I want to be notified once a given socket file, say '/var/run/socket.pipe' gets deleted. Something like +---------------------------------------------+ | string path = "/var/run/socket.pipe"; | | int fd = open(path, O_RDONLY); | | EV_SET(&k, fd, ...); | | kevent(..., &k, ...); | +---------------------------------------------+ however does not work, as open(2) does not handle socket files, throwing back ENOTSUPP : An attempt was made to open a socket (not currently implemented). What is the proper way to monitor such files? * Just monitoring the parent directory for changes, and look up whether the file still exists each time? * Connecting to the socket and using EVFILT_READ and wait for EOF? Am I missing the obvious solution here? mfg Tobias From owner-freebsd-hackers@freebsd.org Wed Jul 5 21:43:48 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 71C00D92DE9 for ; Wed, 5 Jul 2017 21:43:48 +0000 (UTC) (envelope-from j.deboynepollard-newsgroups@ntlworld.com) Received: from smtpq3.tb.ukmail.iss.as9143.net (smtpq3.tb.ukmail.iss.as9143.net [212.54.57.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2CB6C72461 for ; Wed, 5 Jul 2017 21:43:47 +0000 (UTC) (envelope-from j.deboynepollard-newsgroups@ntlworld.com) Received: from [212.54.57.80] (helo=smtp1.tb.ukmail.iss.as9143.net) by smtpq3.tb.ukmail.iss.as9143.net with esmtp (Exim 4.86_2) (envelope-from ) id 1dSr7A-0001MR-FL for freebsd-hackers@freebsd.org; Wed, 05 Jul 2017 22:41:36 +0200 Received: from oxbe2.tb.ukmail.iss.as9143.net ([172.25.160.133]) by smtp1.tb.ukmail.iss.as9143.net with bizsmtp id h8hT1v0012syzTg018hTgF; Wed, 05 Jul 2017 22:41:27 +0200 X-SourceIP: 172.25.160.133 X-Authenticated-User: j.deboynepollard-newsgroups@ntlworld.com Date: Wed, 5 Jul 2017 21:41:27 +0100 (BST) From: Jonathan de Boyne Pollard Reply-To: Jonathan de Boyne Pollard To: Debian users , FreeBSD Hackers , Supervision Message-ID: <592685009.2293134.1499287287329.JavaMail.open-xchange@oxbe2.tb.ukmail.iss.as9143.net> In-Reply-To: <731531599.156033.1491767527334.JavaMail.open-xchange@oxbe4.tb.ukmail.iss.as9143.net> References: <54430B41.3010301@NTLWorld.com> <76c00c13-4cc9-ed9c-f48f-81a3f050b80b@NTLWorld.com> <0d6afc48-3465-3509-ff46-494da45022bc@NTLWorld.com> <731531599.156033.1491767527334.JavaMail.open-xchange@oxbe4.tb.ukmail.iss.as9143.net> Subject: nosh version 1.34 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Priority: 3 Importance: Medium X-Mailer: Open-Xchange Mailer v7.6.2-Rev60 X-Originating-IP: 185.28.212.96 X-Originating-Client: com.openexchange.ox.gui.dhtml DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ntlworld.com; s=meg.feb2017; t=1499287287; bh=DR4/AInVK+8Hze3kwrTrrA51i12Rxp34/Twegh2UOE8=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject; b=ZU4WH02Kt1CziG07ToTbDxSBRhK9kN1OzlU49RZYsEeTeUGCu4jQX6IUCA9w8I66U ElCFix0Y+svIjbGlAORQTXHmU80C02EzWXYt7N7/8RcJlK9lXgKHM4HVgUmUIoJ4EQ hbMlkPe5fDfBOOKt6TlGS91CluWXua81xAsC+r7TrooKmSQjvz+ZUl1OilUtiNoHBc BPG0LmkIjKl9QumFrRlOki7GKcj51I6PVFR9Bvp8zyzafa95mxZILtzIFt3cyqKJqU Cnf/CP++f5npswhvtcMjZrnFr2kO/xpQyNXiEfvEMWZgkxGhpZJUjAqCNSxIrab26/ d7UYpIvVBYB6g== X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 21:43:48 -0000 The nosh package is now up to version 1.34 . * http://jdebp.eu./Softwares/nosh/ * https://www.freebsd.org/news/status/report-2015-07-2015-09.html#The-nosh-Project * http://jdebp.info./Softwares/nosh/ Once again, there are a few more service bundles. The most interesting ones in this version are perhaps the finish-update and finish-install targets, designed to be invoked the first bootstrap after an update or install has been done, and the users target, which is used to auto-start per-user subsystems at bootstrap. Several NFS service bundles are now common across operating systems. And the OpenVPN service bundles are now split into separate client and server services. Several minor bugs have been fixed here and there: a duplicated newline in line-banner that was throwing off publicfile FTP service; a problem with recordio on FreeBSD/TrueOS; and a problem with attempts to use slashes in environment variables in service bundle environment directories. The user-space virtual terminal emulator now implements the Xterm extensions to DECSCUSR, and the framebuffer realizer can display the resultant cursor shapes. This can be made use of by programs such as Neovim. There are now separate service bundles and nosh-run- packages for running eudev and systemd-udev, because the two are now significantly divergent. The various utilities for changing the process environment no longer use the GNU C library/BSD C library functions for doing so, and so no longer suffer from the concomitant memory leaks that their manual pages used to warn about. The convert-systemd-units tool has been slightly enhanced, for the benefit of a fix that has been made to the per-user gpg-agent service. The external configuration imports system has been extended. It now deals with importing the hostname configuration value, taking that responsibility away from and simplifying the set-dynamic-hostname utility. It now imports various Debian and other kernel virtual terminal settings, from /etc/kbd/config, /etc/default/console-setup, and /etc/vconsole.conf . And network configuration import now can set up services for both dhcpcd and dhclient. /etc/system-control/convert/rc.conf now contains more settings on Linux operating systems as a result, including dhclient_program. From owner-freebsd-hackers@freebsd.org Thu Jul 6 13:47:31 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 96339DAE138 for ; Thu, 6 Jul 2017 13:47:31 +0000 (UTC) (envelope-from sebastian.huber@embedded-brains.de) Received: from dedi548.your-server.de (dedi548.your-server.de [85.10.215.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 53EF76FFE8; Thu, 6 Jul 2017 13:47:30 +0000 (UTC) (envelope-from sebastian.huber@embedded-brains.de) Received: from [88.198.220.130] (helo=sslproxy01.your-server.de) by dedi548.your-server.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.85_2) (envelope-from ) id 1dT6m0-0001jM-Jz; Thu, 06 Jul 2017 15:24:48 +0200 Received: from [82.135.62.35] (helo=mail.embedded-brains.de) by sslproxy01.your-server.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1dT6lv-0005Vk-C9; Thu, 06 Jul 2017 15:24:43 +0200 Received: from localhost (localhost.localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id 174332A004F; Thu, 6 Jul 2017 15:24:53 +0200 (CEST) Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 8edlrieEalKl; Thu, 6 Jul 2017 15:24:52 +0200 (CEST) Received: from localhost (localhost.localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id A07CA2A160A; Thu, 6 Jul 2017 15:24:52 +0200 (CEST) X-Virus-Scanned: amavisd-new at zimbra.eb.localhost Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id wciEhVGC3FxC; Thu, 6 Jul 2017 15:24:52 +0200 (CEST) Received: from linux-diu0.suse (unknown [192.168.96.129]) by mail.embedded-brains.de (Postfix) with ESMTP id 7CAFE2A004F; Thu, 6 Jul 2017 15:24:52 +0200 (CEST) From: Sebastian Huber To: freebsd-hackers@freebsd.org Cc: kib@freebsd.org Subject: [PATCH] bitset(9): Add BIT_FLS() Date: Thu, 6 Jul 2017 15:24:40 +0200 Message-Id: <20170706132440.18520-1-sebastian.huber@embedded-brains.de> X-Mailer: git-send-email 2.12.3 X-Authenticated-Sender: smtp-embedded@poldinet.de X-Virus-Scanned: Clear (ClamAV 0.99.2/23539/Thu Jul 6 14:09:54 2017) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jul 2017 13:47:31 -0000 Add BIT_FLS() analogous to BIT_FFS(). The benefit of BIT_FLS() is that ffsl() can be implemented with a count leading zeros instruction which is more widespread available. --- share/man/man9/bitset.9 | 22 +++++++++++++++++++++- sys/sys/bitset.h | 15 +++++++++++++++ 2 files changed, 36 insertions(+), 1 deletion(-) diff --git a/share/man/man9/bitset.9 b/share/man/man9/bitset.9 index d4060ace24c..f7f8a502b04 100644 --- a/share/man/man9/bitset.9 +++ b/share/man/man9/bitset.9 @@ -24,7 +24,7 @@ .\" .\" $FreeBSD$ .\" -.Dd May 24, 2017 +.Dd July 6, 2017 .Dt BITSET 9 .Os .Sh NAME @@ -43,6 +43,7 @@ .Nm BIT_EMPTY , .Nm BIT_ISFULLSET , .Nm BIT_FFS , +.Nm BIT_FLS , .Nm BIT_COUNT , .Nm BIT_SUBSET , .Nm BIT_OVERLAP , @@ -85,6 +86,8 @@ .Ft int .Fn BIT_FFS "const SETSIZE" "struct STRUCTNAME *bitset" .Ft int +.Fn BIT_FLS "const SETSIZE" "struct STRUCTNAME *bitset" +.Ft int .Fn BIT_COUNT "const SETSIZE" "struct STRUCTNAME *bitset" .\" .Ft bool @@ -282,6 +285,23 @@ index parameter to any other macro, you must subtract one from the result. .Pp The +.Fn BIT_FLS +macro returns the 1-index of the last (highest) set bit in +.Fa bitset , +or zero if +.Fa bitset +is empty. +Like with +.Xr fls 3 , +to use the non-zero result of +.Fn BIT_FLS +as a +.Fa bit +index parameter to any other +.Nm +macro, you must subtract one from the result. +.Pp +The .Fn BIT_COUNT macro returns the total number of set bits in .Fa bitset . diff --git a/sys/sys/bitset.h b/sys/sys/bitset.h index 8bc9e3d87a0..1ed19531b3b 100644 --- a/sys/sys/bitset.h +++ b/sys/sys/bitset.h @@ -213,6 +213,21 @@ __bit; \ }) +#define BIT_FLS(_s, p) __extension__ ({ \ + __size_t __i; \ + int __bit; \ + \ + __bit = 0; \ + for (__i = __bitset_words((_s)) - 1; __i >= 0; __i--) { \ + if ((p)->__bits[__i] != 0) { \ + __bit = flsl((p)->__bits[__i]); \ + __bit += __i * _BITSET_BITS; \ + break; \ + } \ + } \ + __bit; \ +}) + #define BIT_COUNT(_s, p) __extension__ ({ \ __size_t __i; \ int __count; \ -- 2.12.3 From owner-freebsd-hackers@freebsd.org Thu Jul 6 21:12:56 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B798AD920DD for ; Thu, 6 Jul 2017 21:12:56 +0000 (UTC) (envelope-from marcnarc@xiplink.com) Received: from smtp93.ord1c.emailsrvr.com (smtp93.ord1c.emailsrvr.com [108.166.43.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9ADF27FD0D for ; Thu, 6 Jul 2017 21:12:56 +0000 (UTC) (envelope-from marcnarc@xiplink.com) Received: from smtp28.relay.ord1c.emailsrvr.com (localhost [127.0.0.1]) by smtp28.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id D925940378; Thu, 6 Jul 2017 17:02:59 -0400 (EDT) X-Auth-ID: mbranchaud@xiplink.com Received: by smtp28.relay.ord1c.emailsrvr.com (Authenticated sender: mbranchaud-AT-xiplink.com) with ESMTPSA id B066F40321; Thu, 6 Jul 2017 17:02:59 -0400 (EDT) X-Sender-Id: mbranchaud@xiplink.com Received: from [10.10.1.32] ([UNAVAILABLE]. [192.252.130.194]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA) by 0.0.0.0:465 (trex/5.7.12); Thu, 06 Jul 2017 17:02:59 -0400 To: freebsd-hackers@freebsd.org From: Marc Branchaud Subject: libexecinfo backtrace() in a signal handler Message-ID: <4d662753-98bc-1275-9394-0cda95eedc65@xiplink.com> Date: Thu, 6 Jul 2017 17:02:59 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 06 Jul 2017 21:37:29 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jul 2017 21:12:56 -0000 Howdy, (Please CC replies to me, as I am not subscribed. Apologies if I'm in the wrong forum!) I'm trying to use libexecinfo's backtrace() in a SIGSEGV handler. It only finds one single frame in the stack, for the signal handler function. (Outside of the signal handler backtrace() does return the full stack from the call point.) Is there any way to get the stack from where the SIGSEGV arose? A few hours of Googling has proved fruitless. My overall goal is to intercept core-dumping signals to try to save a textual backtrace instead of a full dump (as they can be quite large in my application). So I'd also like to catch SIGBUS, and maybe SIGFPE too. Details: FreeBSD 9 (yes, ouch, I know, but I see the same problem in 10) libexecinfo is copied from STABLE-10 amd64 gcc Here's a little test app. Even when compiled with -O0, backtrace() still only finds the frame for the handler() function. ----->8----->8----->8----->8------>8---->8----->8----->8----- #include #include #include #include #include void handler(int sig) { void *frames[10]; size_t size = backtrace(frames, sizeof(frames)); fprintf(stderr, "Signal %d:\n", sig); fprintf(stderr, "%zu FRAMES:\n", size); backtrace_symbols_fd(frames, size, STDERR_FILENO); exit(1); } void baz() { int *foo = (int*)-1; printf("%d\n", *foo); } void bar() { baz(); } void foo() { bar(); } int main(int argc, char **argv) { signal(SIGSEGV, handler); foo(); return 0; } ----->8----->8----->8----->8------>8---->8----->8----->8----- Thanks! M. From owner-freebsd-hackers@freebsd.org Thu Jul 6 22:58:12 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1783AD940D0 for ; Thu, 6 Jul 2017 22:58:12 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: from mail-pg0-f44.google.com (mail-pg0-f44.google.com [74.125.83.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E3D4A82E87 for ; Thu, 6 Jul 2017 22:58:11 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: by mail-pg0-f44.google.com with SMTP id t186so7793963pgb.1 for ; Thu, 06 Jul 2017 15:58:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=mQeu+BJvQMsUCTeFtT18t5a+x08ImtXxot+2yyy/Mtw=; b=X+i72C9KYj+ZDFXTN2ZGDjsHdyf+94vTb1pVD00yw3KgdDYDMK7/u00Yyt+APpCnhS 525ra8kF9bOGlSEZxCmgbbEbb3oXy18eF6eeo5nASeF+8yZTBZNxHVvA8r4GCOwC59wf +i/eQZZFKtylZlz+A/cJ++uur6VUzorLW3olbln08EGiboqHP5CQWlFngAW0VS4MvfzH y26BZIXe6D1Bp8LiypIGGc+qt42qPo5pTMB2xWXFgmTdcj6lf45TdpjPdJXYm/ZLY6SO 1R/rsCVoA1ZRSPFB+1jwC9L/twq9Lure4k3qQL8OoQZZQWXsTH85dz7uvVJM4eijNOuY WU/w== X-Gm-Message-State: AIVw110U/ZYsNhGZuQSGdSPuCOTBOZce0Z6OlGlaomMKszHDuBfP3G4H jHRqlYN+frHgAGMKoRY= X-Received: by 10.98.78.88 with SMTP id c85mr28817062pfb.17.1499381885482; Thu, 06 Jul 2017 15:58:05 -0700 (PDT) Received: from mail-pf0-f174.google.com (mail-pf0-f174.google.com. [209.85.192.174]) by smtp.gmail.com with ESMTPSA id p15sm2388182pfi.99.2017.07.06.15.58.05 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 06 Jul 2017 15:58:05 -0700 (PDT) Received: by mail-pf0-f174.google.com with SMTP id e7so7775402pfk.0 for ; Thu, 06 Jul 2017 15:58:05 -0700 (PDT) X-Received: by 10.84.150.164 with SMTP id h33mr31500265plh.152.1499381885221; Thu, 06 Jul 2017 15:58:05 -0700 (PDT) MIME-Version: 1.0 Reply-To: cem@freebsd.org Received: by 10.100.146.15 with HTTP; Thu, 6 Jul 2017 15:58:04 -0700 (PDT) In-Reply-To: <4d662753-98bc-1275-9394-0cda95eedc65@xiplink.com> References: <4d662753-98bc-1275-9394-0cda95eedc65@xiplink.com> From: Conrad Meyer Date: Thu, 6 Jul 2017 15:58:04 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: libexecinfo backtrace() in a signal handler To: Marc Branchaud Cc: "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jul 2017 22:58:12 -0000 On Thu, Jul 6, 2017 at 2:02 PM, Marc Branchaud wrote: > Howdy, > > (Please CC replies to me, as I am not subscribed. Apologies if I'm in the > wrong forum!) > > I'm trying to use libexecinfo's backtrace() in a SIGSEGV handler. It only > finds one single frame in the stack, for the signal handler function. > (Outside of the signal handler backtrace() does return the full stack from > the call point.) > > Is there any way to get the stack from where the SIGSEGV arose? A few hours > of Googling has proved fruitless. > > My overall goal is to intercept core-dumping signals to try to save a > textual backtrace instead of a full dump (as they can be quite large in my > application). So I'd also like to catch SIGBUS, and maybe SIGFPE too. Hi Marc, Signal handlers use a special stack frame that libexecinfo is too simple to understand. To get a stack from a signal handler, you might want to use libunwind instead. Best, Conrad From owner-freebsd-hackers@freebsd.org Thu Jul 6 23:16:39 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C71E7D94564 for ; Thu, 6 Jul 2017 23:16:39 +0000 (UTC) (envelope-from joerg@bec.de) Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [217.70.183.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 866CF83627; Thu, 6 Jul 2017 23:16:39 +0000 (UTC) (envelope-from joerg@bec.de) Received: from britannica.bec.de (p200300D2ABC87B104639C4FFFE599710.dip0.t-ipconnect.de [IPv6:2003:d2:abc8:7b10:4639:c4ff:fe59:9710]) (Authenticated sender: joerg@bec.de) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id 8E244A80C7; Fri, 7 Jul 2017 01:16:30 +0200 (CEST) Date: Fri, 7 Jul 2017 01:16:22 +0200 From: Joerg Sonnenberger To: Conrad Meyer Cc: Marc Branchaud , "freebsd-hackers@freebsd.org" Subject: Re: libexecinfo backtrace() in a signal handler Message-ID: <20170706231622.GA26699@britannica.bec.de> Mail-Followup-To: Conrad Meyer , Marc Branchaud , "freebsd-hackers@freebsd.org" References: <4d662753-98bc-1275-9394-0cda95eedc65@xiplink.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.8.3 (2017-05-23) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jul 2017 23:16:39 -0000 On Thu, Jul 06, 2017 at 03:58:04PM -0700, Conrad Meyer wrote: > Signal handlers use a special stack frame that libexecinfo is too > simple to understand. To get a stack from a signal handler, you might > want to use libunwind instead. Actually, that's not the problem. The problem is that nothing registers the necessary unwind data. Joerg From owner-freebsd-hackers@freebsd.org Thu Jul 6 23:52:46 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 06A0BD94E31 for ; Thu, 6 Jul 2017 23:52:46 +0000 (UTC) (envelope-from lidl@pix.net) Received: from hydra.pix.net (hydra.pix.net [IPv6:2001:470:e254::4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.pix.net", Issuer "Pix.Com Technologies LLC CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id AD661842D3 for ; Thu, 6 Jul 2017 23:52:45 +0000 (UTC) (envelope-from lidl@pix.net) Received: from torb.pix.net (torb.pix.net [192.168.16.32]) (authenticated bits=0) by hydra.pix.net (8.16.0.19/8.15.2) with ESMTPA id v66Nqhtj098420; Thu, 6 Jul 2017 19:52:44 -0400 (EDT) (envelope-from lidl@pix.net) To: freebsd-hackers@freebsd.org References: <4d662753-98bc-1275-9394-0cda95eedc65@xiplink.com> Subject: Re: libexecinfo backtrace() in a signal handler From: Kurt Lidl Message-ID: Date: Thu, 6 Jul 2017 19:52:43 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <4d662753-98bc-1275-9394-0cda95eedc65@xiplink.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jul 2017 23:52:46 -0000 You might want to look at this code: https://github.com/stass/libsegfault Which uses this libunwind: (I think) http://www.nongnu.org/libunwind/man/libunwind(3).html Might be just want you wanted. -Kurt From owner-freebsd-hackers@freebsd.org Fri Jul 7 05:04:31 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AE9C2D9A34A for ; Fri, 7 Jul 2017 05:04:31 +0000 (UTC) (envelope-from sebastian.huber@embedded-brains.de) Received: from dedi548.your-server.de (dedi548.your-server.de [85.10.215.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 43D5E67851; Fri, 7 Jul 2017 05:04:30 +0000 (UTC) (envelope-from sebastian.huber@embedded-brains.de) Received: from [88.198.220.130] (helo=sslproxy01.your-server.de) by dedi548.your-server.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.85_2) (envelope-from ) id 1dTLRM-00008S-2b; Fri, 07 Jul 2017 07:04:28 +0200 Received: from [82.135.62.35] (helo=mail.embedded-brains.de) by sslproxy01.your-server.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1dTLRL-00088v-ND; Fri, 07 Jul 2017 07:04:27 +0200 Received: from localhost (localhost.localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id 978A32A004F; Fri, 7 Jul 2017 07:04:37 +0200 (CEST) Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id KhGaMoPdz2JQ; Fri, 7 Jul 2017 07:04:37 +0200 (CEST) Received: from localhost (localhost.localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id 3AA022A1677; Fri, 7 Jul 2017 07:04:37 +0200 (CEST) X-Virus-Scanned: amavisd-new at zimbra.eb.localhost Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id WG9IWqlMwWnl; Fri, 7 Jul 2017 07:04:37 +0200 (CEST) Received: from linux-diu0.suse (unknown [192.168.96.129]) by mail.embedded-brains.de (Postfix) with ESMTP id 18D662A004F; Fri, 7 Jul 2017 07:04:37 +0200 (CEST) From: Sebastian Huber To: freebsd-hackers@freebsd.org Cc: kib@freebsd.org Subject: [PATCH] bitset(9): Improve BIT_FLS() documentation Date: Fri, 7 Jul 2017 07:04:25 +0200 Message-Id: <20170707050425.14630-1-sebastian.huber@embedded-brains.de> X-Mailer: git-send-email 2.12.3 X-Authenticated-Sender: smtp-embedded@poldinet.de X-Virus-Scanned: Clear (ClamAV 0.99.2/23540/Thu Jul 6 22:11:50 2017) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jul 2017 05:04:31 -0000 --- share/man/man9/bitset.9 | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/share/man/man9/bitset.9 b/share/man/man9/bitset.9 index f7f8a502b04..1d02eee252b 100644 --- a/share/man/man9/bitset.9 +++ b/share/man/man9/bitset.9 @@ -24,7 +24,7 @@ .\" .\" $FreeBSD$ .\" -.Dd July 6, 2017 +.Dd July 7, 2017 .Dt BITSET 9 .Os .Sh NAME @@ -519,4 +519,6 @@ argument to all of these macros must match the value given to .Pp Unlike every other reference to individual set members, which are zero-indexed, .Fn BIT_FFS -returns a one-indexed result (or zero if the set is empty). +and +.Fn BIT_FLS +return a one-indexed result (or zero if the set is empty). -- 2.12.3 From owner-freebsd-hackers@freebsd.org Fri Jul 7 05:37:56 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6627AD9ABFE for ; Fri, 7 Jul 2017 05:37:56 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E5768683FD; Fri, 7 Jul 2017 05:37:55 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id v675bjtZ055210 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 7 Jul 2017 08:37:45 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua v675bjtZ055210 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id v675bjrC055209; Fri, 7 Jul 2017 08:37:45 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 7 Jul 2017 08:37:45 +0300 From: Konstantin Belousov To: Conrad Meyer , Marc Branchaud , "freebsd-hackers@freebsd.org" Subject: Re: libexecinfo backtrace() in a signal handler Message-ID: <20170707053744.GM1935@kib.kiev.ua> References: <4d662753-98bc-1275-9394-0cda95eedc65@xiplink.com> <20170706231622.GA26699@britannica.bec.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170706231622.GA26699@britannica.bec.de> User-Agent: Mutt/1.8.3 (2017-05-23) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jul 2017 05:37:56 -0000 On Fri, Jul 07, 2017 at 01:16:22AM +0200, Joerg Sonnenberger wrote: > On Thu, Jul 06, 2017 at 03:58:04PM -0700, Conrad Meyer wrote: > > Signal handlers use a special stack frame that libexecinfo is too > > simple to understand. To get a stack from a signal handler, you might > > want to use libunwind instead. > > Actually, that's not the problem. The problem is that nothing registers > the necessary unwind data. Actually, that's not the problem. Libunwind port on FreeBSD knows how to detect signal trampolines, either with the direct help from kernel, or using some heuristic by parsing instructions, on (much) older kernels. From owner-freebsd-hackers@freebsd.org Fri Jul 7 11:44:47 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 91AF7DA0EB4 for ; Fri, 7 Jul 2017 11:44:47 +0000 (UTC) (envelope-from joerg@bec.de) Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [217.70.183.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 50C8B76DB8; Fri, 7 Jul 2017 11:44:46 +0000 (UTC) (envelope-from joerg@bec.de) Received: from britannica.bec.de (p200300D2ABC87B104639C4FFFE599710.dip0.t-ipconnect.de [IPv6:2003:d2:abc8:7b10:4639:c4ff:fe59:9710]) (Authenticated sender: joerg@bec.de) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id B9FA4A80F1; Fri, 7 Jul 2017 13:44:43 +0200 (CEST) Date: Fri, 7 Jul 2017 13:44:35 +0200 From: Joerg Sonnenberger To: Konstantin Belousov Cc: Conrad Meyer , Marc Branchaud , "freebsd-hackers@freebsd.org" Subject: Re: libexecinfo backtrace() in a signal handler Message-ID: <20170707114435.GA5034@britannica.bec.de> Mail-Followup-To: Konstantin Belousov , Conrad Meyer , Marc Branchaud , "freebsd-hackers@freebsd.org" References: <4d662753-98bc-1275-9394-0cda95eedc65@xiplink.com> <20170706231622.GA26699@britannica.bec.de> <20170707053744.GM1935@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170707053744.GM1935@kib.kiev.ua> User-Agent: Mutt/1.8.3 (2017-05-23) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jul 2017 11:44:47 -0000 On Fri, Jul 07, 2017 at 08:37:45AM +0300, Konstantin Belousov wrote: > On Fri, Jul 07, 2017 at 01:16:22AM +0200, Joerg Sonnenberger wrote: > > On Thu, Jul 06, 2017 at 03:58:04PM -0700, Conrad Meyer wrote: > > > Signal handlers use a special stack frame that libexecinfo is too > > > simple to understand. To get a stack from a signal handler, you might > > > want to use libunwind instead. > > > > Actually, that's not the problem. The problem is that nothing registers > > the necessary unwind data. > > Actually, that's not the problem. Libunwind port on FreeBSD knows how > to detect signal trampolines, either with the direct help from kernel, > or using some heuristic by parsing instructions, on (much) older kernels. But the original question was about libexecinfo and the Itanium unwinder it is using. That would be able to unwind past signal frames iff the proper annotation was registered. I haven't had time to do that for NetBSD, but it is certainly the original problem. Joerg From owner-freebsd-hackers@freebsd.org Fri Jul 7 15:41:15 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 611E7DA6112; Fri, 7 Jul 2017 15:41:15 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 285B67EED3; Fri, 7 Jul 2017 15:41:15 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-it0-x22e.google.com with SMTP id k192so39836622ith.1; Fri, 07 Jul 2017 08:41:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to; bh=HOFjF64C3WiuQ1YdQLZQBlyYFoRCh+A+f66MKViHpc4=; b=tQgk9HvFyMIik9sb1wv79G2IZd1n08RtKe3v5pVjFcwP4KfAFW3pTA7iSNeF5zpgqK bFk46xQgL8gxvBOukUK+a/nPp/jW+XqtMnGMWfw1r0Q9IeJKdxhWXMa/PMawqoIEKzjU BUDHzfev4K9p4CHmV6GGWHVrkXeY8CywBbFAcIPhnn9BR0WeWv2N+Z3vlT/g/YvLNn/f dwJ7iiLW0Ns/1GxWLdZuhmhgE+zLYQtltt0GUqogidsJtzXU8Vpz8Rjap9kp9yR9sJ8P BW5XAjGP4RSRXWI7WcRHkvKH4fzQudMYhWIQ+1K0CkMFfUn4OZetO63TLiy11ssQy3B0 t+mg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to; bh=HOFjF64C3WiuQ1YdQLZQBlyYFoRCh+A+f66MKViHpc4=; b=adyf3DJQFgYrG1s9zGWiqHTH2PiRVf8YNfWQfpoM6jsXMcDvMgI/qgdibLzvjnNlJZ sAxPeSwqsjGsIPIeJhrVOBbPjRLpLOr2S/yiTPMsWv+Za/mHc8kMDLU+JNidRhN11LmF BDIXK/Q6X4vnH2O4Wnr1TLc3mrNDyFtm7T1+52oFfNJTbAne6CyZjuN2+VW4KRaDQlEt 5jiBDVI+XiTA6StDNmLE99leXRAbAGtboEBFOvjGr34YxvN/K5S2K3zSB0BAgoeMoqp3 Tgi3PbNbd+/TaI2HZrXXdcZQvLQ6kppwAcaJCJ2CC2Bs1MJ6XuivogmPwShtoJUH/rlr 1M9g== X-Gm-Message-State: AIVw111Rziz6QGkDgT1jAyuR/Qk7QeTm2cqhKtXWGPFC0Cp7WKwm7dAj 4Ey1aCCWRRZ1Ap1Cjndf+PGLhyo40uTdsTM= X-Received: by 10.36.150.194 with SMTP id z185mr3389183itd.127.1499442074371; Fri, 07 Jul 2017 08:41:14 -0700 (PDT) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 10.107.10.85 with HTTP; Fri, 7 Jul 2017 08:40:53 -0700 (PDT) In-Reply-To: <20170701012751.GN68391@kduck.kaduk.org> References: <20170701012751.GN68391@kduck.kaduk.org> From: Ed Maste Date: Fri, 7 Jul 2017 11:40:53 -0400 X-Google-Sender-Auth: vwLd1PJ9k-PhLbq2BMF2rYLdJ48 Message-ID: Subject: Re: Final Call for 2017Q2 Quarterly Status Reports To: "freebsd-hackers@freebsd.org" , FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jul 2017 15:41:15 -0000 On 30 June 2017 at 21:27, Benjamin Kaduk wrote: > > The preferred and easiest submission method is to use the XML generator [1] > > [1] https://www.FreeBSD.org/cgi/monthly.cgi Note that Chrome has a bug when attempting to save the output of monthly.cgi, and your work will be lost. Please do not use Chrome for monthly.cgi, and inspect the downloaded xml file before submitting to monthly@ and before closing the browser tab. Details in https://bugs.chromium.org/p/chromium/issues/detail?id=617382. From owner-freebsd-hackers@freebsd.org Fri Jul 7 18:12:56 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B3BF7DA8CDE for ; Fri, 7 Jul 2017 18:12:56 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from shell1.rawbw.com (shell1.rawbw.com [198.144.192.42]) by mx1.freebsd.org (Postfix) with ESMTP id A2A1484857 for ; Fri, 7 Jul 2017 18:12:56 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from yv.noip.me (c-24-6-186-56.hsd1.ca.comcast.net [24.6.186.56]) (authenticated bits=0) by shell1.rawbw.com (8.15.1/8.15.1) with ESMTPSA id v67ICouW030369 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 7 Jul 2017 11:12:50 -0700 (PDT) (envelope-from yuri@rawbw.com) X-Authentication-Warning: shell1.rawbw.com: Host c-24-6-186-56.hsd1.ca.comcast.net [24.6.186.56] claimed to be yv.noip.me Subject: Re: CUDA and FreeBSD: can linux kernel module be ported to FreeBSD? To: Joe Nosay References: Cc: Freebsd hackers list From: Yuri Message-ID: Date: Fri, 7 Jul 2017 11:12:49 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jul 2017 18:12:56 -0000 On 07/06/2017 12:13, Joe Nosay wrote: > The mail will bounce for me; and so, I will need you to quote my reply. > Have you asked - or has anyone asked - NVIDIA about accessing the > source code to build CUDA as a native driver/(kernel module) ? Aaron Plattner (aplattner аt nvidia dоt com) is the current maintainer of drivers in NVidia. You can ask him. Yuri From owner-freebsd-hackers@freebsd.org Fri Jul 7 20:06:43 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 779D7DAA9D8 for ; Fri, 7 Jul 2017 20:06:43 +0000 (UTC) (envelope-from marcnarc@xiplink.com) Received: from smtp77.iad3a.emailsrvr.com (smtp77.iad3a.emailsrvr.com [173.203.187.77]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 532A31A44 for ; Fri, 7 Jul 2017 20:06:42 +0000 (UTC) (envelope-from marcnarc@xiplink.com) Received: from smtp34.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp34.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 0A14B24C70; Fri, 7 Jul 2017 16:01:09 -0400 (EDT) X-Auth-ID: mbranchaud@xiplink.com Received: by smtp34.relay.iad3a.emailsrvr.com (Authenticated sender: mbranchaud-AT-xiplink.com) with ESMTPSA id CF78624BBD; Fri, 7 Jul 2017 16:01:08 -0400 (EDT) X-Sender-Id: mbranchaud@xiplink.com Received: from [10.10.1.32] ([UNAVAILABLE]. [192.252.130.194]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA) by 0.0.0.0:465 (trex/5.7.12); Fri, 07 Jul 2017 16:01:09 -0400 Subject: Re: libexecinfo backtrace() in a signal handler To: cem@freebsd.org References: <4d662753-98bc-1275-9394-0cda95eedc65@xiplink.com> Cc: "freebsd-hackers@freebsd.org" From: Marc Branchaud Message-ID: Date: Fri, 7 Jul 2017 16:01:08 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 07 Jul 2017 20:43:21 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jul 2017 20:06:43 -0000 On 2017-07-06 06:58 PM, Conrad Meyer wrote: > On Thu, Jul 6, 2017 at 2:02 PM, Marc Branchaud wrote: >> Howdy, >> >> (Please CC replies to me, as I am not subscribed. Apologies if I'm in the >> wrong forum!) >> >> I'm trying to use libexecinfo's backtrace() in a SIGSEGV handler. It only >> finds one single frame in the stack, for the signal handler function. >> (Outside of the signal handler backtrace() does return the full stack from >> the call point.) >> >> Is there any way to get the stack from where the SIGSEGV arose? A few hours >> of Googling has proved fruitless. >> >> My overall goal is to intercept core-dumping signals to try to save a >> textual backtrace instead of a full dump (as they can be quite large in my >> application). So I'd also like to catch SIGBUS, and maybe SIGFPE too. > > Hi Marc, > > Signal handlers use a special stack frame that libexecinfo is too > simple to understand. To get a stack from a signal handler, you might > want to use libunwind instead. Thanks Conrad, and everyone else. libunwind does indeed find the frames past the signal handler stack, at least in 10.3 when compiled with clang. (I tested with basically the example show_backtrace() function from the libunwind(3) man page.) I don't know what magic libunwind uses if, as Joerg suggests, the proper annotation isn't registered. Intuitively I figured the information has to be there somewhere, since a SIGSEGV coredump includes the full stack. M.