Re: Crashes in libthr?
On 2016-03-15 12:21, Larry Rosenman wrote: This may have been my screw up On March 15, 2016 12:05:03 PM Bryan Drewery wrote: On 3/14/16 8:03 PM, Larry Rosenman wrote: On 2016-03-14 21:49, Larry Rosenman wrote: On 2016-03-14 18:49, Larry Rosenman wrote: On 2016-03-14 18:47, Steven Hartland wrote: On 14/03/2016 22:28, Larry Rosenman wrote: On 2016-03-14 17:25, Poul-Henning Kamp wrote: In message <2016031428.ga1...@borg.lerctr.org>, Larry Rosenman writes: And sshd is busted. FYI: I seeing no such issues on two systems running: 11.0-CURRENT #4 r296808: Sun Mar 13 22:39:59 UTC 2016 and 11.0-CURRENT #32 r296137: Sat Feb 27 11:34:01 UTC 2016 As I said it's this ONE box, even doing an install from the other (RUNNING) boxes /usr/src,/usr/obj). This build was at: borg.lerctr.org /usr/src $ svn info Path: . Working Copy Root Path: /usr/src URL: https://svn.freebsd.org/base/head Relative URL: ^/head Repository Root: https://svn.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 296823 Node Kind: directory Schedule: normal Last Changed Author: adrian Last Changed Rev: 296823 Last Changed Date: 2016-03-13 23:39:35 -0500 (Sun, 13 Mar 2016) borg.lerctr.org /usr/src $ I can post the make.conf. It's really weird. Silly question your not building on an NFS FS are you? No, this is local disk. The "install from other machine" was via NFS.. I found it. A bad version (from march 8th or so) of /lib/libprivatessh.so.5 that did NOT export the symbol, but the version in /usr/lib/libprivatessh.so.5 DID export the symbol. I wiped out the /lib/libprivate* and re-did installworld. and all seems fine now. I suspect I hit a time when the tree had bad stuff installing into /lib/libprivate* BTW, there were LOTS of OTHER things in /lib with the same bad date, which I've now cleaned up. make delete-old{-libs} did *NOT* clean this up. These were dated March 8 2016? I don't recall any recent changes causing libraries to be installed to the wrong place. -- Regards, Bryan Drewery I think I screwed up badly.. So, thank G-D for ZFS snapshots and Boot Environments. I've reverted to an earler snap/root via clone/promote. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: l...@lerctr.org US Mail: 7011 W Parmer Ln, Apt 1115, Austin, TX 78729-6961 ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Crashes in libthr?
This may have been my screw up On March 15, 2016 12:05:03 PM Bryan Drewery wrote: On 3/14/16 8:03 PM, Larry Rosenman wrote: On 2016-03-14 21:49, Larry Rosenman wrote: On 2016-03-14 18:49, Larry Rosenman wrote: On 2016-03-14 18:47, Steven Hartland wrote: On 14/03/2016 22:28, Larry Rosenman wrote: On 2016-03-14 17:25, Poul-Henning Kamp wrote: In message <2016031428.ga1...@borg.lerctr.org>, Larry Rosenman writes: And sshd is busted. FYI: I seeing no such issues on two systems running: 11.0-CURRENT #4 r296808: Sun Mar 13 22:39:59 UTC 2016 and 11.0-CURRENT #32 r296137: Sat Feb 27 11:34:01 UTC 2016 As I said it's this ONE box, even doing an install from the other (RUNNING) boxes /usr/src,/usr/obj). This build was at: borg.lerctr.org /usr/src $ svn info Path: . Working Copy Root Path: /usr/src URL: https://svn.freebsd.org/base/head Relative URL: ^/head Repository Root: https://svn.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 296823 Node Kind: directory Schedule: normal Last Changed Author: adrian Last Changed Rev: 296823 Last Changed Date: 2016-03-13 23:39:35 -0500 (Sun, 13 Mar 2016) borg.lerctr.org /usr/src $ I can post the make.conf. It's really weird. Silly question your not building on an NFS FS are you? No, this is local disk. The "install from other machine" was via NFS.. I found it. A bad version (from march 8th or so) of /lib/libprivatessh.so.5 that did NOT export the symbol, but the version in /usr/lib/libprivatessh.so.5 DID export the symbol. I wiped out the /lib/libprivate* and re-did installworld. and all seems fine now. I suspect I hit a time when the tree had bad stuff installing into /lib/libprivate* BTW, there were LOTS of OTHER things in /lib with the same bad date, which I've now cleaned up. make delete-old{-libs} did *NOT* clean this up. These were dated March 8 2016? I don't recall any recent changes causing libraries to be installed to the wrong place. -- Regards, Bryan Drewery ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Crashes in libthr?
On 3/14/16 8:03 PM, Larry Rosenman wrote: > On 2016-03-14 21:49, Larry Rosenman wrote: >> On 2016-03-14 18:49, Larry Rosenman wrote: >>> On 2016-03-14 18:47, Steven Hartland wrote: On 14/03/2016 22:28, Larry Rosenman wrote: > On 2016-03-14 17:25, Poul-Henning Kamp wrote: >> >> In message <2016031428.ga1...@borg.lerctr.org>, Larry Rosenman >> writes: >> >>> And sshd is busted. >> >> FYI: I seeing no such issues on two systems running: >> >> 11.0-CURRENT #4 r296808: Sun Mar 13 22:39:59 UTC 2016 >> and >> 11.0-CURRENT #32 r296137: Sat Feb 27 11:34:01 UTC 2016 > As I said it's this ONE box, even doing an install from the other > (RUNNING) boxes > /usr/src,/usr/obj). > > This build was at: > borg.lerctr.org /usr/src $ svn info > Path: . > Working Copy Root Path: /usr/src > URL: https://svn.freebsd.org/base/head > Relative URL: ^/head > Repository Root: https://svn.freebsd.org/base > Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f > Revision: 296823 > Node Kind: directory > Schedule: normal > Last Changed Author: adrian > Last Changed Rev: 296823 > Last Changed Date: 2016-03-13 23:39:35 -0500 (Sun, 13 Mar 2016) > > borg.lerctr.org /usr/src $ > > > I can post the make.conf. > > It's really weird. Silly question your not building on an NFS FS are you? >>> No, this is local disk. The "install from other machine" was via >>> NFS.. >> >> >> I found it. A bad version (from march 8th or so) of >> /lib/libprivatessh.so.5 that did NOT export the symbol, but the >> version in /usr/lib/libprivatessh.so.5 DID export the symbol. >> >> I wiped out the /lib/libprivate* and re-did installworld. >> >> and all seems fine now. >> >> I suspect I hit a time when the tree had bad stuff installing into >> /lib/libprivate* > > > BTW, there were LOTS of OTHER things in /lib with the same bad date, > which I've now cleaned up. > > make delete-old{-libs} did *NOT* clean this up. > > These were dated March 8 2016? I don't recall any recent changes causing libraries to be installed to the wrong place. -- Regards, Bryan Drewery ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Crashes in libthr?
On 2016-03-14 21:49, Larry Rosenman wrote: On 2016-03-14 18:49, Larry Rosenman wrote: On 2016-03-14 18:47, Steven Hartland wrote: On 14/03/2016 22:28, Larry Rosenman wrote: On 2016-03-14 17:25, Poul-Henning Kamp wrote: In message <2016031428.ga1...@borg.lerctr.org>, Larry Rosenman writes: And sshd is busted. FYI: I seeing no such issues on two systems running: 11.0-CURRENT #4 r296808: Sun Mar 13 22:39:59 UTC 2016 and 11.0-CURRENT #32 r296137: Sat Feb 27 11:34:01 UTC 2016 As I said it's this ONE box, even doing an install from the other (RUNNING) boxes /usr/src,/usr/obj). This build was at: borg.lerctr.org /usr/src $ svn info Path: . Working Copy Root Path: /usr/src URL: https://svn.freebsd.org/base/head Relative URL: ^/head Repository Root: https://svn.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 296823 Node Kind: directory Schedule: normal Last Changed Author: adrian Last Changed Rev: 296823 Last Changed Date: 2016-03-13 23:39:35 -0500 (Sun, 13 Mar 2016) borg.lerctr.org /usr/src $ I can post the make.conf. It's really weird. Silly question your not building on an NFS FS are you? ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" No, this is local disk. The "install from other machine" was via NFS.. I found it. A bad version (from march 8th or so) of /lib/libprivatessh.so.5 that did NOT export the symbol, but the version in /usr/lib/libprivatessh.so.5 DID export the symbol. I wiped out the /lib/libprivate* and re-did installworld. and all seems fine now. I suspect I hit a time when the tree had bad stuff installing into /lib/libprivate* BTW, there were LOTS of OTHER things in /lib with the same bad date, which I've now cleaned up. make delete-old{-libs} did *NOT* clean this up. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: l...@lerctr.org US Mail: 7011 W Parmer Ln, Apt 1115, Austin, TX 78729-6961 ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Crashes in libthr?
On 2016-03-14 18:49, Larry Rosenman wrote: On 2016-03-14 18:47, Steven Hartland wrote: On 14/03/2016 22:28, Larry Rosenman wrote: On 2016-03-14 17:25, Poul-Henning Kamp wrote: In message <2016031428.ga1...@borg.lerctr.org>, Larry Rosenman writes: And sshd is busted. FYI: I seeing no such issues on two systems running: 11.0-CURRENT #4 r296808: Sun Mar 13 22:39:59 UTC 2016 and 11.0-CURRENT #32 r296137: Sat Feb 27 11:34:01 UTC 2016 As I said it's this ONE box, even doing an install from the other (RUNNING) boxes /usr/src,/usr/obj). This build was at: borg.lerctr.org /usr/src $ svn info Path: . Working Copy Root Path: /usr/src URL: https://svn.freebsd.org/base/head Relative URL: ^/head Repository Root: https://svn.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 296823 Node Kind: directory Schedule: normal Last Changed Author: adrian Last Changed Rev: 296823 Last Changed Date: 2016-03-13 23:39:35 -0500 (Sun, 13 Mar 2016) borg.lerctr.org /usr/src $ I can post the make.conf. It's really weird. Silly question your not building on an NFS FS are you? ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" No, this is local disk. The "install from other machine" was via NFS.. I found it. A bad version (from march 8th or so) of /lib/libprivatessh.so.5 that did NOT export the symbol, but the version in /usr/lib/libprivatessh.so.5 DID export the symbol. I wiped out the /lib/libprivate* and re-did installworld. and all seems fine now. I suspect I hit a time when the tree had bad stuff installing into /lib/libprivate* -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: l...@lerctr.org US Mail: 7011 W Parmer Ln, Apt 1115, Austin, TX 78729-6961 ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Crashes in libthr?
On 2016-03-14 18:47, Steven Hartland wrote: On 14/03/2016 22:28, Larry Rosenman wrote: On 2016-03-14 17:25, Poul-Henning Kamp wrote: In message <2016031428.ga1...@borg.lerctr.org>, Larry Rosenman writes: And sshd is busted. FYI: I seeing no such issues on two systems running: 11.0-CURRENT #4 r296808: Sun Mar 13 22:39:59 UTC 2016 and 11.0-CURRENT #32 r296137: Sat Feb 27 11:34:01 UTC 2016 As I said it's this ONE box, even doing an install from the other (RUNNING) boxes /usr/src,/usr/obj). This build was at: borg.lerctr.org /usr/src $ svn info Path: . Working Copy Root Path: /usr/src URL: https://svn.freebsd.org/base/head Relative URL: ^/head Repository Root: https://svn.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 296823 Node Kind: directory Schedule: normal Last Changed Author: adrian Last Changed Rev: 296823 Last Changed Date: 2016-03-13 23:39:35 -0500 (Sun, 13 Mar 2016) borg.lerctr.org /usr/src $ I can post the make.conf. It's really weird. Silly question your not building on an NFS FS are you? ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" No, this is local disk. The "install from other machine" was via NFS.. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: l...@lerctr.org US Mail: 7011 W Parmer Ln, Apt 1115, Austin, TX 78729-6961 ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Crashes in libthr?
On 14/03/2016 22:28, Larry Rosenman wrote: On 2016-03-14 17:25, Poul-Henning Kamp wrote: In message <2016031428.ga1...@borg.lerctr.org>, Larry Rosenman writes: And sshd is busted. FYI: I seeing no such issues on two systems running: 11.0-CURRENT #4 r296808: Sun Mar 13 22:39:59 UTC 2016 and 11.0-CURRENT #32 r296137: Sat Feb 27 11:34:01 UTC 2016 As I said it's this ONE box, even doing an install from the other (RUNNING) boxes /usr/src,/usr/obj). This build was at: borg.lerctr.org /usr/src $ svn info Path: . Working Copy Root Path: /usr/src URL: https://svn.freebsd.org/base/head Relative URL: ^/head Repository Root: https://svn.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 296823 Node Kind: directory Schedule: normal Last Changed Author: adrian Last Changed Rev: 296823 Last Changed Date: 2016-03-13 23:39:35 -0500 (Sun, 13 Mar 2016) borg.lerctr.org /usr/src $ I can post the make.conf. It's really weird. Silly question your not building on an NFS FS are you? ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Crashes in libthr?
On 2016-03-14 17:25, Poul-Henning Kamp wrote: In message <2016031428.ga1...@borg.lerctr.org>, Larry Rosenman writes: And sshd is busted. FYI: I seeing no such issues on two systems running: 11.0-CURRENT #4 r296808: Sun Mar 13 22:39:59 UTC 2016 and 11.0-CURRENT #32 r296137: Sat Feb 27 11:34:01 UTC 2016 As I said it's this ONE box, even doing an install from the other (RUNNING) boxes /usr/src,/usr/obj). This build was at: borg.lerctr.org /usr/src $ svn info Path: . Working Copy Root Path: /usr/src URL: https://svn.freebsd.org/base/head Relative URL: ^/head Repository Root: https://svn.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 296823 Node Kind: directory Schedule: normal Last Changed Author: adrian Last Changed Rev: 296823 Last Changed Date: 2016-03-13 23:39:35 -0500 (Sun, 13 Mar 2016) borg.lerctr.org /usr/src $ I can post the make.conf. It's really weird. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: l...@lerctr.org US Mail: 7011 W Parmer Ln, Apt 1115, Austin, TX 78729-6961 ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Crashes in libthr?
In message <2016031428.ga1...@borg.lerctr.org>, Larry Rosenman writes: >And sshd is busted. FYI: I seeing no such issues on two systems running: 11.0-CURRENT #4 r296808: Sun Mar 13 22:39:59 UTC 2016 and 11.0-CURRENT #32 r296137: Sat Feb 27 11:34:01 UTC 2016 -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Crashes in libthr?
On Tue, Mar 15, 2016 at 12:17:45AM +0200, Konstantin Belousov wrote: > On Mon, Mar 14, 2016 at 05:10:18PM -0500, Larry Rosenman wrote: > > There is something(tm) strange with sshd but nothing else at the moment. > > > > When I use the sshd from the build, I get: > > > > /usr/sbin/sshd.BAD: Undefined symbol "Fssh_ssh_malloc_init" > > > > But on a different box from the same build it works. > > > > Really weird. > > > > Ideas? > > > > (I've reverted to a known good sshd). > > On my stable/10 machines, the Fssh_ssh_malloc_init symbol is exported > by /usr/lib/private/libssh.so.5 and imported by sshd. > > OTOH on my HEAD machine, the symbol is not exported by > /usr/lib/libprivatessh.so.5 and sshd does not need it. > > I have no idea what happens to your build. Try to check out the pristine > sources, perhaps. I **DID** check out PRISTINE sources, cleaned out /usr/obj, moved /etc/{make,src}.conf out of the way, and did a single thread (no -j, no -DNO_CLEAN) build. And sshd is busted. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: l...@lerctr.org US Mail: 7011 W Parmer Ln, Apt 1115, Austin, TX 78729-6961 ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Crashes in libthr?
On Mon, Mar 14, 2016 at 05:10:18PM -0500, Larry Rosenman wrote: > There is something(tm) strange with sshd but nothing else at the moment. > > When I use the sshd from the build, I get: > > /usr/sbin/sshd.BAD: Undefined symbol "Fssh_ssh_malloc_init" > > But on a different box from the same build it works. > > Really weird. > > Ideas? > > (I've reverted to a known good sshd). On my stable/10 machines, the Fssh_ssh_malloc_init symbol is exported by /usr/lib/private/libssh.so.5 and imported by sshd. OTOH on my HEAD machine, the symbol is not exported by /usr/lib/libprivatessh.so.5 and sshd does not need it. I have no idea what happens to your build. Try to check out the pristine sources, perhaps. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Crashes in libthr?
On Mon, Mar 14, 2016 at 08:23:07AM -0500, Larry Rosenman wrote: > On 2016-03-14 01:53, Konstantin Belousov wrote: > > On Sun, Mar 13, 2016 at 09:51:25PM -0500, Larry Rosenman wrote: > >> I wound up restoring EVERYTHING from the latest snapshot memstick > >> image > >> and I still can't get a world built: > >> > >> attached is the make.out, from a clean /usr/obj, and latest /usr/src. > > What do you mean by clean obj, did you rm -rf usr/obj before the build > > ? > > zfs destroy/zfs create but essentially yes. > > > >> > >> ===> lib/clang/libclanganalysis (all) > >> clang-tblgen -gen-clang-attr-list -I > >> /usr/src/lib/clang/libclanganalysis/../../../contrib/llvm/tools/clang/include > >> > >> -d AttrList.inc.d -o AttrList.inc.h > >> /usr/src/lib/clang/libclanganalysis/../../../contrib/llvm/tools/clang/include/clang/Basic/Attr.td > >> *** Signal 11 > >> > >> Stop. > >> make[4]: stopped in /usr/src/lib/clang/libclanganalysis > >> *** Error code 1 > > Which binary faulted ? Try to load it into the debugger. > > > > Also, you could put DEBUG_FLAGS=-g into make.conf and build, but I am > > not > > sure if the setting is effective during all buildworld stages, > > including > > the earliest. > > > > BTW, do you have anything in make.conf or src.conf ? > > What if you build on some other system ? > I installed from another system, and all seemed fine EXCEPT for sshd > whining about Fssh_ssh_malloc_init not found > which I find weird. > > I did have stuff in /etc/{make,src}.conf, so I removed them, and pulled > a fresh checkout, and > zfs destroy/create /usr/obj. > > running a single-thread build, that's still running. I'll see what that > looks like when I get home > from work this evening. > > Really strange. > > There is something(tm) strange with sshd but nothing else at the moment. When I use the sshd from the build, I get: /usr/sbin/sshd.BAD: Undefined symbol "Fssh_ssh_malloc_init" But on a different box from the same build it works. Really weird. Ideas? (I've reverted to a known good sshd). -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: l...@lerctr.org US Mail: 7011 W Parmer Ln, Apt 1115, Austin, TX 78729-6961 ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Crashes in libthr?
On 2016-03-14 01:53, Konstantin Belousov wrote: On Sun, Mar 13, 2016 at 09:51:25PM -0500, Larry Rosenman wrote: I wound up restoring EVERYTHING from the latest snapshot memstick image and I still can't get a world built: attached is the make.out, from a clean /usr/obj, and latest /usr/src. What do you mean by clean obj, did you rm -rf usr/obj before the build ? zfs destroy/zfs create but essentially yes. ===> lib/clang/libclanganalysis (all) clang-tblgen -gen-clang-attr-list -I /usr/src/lib/clang/libclanganalysis/../../../contrib/llvm/tools/clang/include -d AttrList.inc.d -o AttrList.inc.h /usr/src/lib/clang/libclanganalysis/../../../contrib/llvm/tools/clang/include/clang/Basic/Attr.td *** Signal 11 Stop. make[4]: stopped in /usr/src/lib/clang/libclanganalysis *** Error code 1 Which binary faulted ? Try to load it into the debugger. Also, you could put DEBUG_FLAGS=-g into make.conf and build, but I am not sure if the setting is effective during all buildworld stages, including the earliest. BTW, do you have anything in make.conf or src.conf ? What if you build on some other system ? I installed from another system, and all seemed fine EXCEPT for sshd whining about Fssh_ssh_malloc_init not found which I find weird. I did have stuff in /etc/{make,src}.conf, so I removed them, and pulled a fresh checkout, and zfs destroy/create /usr/obj. running a single-thread build, that's still running. I'll see what that looks like when I get home from work this evening. Really strange. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: l...@lerctr.org US Mail: 7011 W Parmer Ln, Apt 1115, Austin, TX 78729-6961 ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Crashes in libthr?
On Sun, Mar 13, 2016 at 09:51:25PM -0500, Larry Rosenman wrote: > I wound up restoring EVERYTHING from the latest snapshot memstick image > and I still can't get a world built: > > attached is the make.out, from a clean /usr/obj, and latest /usr/src. What do you mean by clean obj, did you rm -rf usr/obj before the build ? > > ===> lib/clang/libclanganalysis (all) > clang-tblgen -gen-clang-attr-list -I > /usr/src/lib/clang/libclanganalysis/../../../contrib/llvm/tools/clang/include > -d AttrList.inc.d -o AttrList.inc.h > /usr/src/lib/clang/libclanganalysis/../../../contrib/llvm/tools/clang/include/clang/Basic/Attr.td > *** Signal 11 > > Stop. > make[4]: stopped in /usr/src/lib/clang/libclanganalysis > *** Error code 1 Which binary faulted ? Try to load it into the debugger. Also, you could put DEBUG_FLAGS=-g into make.conf and build, but I am not sure if the setting is effective during all buildworld stages, including the earliest. BTW, do you have anything in make.conf or src.conf ? What if you build on some other system ? ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Crashes in libthr?
On Sun, Mar 13, 2016 at 09:51:23PM -0500, Larry Rosenman wrote: > On Sun, Mar 13, 2016 at 07:03:53PM -0500, Larry Rosenman wrote: > > On 2016-03-13 14:29, Konstantin Belousov wrote: > > > On Sun, Mar 13, 2016 at 02:10:58PM -0500, Larry Rosenman wrote: > > >> On 2016-03-13 13:58, Konstantin Belousov wrote: > > >> > On Sun, Mar 13, 2016 at 01:32:20PM -0500, Larry Rosenman wrote: > > >> >> On 2016-03-13 13:12, Konstantin Belousov wrote: > > >> >> > On Sun, Mar 13, 2016 at 11:16:20AM -0500, Larry Rosenman wrote: > > >> >> >> I updated one of my servers, and WHILE DOING THE INSTALLWORLD, I > > >> >> >> get > > >> >> >> segfaults. > > >> >> >> > > >> >> >> ANY multithreaded program crashes. > > >> >> >> > > >> >> >> I reverted libthr, and it's fine. > > >> >> >> > > >> >> >> borg.lerctr.org / # gdb -c zfs.core /sbin/zfs > > >> >> >> GNU gdb 6.1.1 [FreeBSD] > > >> >> >> Copyright 2004 Free Software Foundation, Inc. > > >> >> >> GDB is free software, covered by the GNU General Public License, > > >> >> >> and > > >> >> >> you > > >> >> >> are > > >> >> >> welcome to change it and/or distribute copies of it under certain > > >> >> >> conditions. > > >> >> >> Type "show copying" to see the conditions. > > >> >> >> There is absolutely no warranty for GDB. Type "show warranty" for > > >> >> >> details. > > >> >> >> This GDB was configured as "amd64-marcel-freebsd"... > > >> >> >> Core was generated by `zfs'. > > >> >> >> Program terminated with signal 11, Segmentation fault. > > >> >> >> Reading symbols from /lib/libjail.so.1...Reading symbols from > > >> >> >> /usr/lib/debug//lib/libjail.so.1.debug...done. > > >> >> >> done. > > >> >> >> Loaded symbols for /lib/libjail.so.1 > > >> >> >> Reading symbols from /lib/libnvpair.so.2...Reading symbols from > > >> >> >> /usr/lib/debug//lib/libnvpair.so.2.debug...done. > > >> >> >> done. > > >> >> >> Loaded symbols for /lib/libnvpair.so.2 > > >> >> >> Reading symbols from /lib/libuutil.so.2...Reading symbols from > > >> >> >> /usr/lib/debug//lib/libuutil.so.2.debug...done. > > >> >> >> done. > > >> >> >> Loaded symbols for /lib/libuutil.so.2 > > >> >> >> Reading symbols from /lib/libzfs_core.so.2...Reading symbols from > > >> >> >> /usr/lib/debug//lib/libzfs_core.so.2.debug...done. > > >> >> >> done. > > >> >> >> Loaded symbols for /lib/libzfs_core.so.2 > > >> >> >> Reading symbols from /lib/libzfs.so.2...Reading symbols from > > >> >> >> /usr/lib/debug//lib/libzfs.so.2.debug...done. > > >> >> >> done. > > >> >> >> Loaded symbols for /lib/libzfs.so.2 > > >> >> >> Reading symbols from /lib/libc.so.7...Reading symbols from > > >> >> >> /usr/lib/debug//lib/libc.so.7.debug...done. > > >> >> >> done. > > >> >> >> Loaded symbols for /lib/libc.so.7 > > >> >> >> Reading symbols from /lib/libmd.so.6...Reading symbols from > > >> >> >> /usr/lib/debug//lib/libmd.so.6.debug...done. > > >> >> >> done. > > >> >> >> Loaded symbols for /lib/libmd.so.6 > > >> >> >> Reading symbols from /lib/libumem.so.2...Reading symbols from > > >> >> >> /usr/lib/debug//lib/libumem.so.2.debug...done. > > >> >> >> done. > > >> >> >> Loaded symbols for /lib/libumem.so.2 > > >> >> >> Reading symbols from /lib/libutil.so.9...Reading symbols from > > >> >> >> /usr/lib/debug//lib/libutil.so.9.debug...done. > > >> >> >> done. > > >> >> >> Loaded symbols for /lib/libutil.so.9 > > >> >> >> Reading symbols from /lib/libm.so.5...Reading symbols from > > >> >> >> /usr/lib/debug//lib/libm.so.5.debug...done. > > >> >> >> done. > > >> >> >> Loaded symbols for /lib/libm.so.5 > > >> >> >> Reading symbols from /lib/libavl.so.2...Reading symbols from > > >> >> >> /usr/lib/debug//lib/libavl.so.2.debug...done. > > >> >> >> done. > > >> >> >> Loaded symbols for /lib/libavl.so.2 > > >> >> >> Reading symbols from /lib/libbsdxml.so.4...Reading symbols from > > >> >> >> /usr/lib/debug//lib/libbsdxml.so.4.debug...done. > > >> >> >> done. > > >> >> >> Loaded symbols for /lib/libbsdxml.so.4 > > >> >> >> Reading symbols from /lib/libgeom.so.5...Reading symbols from > > >> >> >> /usr/lib/debug//lib/libgeom.so.5.debug...done. > > >> >> >> done. > > >> >> >> Loaded symbols for /lib/libgeom.so.5 > > >> >> >> Reading symbols from /lib/libz.so.6...Reading symbols from > > >> >> >> /usr/lib/debug//lib/libz.so.6.debug...done. > > >> >> >> done. > > >> >> >> Loaded symbols for /lib/libz.so.6 > > >> >> >> Reading symbols from /lib/libthr.so.3...done. > > >> >> >> Loaded symbols for /lib/libthr.so.3 > > >> >> > Why all libs have debug symbols, while your most interesting one, > > >> >> > libthr.so.3, does not ? > > >> >> > > > >> >> >> Reading symbols from /lib/libsbuf.so.6...Reading symbols from > > >> >> >> /usr/lib/debug//lib/libsbuf.so.6.debug...done. > > >> >> >> done. > > >> >> >> Loaded symbols for /lib/libsbuf.so.6 > > >> >> >> Reading symbols from /libexec/ld-elf.so.1...done. > > >> >> >> Loaded symbols for /libexec/ld-elf.so.1 > > >> >> >> #0 0x000802703f81 in __pthread_cxa_finalize () from > > >> >> >> /lib/libthr.so.3 > > >> >>
Re: Crashes in libthr?
On 2016-03-13 14:29, Konstantin Belousov wrote: On Sun, Mar 13, 2016 at 02:10:58PM -0500, Larry Rosenman wrote: On 2016-03-13 13:58, Konstantin Belousov wrote: > On Sun, Mar 13, 2016 at 01:32:20PM -0500, Larry Rosenman wrote: >> On 2016-03-13 13:12, Konstantin Belousov wrote: >> > On Sun, Mar 13, 2016 at 11:16:20AM -0500, Larry Rosenman wrote: >> >> I updated one of my servers, and WHILE DOING THE INSTALLWORLD, I get >> >> segfaults. >> >> >> >> ANY multithreaded program crashes. >> >> >> >> I reverted libthr, and it's fine. >> >> >> >> borg.lerctr.org / # gdb -c zfs.core /sbin/zfs >> >> GNU gdb 6.1.1 [FreeBSD] >> >> Copyright 2004 Free Software Foundation, Inc. >> >> GDB is free software, covered by the GNU General Public License, and >> >> you >> >> are >> >> welcome to change it and/or distribute copies of it under certain >> >> conditions. >> >> Type "show copying" to see the conditions. >> >> There is absolutely no warranty for GDB. Type "show warranty" for >> >> details. >> >> This GDB was configured as "amd64-marcel-freebsd"... >> >> Core was generated by `zfs'. >> >> Program terminated with signal 11, Segmentation fault. >> >> Reading symbols from /lib/libjail.so.1...Reading symbols from >> >> /usr/lib/debug//lib/libjail.so.1.debug...done. >> >> done. >> >> Loaded symbols for /lib/libjail.so.1 >> >> Reading symbols from /lib/libnvpair.so.2...Reading symbols from >> >> /usr/lib/debug//lib/libnvpair.so.2.debug...done. >> >> done. >> >> Loaded symbols for /lib/libnvpair.so.2 >> >> Reading symbols from /lib/libuutil.so.2...Reading symbols from >> >> /usr/lib/debug//lib/libuutil.so.2.debug...done. >> >> done. >> >> Loaded symbols for /lib/libuutil.so.2 >> >> Reading symbols from /lib/libzfs_core.so.2...Reading symbols from >> >> /usr/lib/debug//lib/libzfs_core.so.2.debug...done. >> >> done. >> >> Loaded symbols for /lib/libzfs_core.so.2 >> >> Reading symbols from /lib/libzfs.so.2...Reading symbols from >> >> /usr/lib/debug//lib/libzfs.so.2.debug...done. >> >> done. >> >> Loaded symbols for /lib/libzfs.so.2 >> >> Reading symbols from /lib/libc.so.7...Reading symbols from >> >> /usr/lib/debug//lib/libc.so.7.debug...done. >> >> done. >> >> Loaded symbols for /lib/libc.so.7 >> >> Reading symbols from /lib/libmd.so.6...Reading symbols from >> >> /usr/lib/debug//lib/libmd.so.6.debug...done. >> >> done. >> >> Loaded symbols for /lib/libmd.so.6 >> >> Reading symbols from /lib/libumem.so.2...Reading symbols from >> >> /usr/lib/debug//lib/libumem.so.2.debug...done. >> >> done. >> >> Loaded symbols for /lib/libumem.so.2 >> >> Reading symbols from /lib/libutil.so.9...Reading symbols from >> >> /usr/lib/debug//lib/libutil.so.9.debug...done. >> >> done. >> >> Loaded symbols for /lib/libutil.so.9 >> >> Reading symbols from /lib/libm.so.5...Reading symbols from >> >> /usr/lib/debug//lib/libm.so.5.debug...done. >> >> done. >> >> Loaded symbols for /lib/libm.so.5 >> >> Reading symbols from /lib/libavl.so.2...Reading symbols from >> >> /usr/lib/debug//lib/libavl.so.2.debug...done. >> >> done. >> >> Loaded symbols for /lib/libavl.so.2 >> >> Reading symbols from /lib/libbsdxml.so.4...Reading symbols from >> >> /usr/lib/debug//lib/libbsdxml.so.4.debug...done. >> >> done. >> >> Loaded symbols for /lib/libbsdxml.so.4 >> >> Reading symbols from /lib/libgeom.so.5...Reading symbols from >> >> /usr/lib/debug//lib/libgeom.so.5.debug...done. >> >> done. >> >> Loaded symbols for /lib/libgeom.so.5 >> >> Reading symbols from /lib/libz.so.6...Reading symbols from >> >> /usr/lib/debug//lib/libz.so.6.debug...done. >> >> done. >> >> Loaded symbols for /lib/libz.so.6 >> >> Reading symbols from /lib/libthr.so.3...done. >> >> Loaded symbols for /lib/libthr.so.3 >> > Why all libs have debug symbols, while your most interesting one, >> > libthr.so.3, does not ? >> > >> >> Reading symbols from /lib/libsbuf.so.6...Reading symbols from >> >> /usr/lib/debug//lib/libsbuf.so.6.debug...done. >> >> done. >> >> Loaded symbols for /lib/libsbuf.so.6 >> >> Reading symbols from /libexec/ld-elf.so.1...done. >> >> Loaded symbols for /libexec/ld-elf.so.1 >> >> #0 0x000802703f81 in __pthread_cxa_finalize () from >> >> /lib/libthr.so.3 >> >> [New LWP 100957] >> >> (gdb) bt >> >> #0 0x000802703f81 in __pthread_cxa_finalize () from >> >> /lib/libthr.so.3 >> >> #1 0x000802703e85 in __pthread_cxa_finalize () from >> >> /lib/libthr.so.3 >> >> #2 0x000802707052 in ?? () from /lib/libthr.so.3 >> >> #3 0x00080063fc00 in ?? () >> >> #4 0x7fffe638 in ?? () >> >> #5 0x7fffe5b0 in ?? () >> >> #6 0x0008026f8fd6 in atoi@plt () from /lib/libthr.so.3 >> >> #7 0x7fffe5b0 in ?? () >> >> #8 0x00080061adfd in r_debug_state () from /libexec/ld-elf.so.1 >> >> Previous frame inner to this frame (corrupt stack?) >> >> (gdb) >> >> >> >> old SVN: r296103 >> >> new SVN: r296796M >> >> (The M is a nd6 patch from markj@) >> >> >> >> this was a FULL buildworld/buildkernel. >> > >> > If you cd lib/libthr and do >> > make clea
Re: Crashes in libthr?
On Sun, Mar 13, 2016 at 02:10:58PM -0500, Larry Rosenman wrote: > On 2016-03-13 13:58, Konstantin Belousov wrote: > > On Sun, Mar 13, 2016 at 01:32:20PM -0500, Larry Rosenman wrote: > >> On 2016-03-13 13:12, Konstantin Belousov wrote: > >> > On Sun, Mar 13, 2016 at 11:16:20AM -0500, Larry Rosenman wrote: > >> >> I updated one of my servers, and WHILE DOING THE INSTALLWORLD, I get > >> >> segfaults. > >> >> > >> >> ANY multithreaded program crashes. > >> >> > >> >> I reverted libthr, and it's fine. > >> >> > >> >> borg.lerctr.org / # gdb -c zfs.core /sbin/zfs > >> >> GNU gdb 6.1.1 [FreeBSD] > >> >> Copyright 2004 Free Software Foundation, Inc. > >> >> GDB is free software, covered by the GNU General Public License, and > >> >> you > >> >> are > >> >> welcome to change it and/or distribute copies of it under certain > >> >> conditions. > >> >> Type "show copying" to see the conditions. > >> >> There is absolutely no warranty for GDB. Type "show warranty" for > >> >> details. > >> >> This GDB was configured as "amd64-marcel-freebsd"... > >> >> Core was generated by `zfs'. > >> >> Program terminated with signal 11, Segmentation fault. > >> >> Reading symbols from /lib/libjail.so.1...Reading symbols from > >> >> /usr/lib/debug//lib/libjail.so.1.debug...done. > >> >> done. > >> >> Loaded symbols for /lib/libjail.so.1 > >> >> Reading symbols from /lib/libnvpair.so.2...Reading symbols from > >> >> /usr/lib/debug//lib/libnvpair.so.2.debug...done. > >> >> done. > >> >> Loaded symbols for /lib/libnvpair.so.2 > >> >> Reading symbols from /lib/libuutil.so.2...Reading symbols from > >> >> /usr/lib/debug//lib/libuutil.so.2.debug...done. > >> >> done. > >> >> Loaded symbols for /lib/libuutil.so.2 > >> >> Reading symbols from /lib/libzfs_core.so.2...Reading symbols from > >> >> /usr/lib/debug//lib/libzfs_core.so.2.debug...done. > >> >> done. > >> >> Loaded symbols for /lib/libzfs_core.so.2 > >> >> Reading symbols from /lib/libzfs.so.2...Reading symbols from > >> >> /usr/lib/debug//lib/libzfs.so.2.debug...done. > >> >> done. > >> >> Loaded symbols for /lib/libzfs.so.2 > >> >> Reading symbols from /lib/libc.so.7...Reading symbols from > >> >> /usr/lib/debug//lib/libc.so.7.debug...done. > >> >> done. > >> >> Loaded symbols for /lib/libc.so.7 > >> >> Reading symbols from /lib/libmd.so.6...Reading symbols from > >> >> /usr/lib/debug//lib/libmd.so.6.debug...done. > >> >> done. > >> >> Loaded symbols for /lib/libmd.so.6 > >> >> Reading symbols from /lib/libumem.so.2...Reading symbols from > >> >> /usr/lib/debug//lib/libumem.so.2.debug...done. > >> >> done. > >> >> Loaded symbols for /lib/libumem.so.2 > >> >> Reading symbols from /lib/libutil.so.9...Reading symbols from > >> >> /usr/lib/debug//lib/libutil.so.9.debug...done. > >> >> done. > >> >> Loaded symbols for /lib/libutil.so.9 > >> >> Reading symbols from /lib/libm.so.5...Reading symbols from > >> >> /usr/lib/debug//lib/libm.so.5.debug...done. > >> >> done. > >> >> Loaded symbols for /lib/libm.so.5 > >> >> Reading symbols from /lib/libavl.so.2...Reading symbols from > >> >> /usr/lib/debug//lib/libavl.so.2.debug...done. > >> >> done. > >> >> Loaded symbols for /lib/libavl.so.2 > >> >> Reading symbols from /lib/libbsdxml.so.4...Reading symbols from > >> >> /usr/lib/debug//lib/libbsdxml.so.4.debug...done. > >> >> done. > >> >> Loaded symbols for /lib/libbsdxml.so.4 > >> >> Reading symbols from /lib/libgeom.so.5...Reading symbols from > >> >> /usr/lib/debug//lib/libgeom.so.5.debug...done. > >> >> done. > >> >> Loaded symbols for /lib/libgeom.so.5 > >> >> Reading symbols from /lib/libz.so.6...Reading symbols from > >> >> /usr/lib/debug//lib/libz.so.6.debug...done. > >> >> done. > >> >> Loaded symbols for /lib/libz.so.6 > >> >> Reading symbols from /lib/libthr.so.3...done. > >> >> Loaded symbols for /lib/libthr.so.3 > >> > Why all libs have debug symbols, while your most interesting one, > >> > libthr.so.3, does not ? > >> > > >> >> Reading symbols from /lib/libsbuf.so.6...Reading symbols from > >> >> /usr/lib/debug//lib/libsbuf.so.6.debug...done. > >> >> done. > >> >> Loaded symbols for /lib/libsbuf.so.6 > >> >> Reading symbols from /libexec/ld-elf.so.1...done. > >> >> Loaded symbols for /libexec/ld-elf.so.1 > >> >> #0 0x000802703f81 in __pthread_cxa_finalize () from > >> >> /lib/libthr.so.3 > >> >> [New LWP 100957] > >> >> (gdb) bt > >> >> #0 0x000802703f81 in __pthread_cxa_finalize () from > >> >> /lib/libthr.so.3 > >> >> #1 0x000802703e85 in __pthread_cxa_finalize () from > >> >> /lib/libthr.so.3 > >> >> #2 0x000802707052 in ?? () from /lib/libthr.so.3 > >> >> #3 0x00080063fc00 in ?? () > >> >> #4 0x7fffe638 in ?? () > >> >> #5 0x7fffe5b0 in ?? () > >> >> #6 0x0008026f8fd6 in atoi@plt () from /lib/libthr.so.3 > >> >> #7 0x7fffe5b0 in ?? () > >> >> #8 0x00080061adfd in r_debug_state () from /libexec/ld-elf.so.1 > >> >> Previous frame inner to this frame (corrupt stack?) > >> >> (gdb) > >> >> > >> >> old SVN: r296103
Re: Crashes in libthr?
On 2016-03-13 13:58, Konstantin Belousov wrote: On Sun, Mar 13, 2016 at 01:32:20PM -0500, Larry Rosenman wrote: On 2016-03-13 13:12, Konstantin Belousov wrote: > On Sun, Mar 13, 2016 at 11:16:20AM -0500, Larry Rosenman wrote: >> I updated one of my servers, and WHILE DOING THE INSTALLWORLD, I get >> segfaults. >> >> ANY multithreaded program crashes. >> >> I reverted libthr, and it's fine. >> >> borg.lerctr.org / # gdb -c zfs.core /sbin/zfs >> GNU gdb 6.1.1 [FreeBSD] >> Copyright 2004 Free Software Foundation, Inc. >> GDB is free software, covered by the GNU General Public License, and >> you >> are >> welcome to change it and/or distribute copies of it under certain >> conditions. >> Type "show copying" to see the conditions. >> There is absolutely no warranty for GDB. Type "show warranty" for >> details. >> This GDB was configured as "amd64-marcel-freebsd"... >> Core was generated by `zfs'. >> Program terminated with signal 11, Segmentation fault. >> Reading symbols from /lib/libjail.so.1...Reading symbols from >> /usr/lib/debug//lib/libjail.so.1.debug...done. >> done. >> Loaded symbols for /lib/libjail.so.1 >> Reading symbols from /lib/libnvpair.so.2...Reading symbols from >> /usr/lib/debug//lib/libnvpair.so.2.debug...done. >> done. >> Loaded symbols for /lib/libnvpair.so.2 >> Reading symbols from /lib/libuutil.so.2...Reading symbols from >> /usr/lib/debug//lib/libuutil.so.2.debug...done. >> done. >> Loaded symbols for /lib/libuutil.so.2 >> Reading symbols from /lib/libzfs_core.so.2...Reading symbols from >> /usr/lib/debug//lib/libzfs_core.so.2.debug...done. >> done. >> Loaded symbols for /lib/libzfs_core.so.2 >> Reading symbols from /lib/libzfs.so.2...Reading symbols from >> /usr/lib/debug//lib/libzfs.so.2.debug...done. >> done. >> Loaded symbols for /lib/libzfs.so.2 >> Reading symbols from /lib/libc.so.7...Reading symbols from >> /usr/lib/debug//lib/libc.so.7.debug...done. >> done. >> Loaded symbols for /lib/libc.so.7 >> Reading symbols from /lib/libmd.so.6...Reading symbols from >> /usr/lib/debug//lib/libmd.so.6.debug...done. >> done. >> Loaded symbols for /lib/libmd.so.6 >> Reading symbols from /lib/libumem.so.2...Reading symbols from >> /usr/lib/debug//lib/libumem.so.2.debug...done. >> done. >> Loaded symbols for /lib/libumem.so.2 >> Reading symbols from /lib/libutil.so.9...Reading symbols from >> /usr/lib/debug//lib/libutil.so.9.debug...done. >> done. >> Loaded symbols for /lib/libutil.so.9 >> Reading symbols from /lib/libm.so.5...Reading symbols from >> /usr/lib/debug//lib/libm.so.5.debug...done. >> done. >> Loaded symbols for /lib/libm.so.5 >> Reading symbols from /lib/libavl.so.2...Reading symbols from >> /usr/lib/debug//lib/libavl.so.2.debug...done. >> done. >> Loaded symbols for /lib/libavl.so.2 >> Reading symbols from /lib/libbsdxml.so.4...Reading symbols from >> /usr/lib/debug//lib/libbsdxml.so.4.debug...done. >> done. >> Loaded symbols for /lib/libbsdxml.so.4 >> Reading symbols from /lib/libgeom.so.5...Reading symbols from >> /usr/lib/debug//lib/libgeom.so.5.debug...done. >> done. >> Loaded symbols for /lib/libgeom.so.5 >> Reading symbols from /lib/libz.so.6...Reading symbols from >> /usr/lib/debug//lib/libz.so.6.debug...done. >> done. >> Loaded symbols for /lib/libz.so.6 >> Reading symbols from /lib/libthr.so.3...done. >> Loaded symbols for /lib/libthr.so.3 > Why all libs have debug symbols, while your most interesting one, > libthr.so.3, does not ? > >> Reading symbols from /lib/libsbuf.so.6...Reading symbols from >> /usr/lib/debug//lib/libsbuf.so.6.debug...done. >> done. >> Loaded symbols for /lib/libsbuf.so.6 >> Reading symbols from /libexec/ld-elf.so.1...done. >> Loaded symbols for /libexec/ld-elf.so.1 >> #0 0x000802703f81 in __pthread_cxa_finalize () from >> /lib/libthr.so.3 >> [New LWP 100957] >> (gdb) bt >> #0 0x000802703f81 in __pthread_cxa_finalize () from >> /lib/libthr.so.3 >> #1 0x000802703e85 in __pthread_cxa_finalize () from >> /lib/libthr.so.3 >> #2 0x000802707052 in ?? () from /lib/libthr.so.3 >> #3 0x00080063fc00 in ?? () >> #4 0x7fffe638 in ?? () >> #5 0x7fffe5b0 in ?? () >> #6 0x0008026f8fd6 in atoi@plt () from /lib/libthr.so.3 >> #7 0x7fffe5b0 in ?? () >> #8 0x00080061adfd in r_debug_state () from /libexec/ld-elf.so.1 >> Previous frame inner to this frame (corrupt stack?) >> (gdb) >> >> old SVN: r296103 >> new SVN: r296796M >> (The M is a nd6 patch from markj@) >> >> this was a FULL buildworld/buildkernel. > > If you cd lib/libthr and do >make clean all install DEBUG_FLAGS=-g > on the broken world, does it fix the problem ? If not, do debugging > symbols from libthr appear accessible to gdb at least ? Try this to > get useful backtrace with source lines information. ar crashes linking the library.. ar does not link library, it archives .o into .a archive. That said, neither ar nor ld (I am not sure whether 'ar' or 'linking' is a thinko in the sentence above) do not depend on libthr. You have
Re: Crashes in libthr?
On 2016-03-13 13:12, Konstantin Belousov wrote: On Sun, Mar 13, 2016 at 11:16:20AM -0500, Larry Rosenman wrote: I updated one of my servers, and WHILE DOING THE INSTALLWORLD, I get segfaults. ANY multithreaded program crashes. I reverted libthr, and it's fine. borg.lerctr.org / # gdb -c zfs.core /sbin/zfs GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... Core was generated by `zfs'. Program terminated with signal 11, Segmentation fault. Reading symbols from /lib/libjail.so.1...Reading symbols from /usr/lib/debug//lib/libjail.so.1.debug...done. done. Loaded symbols for /lib/libjail.so.1 Reading symbols from /lib/libnvpair.so.2...Reading symbols from /usr/lib/debug//lib/libnvpair.so.2.debug...done. done. Loaded symbols for /lib/libnvpair.so.2 Reading symbols from /lib/libuutil.so.2...Reading symbols from /usr/lib/debug//lib/libuutil.so.2.debug...done. done. Loaded symbols for /lib/libuutil.so.2 Reading symbols from /lib/libzfs_core.so.2...Reading symbols from /usr/lib/debug//lib/libzfs_core.so.2.debug...done. done. Loaded symbols for /lib/libzfs_core.so.2 Reading symbols from /lib/libzfs.so.2...Reading symbols from /usr/lib/debug//lib/libzfs.so.2.debug...done. done. Loaded symbols for /lib/libzfs.so.2 Reading symbols from /lib/libc.so.7...Reading symbols from /usr/lib/debug//lib/libc.so.7.debug...done. done. Loaded symbols for /lib/libc.so.7 Reading symbols from /lib/libmd.so.6...Reading symbols from /usr/lib/debug//lib/libmd.so.6.debug...done. done. Loaded symbols for /lib/libmd.so.6 Reading symbols from /lib/libumem.so.2...Reading symbols from /usr/lib/debug//lib/libumem.so.2.debug...done. done. Loaded symbols for /lib/libumem.so.2 Reading symbols from /lib/libutil.so.9...Reading symbols from /usr/lib/debug//lib/libutil.so.9.debug...done. done. Loaded symbols for /lib/libutil.so.9 Reading symbols from /lib/libm.so.5...Reading symbols from /usr/lib/debug//lib/libm.so.5.debug...done. done. Loaded symbols for /lib/libm.so.5 Reading symbols from /lib/libavl.so.2...Reading symbols from /usr/lib/debug//lib/libavl.so.2.debug...done. done. Loaded symbols for /lib/libavl.so.2 Reading symbols from /lib/libbsdxml.so.4...Reading symbols from /usr/lib/debug//lib/libbsdxml.so.4.debug...done. done. Loaded symbols for /lib/libbsdxml.so.4 Reading symbols from /lib/libgeom.so.5...Reading symbols from /usr/lib/debug//lib/libgeom.so.5.debug...done. done. Loaded symbols for /lib/libgeom.so.5 Reading symbols from /lib/libz.so.6...Reading symbols from /usr/lib/debug//lib/libz.so.6.debug...done. done. Loaded symbols for /lib/libz.so.6 Reading symbols from /lib/libthr.so.3...done. Loaded symbols for /lib/libthr.so.3 Why all libs have debug symbols, while your most interesting one, libthr.so.3, does not ? Reading symbols from /lib/libsbuf.so.6...Reading symbols from /usr/lib/debug//lib/libsbuf.so.6.debug...done. done. Loaded symbols for /lib/libsbuf.so.6 Reading symbols from /libexec/ld-elf.so.1...done. Loaded symbols for /libexec/ld-elf.so.1 #0 0x000802703f81 in __pthread_cxa_finalize () from /lib/libthr.so.3 [New LWP 100957] (gdb) bt #0 0x000802703f81 in __pthread_cxa_finalize () from /lib/libthr.so.3 #1 0x000802703e85 in __pthread_cxa_finalize () from /lib/libthr.so.3 #2 0x000802707052 in ?? () from /lib/libthr.so.3 #3 0x00080063fc00 in ?? () #4 0x7fffe638 in ?? () #5 0x7fffe5b0 in ?? () #6 0x0008026f8fd6 in atoi@plt () from /lib/libthr.so.3 #7 0x7fffe5b0 in ?? () #8 0x00080061adfd in r_debug_state () from /libexec/ld-elf.so.1 Previous frame inner to this frame (corrupt stack?) (gdb) old SVN: r296103 new SVN: r296796M (The M is a nd6 patch from markj@) this was a FULL buildworld/buildkernel. If you cd lib/libthr and do make clean all install DEBUG_FLAGS=-g on the broken world, does it fix the problem ? If not, do debugging symbols from libthr appear accessible to gdb at least ? Try this to get useful backtrace with source lines information. ar crashes linking the library.. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: l...@lerctr.org US Mail: 7011 W Parmer Ln, Apt 1115, Austin, TX 78729-6961 ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Crashes in libthr?
On 2016-03-13 13:12, Konstantin Belousov wrote: On Sun, Mar 13, 2016 at 11:16:20AM -0500, Larry Rosenman wrote: I updated one of my servers, and WHILE DOING THE INSTALLWORLD, I get segfaults. ANY multithreaded program crashes. I reverted libthr, and it's fine. borg.lerctr.org / # gdb -c zfs.core /sbin/zfs GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... Core was generated by `zfs'. Program terminated with signal 11, Segmentation fault. Reading symbols from /lib/libjail.so.1...Reading symbols from /usr/lib/debug//lib/libjail.so.1.debug...done. done. Loaded symbols for /lib/libjail.so.1 Reading symbols from /lib/libnvpair.so.2...Reading symbols from /usr/lib/debug//lib/libnvpair.so.2.debug...done. done. Loaded symbols for /lib/libnvpair.so.2 Reading symbols from /lib/libuutil.so.2...Reading symbols from /usr/lib/debug//lib/libuutil.so.2.debug...done. done. Loaded symbols for /lib/libuutil.so.2 Reading symbols from /lib/libzfs_core.so.2...Reading symbols from /usr/lib/debug//lib/libzfs_core.so.2.debug...done. done. Loaded symbols for /lib/libzfs_core.so.2 Reading symbols from /lib/libzfs.so.2...Reading symbols from /usr/lib/debug//lib/libzfs.so.2.debug...done. done. Loaded symbols for /lib/libzfs.so.2 Reading symbols from /lib/libc.so.7...Reading symbols from /usr/lib/debug//lib/libc.so.7.debug...done. done. Loaded symbols for /lib/libc.so.7 Reading symbols from /lib/libmd.so.6...Reading symbols from /usr/lib/debug//lib/libmd.so.6.debug...done. done. Loaded symbols for /lib/libmd.so.6 Reading symbols from /lib/libumem.so.2...Reading symbols from /usr/lib/debug//lib/libumem.so.2.debug...done. done. Loaded symbols for /lib/libumem.so.2 Reading symbols from /lib/libutil.so.9...Reading symbols from /usr/lib/debug//lib/libutil.so.9.debug...done. done. Loaded symbols for /lib/libutil.so.9 Reading symbols from /lib/libm.so.5...Reading symbols from /usr/lib/debug//lib/libm.so.5.debug...done. done. Loaded symbols for /lib/libm.so.5 Reading symbols from /lib/libavl.so.2...Reading symbols from /usr/lib/debug//lib/libavl.so.2.debug...done. done. Loaded symbols for /lib/libavl.so.2 Reading symbols from /lib/libbsdxml.so.4...Reading symbols from /usr/lib/debug//lib/libbsdxml.so.4.debug...done. done. Loaded symbols for /lib/libbsdxml.so.4 Reading symbols from /lib/libgeom.so.5...Reading symbols from /usr/lib/debug//lib/libgeom.so.5.debug...done. done. Loaded symbols for /lib/libgeom.so.5 Reading symbols from /lib/libz.so.6...Reading symbols from /usr/lib/debug//lib/libz.so.6.debug...done. done. Loaded symbols for /lib/libz.so.6 Reading symbols from /lib/libthr.so.3...done. Loaded symbols for /lib/libthr.so.3 Why all libs have debug symbols, while your most interesting one, libthr.so.3, does not ? Reading symbols from /lib/libsbuf.so.6...Reading symbols from /usr/lib/debug//lib/libsbuf.so.6.debug...done. done. Loaded symbols for /lib/libsbuf.so.6 Reading symbols from /libexec/ld-elf.so.1...done. Loaded symbols for /libexec/ld-elf.so.1 #0 0x000802703f81 in __pthread_cxa_finalize () from /lib/libthr.so.3 [New LWP 100957] (gdb) bt #0 0x000802703f81 in __pthread_cxa_finalize () from /lib/libthr.so.3 #1 0x000802703e85 in __pthread_cxa_finalize () from /lib/libthr.so.3 #2 0x000802707052 in ?? () from /lib/libthr.so.3 #3 0x00080063fc00 in ?? () #4 0x7fffe638 in ?? () #5 0x7fffe5b0 in ?? () #6 0x0008026f8fd6 in atoi@plt () from /lib/libthr.so.3 #7 0x7fffe5b0 in ?? () #8 0x00080061adfd in r_debug_state () from /libexec/ld-elf.so.1 Previous frame inner to this frame (corrupt stack?) (gdb) old SVN: r296103 new SVN: r296796M (The M is a nd6 patch from markj@) this was a FULL buildworld/buildkernel. If you cd lib/libthr and do make clean all install DEBUG_FLAGS=-g on the broken world, does it fix the problem ? If not, do debugging symbols from libthr appear accessible to gdb at least ? Try this to get useful backtrace with source lines information. It starts crashing as soon as the new libthr is installed. :( -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: l...@lerctr.org US Mail: 7011 W Parmer Ln, Apt 1115, Austin, TX 78729-6961 ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Crashes in libthr?
On Sun, Mar 13, 2016 at 11:16:20AM -0500, Larry Rosenman wrote: > I updated one of my servers, and WHILE DOING THE INSTALLWORLD, I get > segfaults. > > ANY multithreaded program crashes. > > I reverted libthr, and it's fine. > > borg.lerctr.org / # gdb -c zfs.core /sbin/zfs > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you > are > welcome to change it and/or distribute copies of it under certain > conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for > details. > This GDB was configured as "amd64-marcel-freebsd"... > Core was generated by `zfs'. > Program terminated with signal 11, Segmentation fault. > Reading symbols from /lib/libjail.so.1...Reading symbols from > /usr/lib/debug//lib/libjail.so.1.debug...done. > done. > Loaded symbols for /lib/libjail.so.1 > Reading symbols from /lib/libnvpair.so.2...Reading symbols from > /usr/lib/debug//lib/libnvpair.so.2.debug...done. > done. > Loaded symbols for /lib/libnvpair.so.2 > Reading symbols from /lib/libuutil.so.2...Reading symbols from > /usr/lib/debug//lib/libuutil.so.2.debug...done. > done. > Loaded symbols for /lib/libuutil.so.2 > Reading symbols from /lib/libzfs_core.so.2...Reading symbols from > /usr/lib/debug//lib/libzfs_core.so.2.debug...done. > done. > Loaded symbols for /lib/libzfs_core.so.2 > Reading symbols from /lib/libzfs.so.2...Reading symbols from > /usr/lib/debug//lib/libzfs.so.2.debug...done. > done. > Loaded symbols for /lib/libzfs.so.2 > Reading symbols from /lib/libc.so.7...Reading symbols from > /usr/lib/debug//lib/libc.so.7.debug...done. > done. > Loaded symbols for /lib/libc.so.7 > Reading symbols from /lib/libmd.so.6...Reading symbols from > /usr/lib/debug//lib/libmd.so.6.debug...done. > done. > Loaded symbols for /lib/libmd.so.6 > Reading symbols from /lib/libumem.so.2...Reading symbols from > /usr/lib/debug//lib/libumem.so.2.debug...done. > done. > Loaded symbols for /lib/libumem.so.2 > Reading symbols from /lib/libutil.so.9...Reading symbols from > /usr/lib/debug//lib/libutil.so.9.debug...done. > done. > Loaded symbols for /lib/libutil.so.9 > Reading symbols from /lib/libm.so.5...Reading symbols from > /usr/lib/debug//lib/libm.so.5.debug...done. > done. > Loaded symbols for /lib/libm.so.5 > Reading symbols from /lib/libavl.so.2...Reading symbols from > /usr/lib/debug//lib/libavl.so.2.debug...done. > done. > Loaded symbols for /lib/libavl.so.2 > Reading symbols from /lib/libbsdxml.so.4...Reading symbols from > /usr/lib/debug//lib/libbsdxml.so.4.debug...done. > done. > Loaded symbols for /lib/libbsdxml.so.4 > Reading symbols from /lib/libgeom.so.5...Reading symbols from > /usr/lib/debug//lib/libgeom.so.5.debug...done. > done. > Loaded symbols for /lib/libgeom.so.5 > Reading symbols from /lib/libz.so.6...Reading symbols from > /usr/lib/debug//lib/libz.so.6.debug...done. > done. > Loaded symbols for /lib/libz.so.6 > Reading symbols from /lib/libthr.so.3...done. > Loaded symbols for /lib/libthr.so.3 Why all libs have debug symbols, while your most interesting one, libthr.so.3, does not ? > Reading symbols from /lib/libsbuf.so.6...Reading symbols from > /usr/lib/debug//lib/libsbuf.so.6.debug...done. > done. > Loaded symbols for /lib/libsbuf.so.6 > Reading symbols from /libexec/ld-elf.so.1...done. > Loaded symbols for /libexec/ld-elf.so.1 > #0 0x000802703f81 in __pthread_cxa_finalize () from > /lib/libthr.so.3 > [New LWP 100957] > (gdb) bt > #0 0x000802703f81 in __pthread_cxa_finalize () from > /lib/libthr.so.3 > #1 0x000802703e85 in __pthread_cxa_finalize () from > /lib/libthr.so.3 > #2 0x000802707052 in ?? () from /lib/libthr.so.3 > #3 0x00080063fc00 in ?? () > #4 0x7fffe638 in ?? () > #5 0x7fffe5b0 in ?? () > #6 0x0008026f8fd6 in atoi@plt () from /lib/libthr.so.3 > #7 0x7fffe5b0 in ?? () > #8 0x00080061adfd in r_debug_state () from /libexec/ld-elf.so.1 > Previous frame inner to this frame (corrupt stack?) > (gdb) > > old SVN: r296103 > new SVN: r296796M > (The M is a nd6 patch from markj@) > > this was a FULL buildworld/buildkernel. If you cd lib/libthr and do make clean all install DEBUG_FLAGS=-g on the broken world, does it fix the problem ? If not, do debugging symbols from libthr appear accessible to gdb at least ? Try this to get useful backtrace with source lines information. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"