Re: ino64? r318606 -> r318739 OK; r318739 -> r318781 fails SIGSEGV

2017-05-25 Thread Simon J. Gerraty 
Simon J. Gerraty  wrote:

> Peter Jeremy  wrote:
> > In my case, I have "WITH_META_MODE=yes" in /etc/src-env.conf and was
> > using "make buildworld" - which failed.  The upgrade worked cleanly
> > when I manually deleted all the .meta files.  If I get a round tuit,
> 
> sys.mk is setup such that missing .meta file makes the target
> out-of-date.
> 
> FWIW I just did a buildworld -DWITH_META_MODE followed by the same with
> -DNO_CLEAN - but no change to the tree.
> That at least worked fine (and quickly) tree was last updated to r318755
> 
> Wonder if it is safe to update...

FWIW I updated to r318860
and again

make -j12  -DWITHOUT_TESTS buildworld -DWITH_META_MODE -DNO_CLEAN

completed happily.

I guess need to update to/from the specific grns people had issue with
to reproduce.

___
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: ino64? r318606 -> r318739 OK; r318739 -> r318781 fails SIGSEGV

2017-05-24 Thread Simon J. Gerraty 
Peter Jeremy  wrote:
> In my case, I have "WITH_META_MODE=yes" in /etc/src-env.conf and was
> using "make buildworld" - which failed.  The upgrade worked cleanly
> when I manually deleted all the .meta files.  If I get a round tuit,

sys.mk is setup such that missing .meta file makes the target
out-of-date.

FWIW I just did a buildworld -DWITH_META_MODE followed by the same with
-DNO_CLEAN - but no change to the tree.
That at least worked fine (and quickly) tree was last updated to r318755

Wonder if it is safe to update...
___
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: ino64? r318606 -> r318739 OK; r318739 -> r318781 fails SIGSEGV

2017-05-24 Thread Peter Jeremy 
On 2017-May-24 20:21:54 +0300, Konstantin Belousov  wrote:
>No SIGSEGV etc, so I think that the effects seen are due to build system.
>rm -rf obj/* is the safest trick, I believe.

But the behaviour does indicate that meta mode is not doing the right thing
under all circumstances.  It's blatently breaking in this scenario but could
be causing more subtle (and unnoticed) breakage in other cases.  This makes
me feel that this is worth investigating further.

-- 
Peter Jeremy


signature.asc
Description: PGP signature

Re: ino64? r318606 -> r318739 OK; r318739 -> r318781 fails SIGSEGV

2017-05-24 Thread Peter Jeremy 
On 2017-May-24 18:01:42 -0700, "Simon J. Gerraty"  wrote:
>Peter Jeremy  wrote:
>> as follows.  My suspicion is that meta mode isn't seeing enough of the
>> differences between the bootstrap and main build steps and so causing make
>> to incorrectly skip steps.
>
>I see a number of places in src/Makefile* where BUILD_TOOLS_META=.NOMETA
>is added to env of things like CROSSENV, CD2MAKE, LIBCOMPATWMAKEENV
>
>Use of .NOMETA could be leading to problems - but I'm not familiar with
>where BUILD_TOOLS_META is used.

I've not looked at the guts of how meta mode works or is inhibited either.

In my case, I have "WITH_META_MODE=yes" in /etc/src-env.conf and was
using "make buildworld" - which failed.  The upgrade worked cleanly
when I manually deleted all the .meta files.  If I get a round tuit,
I'll try to revert to before the update and have a closer look at what
broke with the "normal" build, if no-one else beats me to it.

-- 
Peter Jeremy


signature.asc
Description: PGP signature

Re: ino64? r318606 -> r318739 OK; r318739 -> r318781 fails SIGSEGV

2017-05-24 Thread Simon J. Gerraty 
Peter Jeremy  wrote:
> as follows.  My suspicion is that meta mode isn't seeing enough of the
> differences between the bootstrap and main build steps and so causing make
> to incorrectly skip steps.

I see a number of places in src/Makefile* where BUILD_TOOLS_META=.NOMETA
is added to env of things like CROSSENV, CD2MAKE, LIBCOMPATWMAKEENV

Use of .NOMETA could be leading to problems - but I'm not familiar with
where BUILD_TOOLS_META is used.


> 
> --
> >>> stage 2.3: build tools
> --
> cd /usr/src; MAKEOBJDIRPREFIX=/usr/obj  INSTALL="sh 
> /usr/src/tools/install.sh"  TOOLS_PREFIX=/usr/obj/usr/src/tmp  
> PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/bin:/sbin:/bin:/usr/sbin:/usr/bin
>   WORLDTMP=/usr/obj/usr/src/tmp  MAKEFLAGS="-m /usr/src/tools/build/mk  -m 
> /usr/src/share/mk" /usr/obj/usr/src/make.amd64/bmake  -f Makefile.inc1  
> TARGET=amd64 TARGET_ARCH=amd64  DESTDIR=  BOOTSTRAPPING=1200031  SSP_CFLAGS=  
> -DNO_LINT  -DNO_CPU_CFLAGS MK_WARNS=no MK_CTF=no  MK_CLANG_EXTRAS=no 
> MK_CLANG_FULL=no  MK_LLDB=no MK_TESTS=no build-tools
> ...
> ===> usr.bin/mkesdb_static (obj,build-tools)
> Building /usr/obj/usr/src/usr.bin/mkesdb_static/citrus_bcs.o
> Building /usr/obj/usr/src/usr.bin/mkesdb_static/citrus_db_factory.o
> Building /usr/obj/usr/src/usr.bin/mkesdb_static/citrus_db_hash.o
> Building /usr/obj/usr/src/usr.bin/mkesdb_static/citrus_lookup_factory.o
> Building /usr/obj/usr/src/usr.bin/mkesdb_static/lex.c
> Building /usr/obj/usr/src/usr.bin/mkesdb_static/lex.o
> /usr/src/usr.bin/mkesdb/lex.l:44:10: fatal error: 'yacc.h' file not found
> #include "yacc.h"
>  ^~~~
>1 error generated.
>*** Error code 1
___
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: ino64? r318606 -> r318739 OK; r318739 -> r318781 fails SIGSEGV

2017-05-24 Thread Peter Jeremy 
On 2017-May-24 08:47:41 -0700, Ngie Cooper  wrote:
>There was another report on the list about a stale MAKEOBJDIRPREFIX 
> causing someone grief. I think it's safe to say that meta mode and -DNO_CLEAN 
> might not work across this transition--in particular meta mode tends to err 
> on the side of not to rebuilding things.

I ran into a very similar problem trying to update from r318744 to r318781.
In my case, even two "make clean" wasn't enough and "make buildworld" died
as follows.  My suspicion is that meta mode isn't seeing enough of the
differences between the bootstrap and main build steps and so causing make
to incorrectly skip steps.

--
>>> stage 2.3: build tools
--
cd /usr/src; MAKEOBJDIRPREFIX=/usr/obj  INSTALL="sh /usr/src/tools/install.sh"  
TOOLS_PREFIX=/usr/obj/usr/src/tmp  
PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/bin:/sbin:/bin:/usr/sbin:/usr/bin
  WORLDTMP=/usr/obj/usr/src/tmp  MAKEFLAGS="-m /usr/src/tools/build/mk  -m 
/usr/src/share/mk" /usr/obj/usr/src/make.amd64/bmake  -f Makefile.inc1  
TARGET=amd64 TARGET_ARCH=amd64  DESTDIR=  BOOTSTRAPPING=1200031  SSP_CFLAGS=  
-DNO_LINT  -DNO_CPU_CFLAGS MK_WARNS=no MK_CTF=no  MK_CLANG_EXTRAS=no 
MK_CLANG_FULL=no  MK_LLDB=no MK_TESTS=no build-tools
...
===> usr.bin/mkesdb_static (obj,build-tools)
Building /usr/obj/usr/src/usr.bin/mkesdb_static/citrus_bcs.o
Building /usr/obj/usr/src/usr.bin/mkesdb_static/citrus_db_factory.o
Building /usr/obj/usr/src/usr.bin/mkesdb_static/citrus_db_hash.o
Building /usr/obj/usr/src/usr.bin/mkesdb_static/citrus_lookup_factory.o
Building /usr/obj/usr/src/usr.bin/mkesdb_static/lex.c
Building /usr/obj/usr/src/usr.bin/mkesdb_static/lex.o
/usr/src/usr.bin/mkesdb/lex.l:44:10: fatal error: 'yacc.h' file not found
#include "yacc.h"
 ^~~~
 1 error generated.
 *** Error code 1

Stop.
bmake[3]: stopped in /usr/src/usr.bin/mkesdb_static
.ERROR_TARGET='lex.o'
.ERROR_META_FILE='/usr/obj/usr/src/usr.bin/mkesdb_static/lex.o.meta'
.MAKE.LEVEL='3'
MAKEFILE=''
.MAKE.MODE='meta missing-filemon=yes missing-meta=yes silent=yes verbose'
.CURDIR='/usr/src/usr.bin/mkesdb_static'
.MAKE='/usr/obj/usr/src/make.amd64/bmake'
.OBJDIR='/usr/obj/usr/src/usr.bin/mkesdb_static'
.TARGETS='build-tools'
DESTDIR=''
LD_LIBRARY_PATH=''
MACHINE='amd64'
MACHINE_ARCH='amd64'
MAKEOBJDIRPREFIX='/usr/obj'
MAKESYSPATH='/usr/src/share/mk'
MAKE_VERSION='20161212'
PATH='/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/bin:/sbin:/bin:/usr/sbin:/usr/bin'
SRCTOP='/usr/src'
OBJTOP='/usr/obj/usr/src'
.MAKE.MAKEFILES='/usr/src/share/mk/sys.mk /usr/src/share/mk/local.sys.env.mk 
/usr/src/share/mk/src.sys.env.mk /etc/src-env.conf 
/usr/src/share/mk/bsd.mkopt.mk /usr/src/share/mk/bsd.suffixes.mk /etc/make.conf 
/usr/src/share/mk/local.sys.mk /usr/src/share/mk/src.sys.mk 
/usr/src/usr.bin/mkesdb_static/Makefile /usr/src/usr.bin/mkesdb/Makefile.inc 
/usr/src/tools/build/mk/bsd.prog.mk /usr/src/share/mk/bsd.prog.mk 
/usr/src/share/mk/bsd.init.mk /usr/src/share/mk/bsd.opts.mk 
/usr/src/share/mk/bsd.cpu.mk /usr/src/share/mk/local.init.mk 
/usr/src/share/mk/src.init.mk /usr/src/usr.bin/mkesdb_static/../Makefile.inc 
/usr/src/share/mk/bsd.own.mk /usr/src/share/mk/bsd.compiler.mk 
/usr/src/share/mk/bsd.compiler.mk /usr/src/share/mk/bsd.libnames.mk 
/usr/src/share/mk/src.libnames.mk /usr/src/share/mk/src.opts.mk 
/usr/src/share/mk/bsd.nls.mk /usr/src/share/mk/bsd.confs.mk 
/usr/src/share/mk/bsd.files.mk /usr/src/share/mk/bsd.incs.mk 
/usr/src/share/mk/bsd.links.mk /usr/src/share/mk/bsd.man.mk 
/usr/src/share/mk/bsd.dep.mk /usr/src/share/mk/bsd.clang-analyze.mk 
/usr/src/share/mk/bsd.obj.mk /usr/src/share/mk/bsd.subdir.mk 
/usr/src/share/mk/bsd.sys.mk /usr/src/tools/build/mk/Makefile.boot'
.PATH='. /usr/src/usr.bin/mkesdb_static /usr/src/lib/libc/iconv 
/usr/src/usr.bin/mkesdb'
*** Error code 1

I've done a "find /usr/obj -name \*.meta -print0 | xargs -0 rm" and am still
waiting for that to complete, though it has passed the above failure point.

-- 
Peter Jeremy


signature.asc
Description: PGP signature

Re: ino64? r318606 -> r318739 OK; r318739 -> r318781 fails SIGSEGV

2017-05-24 Thread David Wolfskill 
On Wed, May 24, 2017 at 01:42:39PM -0700, Simon J. Gerraty wrote:
> David Wolfskill  wrote:
> > As far as I can tell, the "ld" command was:
> 
> Since you have the .meta file, it should tell you exactly what the
> command was and what path was actually exec'd

And now that I'm not running around like a headless chicken, and
had time to look to see where the single-character codes in the
meta file are documented (filemon(4)), the correct answeer is:
/usr/obj/usr/src/tmp/usr/bin/ld

(Note that I provided the entire meta file, as well :-})

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
"[T]he president’s improper efforts to influence an ongoing investigation"

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: ino64? r318606 -> r318739 OK; r318739 -> r318781 fails SIGSEGV

2017-05-24 Thread Simon J. Gerraty 
Ngie Cooper  wrote:

> There was another report on the list about a stale
> MAKEOBJDIRPREFIX causing someone grief.

Pointer?
What does stale MAKEOBJDIRPREFIX mean?

>I think it's safe to say that
> meta mode and -DNO_CLEAN might not work across this transition--in
> particular meta mode tends to err on the side of not to rebuilding
> things.

I would have expected the opposite.
___
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: ino64? r318606 -> r318739 OK; r318739 -> r318781 fails SIGSEGV

2017-05-24 Thread Simon J. Gerraty 
David Wolfskill  wrote:
> As far as I can tell, the "ld" command was:

Since you have the .meta file, it should tell you exactly what the
command was and what path was actually exec'd

___
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: ino64? r318606 -> r318739 OK; r318739 -> r318781 fails SIGSEGV

2017-05-24 Thread Konstantin Belousov 
On Wed, May 24, 2017 at 08:15:09AM -0700, David Wolfskill wrote:
> On Wed, May 24, 2017 at 07:20:01AM -0700, David Wolfskill wrote:
> > ...
> > > > I have updated /usr/src back to 318781, then started a new build.
> > > So are you building stock 318781, or did you reverted r318750 ?
> > 
> > Stock 318781 [*].  I revert as a (nearly) last resort. :-)
> > 
> > > > While it has not yet completed ">>> stage 4.2: building libraries", it
> > > > is well beyond the provious point of failure (again, building parts of
> > > > clang/libllvm).
> > > > 
> > > > I'm reporting now, as I'll need to head in to work fairly soon.  I
> > > > should be able to report definitively a bit later.
> > 
> > It's completed the ">>> stage 4.2: building libraries" part, and well
> > into ">>> stage 4.3: building everything".
> > 
> > * Save for my (usual) hacking of conf/newvers.sh a bit.
> > 
> > And now I really do need to head in to work.
> > ...
> 
> It completed successfully and a reboot shows:
> 
> FreeBSD freebeast.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #354  
> r318781M/318781:1200031: Wed May 24 07:31:48 PDT 2017 
> r...@freebeast.catwhisker.org:/common/S3/obj/usr/src/sys/GENERIC  amd64
> 

I performed a local experiment, first building sources from r318784
on a system where I did pre-commit test for ino64, updating the machine
to the result of it, then building sources of r318789 and again updating.

No SIGSEGV etc, so I think that the effects seen are due to build system.
rm -rf obj/* is the safest trick, I believe.
___
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: ino64? r318606 -> r318739 OK; r318739 -> r318781 fails SIGSEGV

2017-05-24 Thread Ngie Cooper 

> On May 24, 2017, at 08:15, David Wolfskill  wrote:

...

> It completed successfully and a reboot shows:
> 
> FreeBSD freebeast.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #354  
> r318781M/318781:1200031: Wed May 24 07:31:48 PDT 2017 
> r...@freebeast.catwhisker.org:/common/S3/obj/usr/src/sys/GENERIC  amd64

Hi David!
There was another report on the list about a stale MAKEOBJDIRPREFIX causing 
someone grief. I think it's safe to say that meta mode and -DNO_CLEAN might not 
work across this transition--in particular meta mode tends to err on the side 
of not to rebuilding things.
Cheers,
-Ngie
___
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: ino64? r318606 -> r318739 OK; r318739 -> r318781 fails SIGSEGV

2017-05-24 Thread David Wolfskill 
On Wed, May 24, 2017 at 07:20:01AM -0700, David Wolfskill wrote:
> ...
> > > I have updated /usr/src back to 318781, then started a new build.
> > So are you building stock 318781, or did you reverted r318750 ?
> 
> Stock 318781 [*].  I revert as a (nearly) last resort. :-)
> 
> > > While it has not yet completed ">>> stage 4.2: building libraries", it
> > > is well beyond the provious point of failure (again, building parts of
> > > clang/libllvm).
> > > 
> > > I'm reporting now, as I'll need to head in to work fairly soon.  I
> > > should be able to report definitively a bit later.
> 
> It's completed the ">>> stage 4.2: building libraries" part, and well
> into ">>> stage 4.3: building everything".
> 
> * Save for my (usual) hacking of conf/newvers.sh a bit.
> 
> And now I really do need to head in to work.
> ...

It completed successfully and a reboot shows:

FreeBSD freebeast.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #354  
r318781M/318781:1200031: Wed May 24 07:31:48 PDT 2017 
r...@freebeast.catwhisker.org:/common/S3/obj/usr/src/sys/GENERIC  amd64

Peace,
david   (typing from shuttle en route to work)
-- 
David H. Wolfskill  da...@catwhisker.org
"[T]he president’s improper efforts to influence an ongoing investigation"

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: ino64? r318606 -> r318739 OK; r318739 -> r318781 fails SIGSEGV

2017-05-24 Thread David Wolfskill 
On Wed, May 24, 2017 at 05:16:38PM +0300, Konstantin Belousov wrote:
> On Wed, May 24, 2017 at 06:59:05AM -0700, David Wolfskill wrote:
> > On Wed, May 24, 2017 at 04:35:58PM +0300, Konstantin Belousov wrote:
> > > If build of r318739 succed, can you try, please, to rebuild the current
> > > latest sources, but now with reverted r318750 ?
> > 
> > It did complete successfully.
> > 
> > I have updated /usr/src back to 318781, then started a new build.
> So are you building stock 318781, or did you reverted r318750 ?

Stock 318781 [*].  I revert as a (nearly) last resort. :-)

> > While it has not yet completed ">>> stage 4.2: building libraries", it
> > is well beyond the provious point of failure (again, building parts of
> > clang/libllvm).
> > 
> > I'm reporting now, as I'll need to head in to work fairly soon.  I
> > should be able to report definitively a bit later.

It's completed the ">>> stage 4.2: building libraries" part, and well
into ">>> stage 4.3: building everything".

* Save for my (usual) hacking of conf/newvers.sh a bit.

And now I really do need to head in to work.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
"[T]he president’s improper efforts to influence an ongoing investigation"

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: ino64? r318606 -> r318739 OK; r318739 -> r318781 fails SIGSEGV

2017-05-24 Thread Konstantin Belousov 
On Wed, May 24, 2017 at 06:59:05AM -0700, David Wolfskill wrote:
> On Wed, May 24, 2017 at 04:35:58PM +0300, Konstantin Belousov wrote:
> > If build of r318739 succed, can you try, please, to rebuild the current
> > latest sources, but now with reverted r318750 ?
> 
> It did complete successfully.
> 
> I have updated /usr/src back to 318781, then started a new build.
So are you building stock 318781, or did you reverted r318750 ?

> 
> While it has not yet completed ">>> stage 4.2: building libraries", it
> is well beyond the provious point of failure (again, building parts of
> clang/libllvm).
> 
> I'm reporting now, as I'll need to head in to work fairly soon.  I
> should be able to report definitively a bit later.
___
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: ino64? r318606 -> r318739 OK; r318739 -> r318781 fails SIGSEGV

2017-05-24 Thread David Wolfskill 
On Wed, May 24, 2017 at 04:35:58PM +0300, Konstantin Belousov wrote:
> ...
> > (lldb) bt
> > * thread #1, name = 'ld', stop reason = signal SIGSEGV
> >   * frame #0: 0x
> > (lldb) 
> > 
> > which isn't entirely unexpected, I suppose, given the nature of SIGSEGV.
> Useful gdb is in ports, devel/gdb.

OK; thanks.

> There is nothing in the nature of SIGSEGV which makes lack of the
> backtrace a reasonable outcome.

Oh; OK.

> ...
> If build of r318739 succed, can you try, please, to rebuild the current
> latest sources, but now with reverted r318750 ?

It did complete successfully.

I have updated /usr/src back to 318781, then started a new build.

While it has not yet completed ">>> stage 4.2: building libraries", it
is well beyond the provious point of failure (again, building parts of
clang/libllvm).

I'm reporting now, as I'll need to head in to work fairly soon.  I
should be able to report definitively a bit later.

Thank you for your help!

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
"[T]he president’s improper efforts to influence an ongoing investigation"

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: ino64? r318606 -> r318739 OK; r318739 -> r318781 fails SIGSEGV

2017-05-24 Thread Konstantin Belousov 
On Wed, May 24, 2017 at 06:01:43AM -0700, David Wolfskill wrote:
> On Wed, May 24, 2017 at 02:10:08PM +0200, Dimitry Andric wrote:
> > ...
> > > building special pic c library
> > > --- libc.so.7 ---
> > > cc: error: unable to execute command: Segmentation fault (core dumped)
> > > cc: error: linker command failed due to signal (use -v to see invocation)
> > > *** [libc.so.7] Error code 254
> > 
> > Looks like your linker is crashing.  Can you figure out:
> > 1) The exact linker command being run
> > 2) The path to the linker executable that crashes
> > 3) Backtrace of the crash
> > 
> > -Dimitry
> > 
> 
> On Wed, May 24, 2017 at 03:10:33PM +0300, Konstantin Belousov wrote:
> > ...
> > 
> > If you perform build of r318739 on r318739 (i.e. build of the same sources
> > as installed on your machine), does the SIGSEGV occur ?
> > 
> > Anyway, get the core file loaded into gdb and get the backtrace, at least.
> 
> Sorry for the delay; I'm way out of practice with using a debugger...
> and I see that gdb isn't in head now.  lldb tells me:
> 
> (lldb) bt
> * thread #1, name = 'ld', stop reason = signal SIGSEGV
>   * frame #0: 0x
> (lldb) 
> 
> which isn't entirely unexpected, I suppose, given the nature of SIGSEGV.
Useful gdb is in ports, devel/gdb.

There is nothing in the nature of SIGSEGV which makes lack of the
backtrace a reasonable outcome.

> 
> On the build machine, I "cloned" slice 4 to slice 3, then rebooted it
> from slice 3, "updated" /usr/src to r318739 and told it to go build
> itself (while I continued poking at my laptop).  The build machine has
> not yet completed the ">>> stage 4.2: building libraries" step -- recall
> that I had performed a "make clean" before cloning... -- but it has got
> quite a bit beyond the previous point of failure (still building clang).
> 
> I have copied the ld.core and libc.so.7.meta files from the build
> machine to  (and
> made gzipped copies, as well).
> 
> As far as I can tell, the "ld" command was:
> freebeast(12.0-C)[10] ls -lT `which ld`
> -r-xr-xr-x  2 root  wheel  1706336 May 23 05:29:59 2017 /usr/bin/ld
> 
> This, from:
> FreeBSD freebeast.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #352  
> r318739M/318739:1200031: Tue May 23 05:16:24 PDT 2017 
> r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/sys/GENERIC  amd64
> 
> Late note: ">>> stage 4.2: building libraries" has completed on the
> build machine (building r318739 while running r318739).
> 
> I apologize for not getting all the information you (both) requested, but
> thought it best to provisde what I can (sooner).

If build of r318739 succed, can you try, please, to rebuild the current
latest sources, but now with reverted r318750 ?
___
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: ino64? r318606 -> r318739 OK; r318739 -> r318781 fails SIGSEGV

2017-05-24 Thread David Wolfskill 
On Wed, May 24, 2017 at 02:10:08PM +0200, Dimitry Andric wrote:
> ...
> > building special pic c library
> > --- libc.so.7 ---
> > cc: error: unable to execute command: Segmentation fault (core dumped)
> > cc: error: linker command failed due to signal (use -v to see invocation)
> > *** [libc.so.7] Error code 254
> 
> Looks like your linker is crashing.  Can you figure out:
> 1) The exact linker command being run
> 2) The path to the linker executable that crashes
> 3) Backtrace of the crash
> 
> -Dimitry
> 

On Wed, May 24, 2017 at 03:10:33PM +0300, Konstantin Belousov wrote:
> ...
> 
> If you perform build of r318739 on r318739 (i.e. build of the same sources
> as installed on your machine), does the SIGSEGV occur ?
> 
> Anyway, get the core file loaded into gdb and get the backtrace, at least.

Sorry for the delay; I'm way out of practice with using a debugger...
and I see that gdb isn't in head now.  lldb tells me:

(lldb) bt
* thread #1, name = 'ld', stop reason = signal SIGSEGV
  * frame #0: 0x
(lldb) 

which isn't entirely unexpected, I suppose, given the nature of SIGSEGV.

On the build machine, I "cloned" slice 4 to slice 3, then rebooted it
from slice 3, "updated" /usr/src to r318739 and told it to go build
itself (while I continued poking at my laptop).  The build machine has
not yet completed the ">>> stage 4.2: building libraries" step -- recall
that I had performed a "make clean" before cloning... -- but it has got
quite a bit beyond the previous point of failure (still building clang).

I have copied the ld.core and libc.so.7.meta files from the build
machine to  (and
made gzipped copies, as well).

As far as I can tell, the "ld" command was:
freebeast(12.0-C)[10] ls -lT `which ld`
-r-xr-xr-x  2 root  wheel  1706336 May 23 05:29:59 2017 /usr/bin/ld

This, from:
FreeBSD freebeast.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #352  
r318739M/318739:1200031: Tue May 23 05:16:24 PDT 2017 
r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/sys/GENERIC  amd64

Late note: ">>> stage 4.2: building libraries" has completed on the
build machine (building r318739 while running r318739).

I apologize for not getting all the information you (both) requested, but
thought it best to provisde what I can (sooner).

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
"[T]he president’s improper efforts to influence an ongoing investigation"

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: ino64? r318606 -> r318739 OK; r318739 -> r318781 fails SIGSEGV

2017-05-24 Thread Konstantin Belousov 
On Wed, May 24, 2017 at 04:59:31AM -0700, David Wolfskill wrote:
> Yesterday's in-place src update (r318606 -> r318739) was a bit more
> "interesting" than usual; as has been noted elsewhere, it really is
> necessary to boot the new kernel before the "make installworld"
> completes successfully.  That said, it ("make installworld") did
> complete successfully, and a followup reboot/smoke test worked without
> incident.
> 
> For today's update, sources are now at r318781; both laptop and build
> machine fail identically during ">>> stage 4.2: building libraries":
> 
> ...
> Building /common/S4/obj/usr/src/lib/libc/strsignal.pico
> Building /common/S4/obj/usr/src/lib/libc/libc.a
> --- libc.a ---
> building static c library
> Building /common/S4/obj/usr/src/lib/libc/libc.so.7
> Building /common/S4/obj/usr/src/lib/libc/libc_pic.a
> --- libc.so.7 ---
> building shared library libc.so.7
> --- libc_pic.a ---
> building special pic c library
> --- libc.so.7 ---
> cc: error: unable to execute command: Segmentation fault (core dumped)
> cc: error: linker command failed due to signal (use -v to see invocation)
> *** [libc.so.7] Error code 254
> 
> bmake[4]: stopped in /usr/src/lib/libc
> .ERROR_TARGET='libc.so.7'
> .ERROR_META_FILE='/common/S4/obj/usr/src/lib/libc/libc.so.7.meta'
> .MAKE.LEVEL='4'
> MAKEFILE=''
> .MAKE.MODE='meta missing-filemon=yes missing-meta=yes silent=yes verbose'
> .CURDIR='/usr/src/lib/libc'
> .MAKE='/usr/obj/usr/src/make.amd64/bmake'
> .OBJDIR='/usr/obj/usr/src/lib/libc'
> .TARGETS='all'
> DESTDIR='/usr/obj/usr/src/tmp'
> LD_LIBRARY_PATH=''
> MACHINE='amd64'
> MACHINE_ARCH='amd64'
> MAKEOBJDIRPREFIX='/usr/obj'
> MAKESYSPATH='/usr/src/share/mk'
> MAKE_VERSION='20160604'
> PATH='/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin'
> SRCTOP='/usr/src'
> OBJTOP='/usr/obj/usr/src'
> .MAKE.MAKEFILES='/usr/src/share/mk/sys.mk /usr/src/share/mk/local.sys.env.mk 
> /usr/src/share/mk/src.sys.env.mk /etc/src-env.conf 
> /usr/src/share/mk/bsd.mkopt.mk /usr/src/share/mk/bsd.suffixes.mk 
> /etc/make.conf /usr/src/share/mk/local.sys.mk /usr/src/share/mk/src.sys.mk 
> /etc/src.conf /usr/src/lib/libc/Makefile /usr/src/share/mk/src.opts.mk 
> /usr/src/share/mk/bsd.own.mk /usr/src/share/mk/bsd.opts.mk 
> /usr/src/share/mk/bsd.cpu.mk /usr/src/share/mk/bsd.compiler.mk 
> /usr/src/share/mk/bsd.compiler.mk /usr/src/lib/libc/amd64/Makefile.inc 
> /usr/src/lib/libc/db/Makefile.inc /usr/src/lib/libc/db/btree/Makefile.inc 
> /usr/src/lib/libc/db/db/Makefile.inc /usr/src/lib/libc/db/hash/Makefile.inc 
> /usr/src/lib/libc/db/man/Makefile.inc /usr/src/lib/libc/db/mpool/Makefile.inc 
> /usr/src/lib/libc/db/recno/Makefile.inc 
> /usr/src/lib/libc/compat-43/Makefile.inc /usr/src/lib/libc/gdtoa/Makefile.inc 
> /usr/src/lib/libc/gen/Makefile.inc /usr/src/lib/libc/amd64/gen/Makefile.inc 
> /usr/src/lib/libc/gmon/Makefile.inc /usr/s
 rc/lib/libc/iconv/Makefile.inc /usr/src/lib/libc_nonshared/Makefile.iconv 
/usr/src/lib/libc/inet/Makefile.inc /usr/src/lib/libc/isc/Makefile.inc 
/usr/src/lib/libc/locale/Makefile.inc /usr/src/lib/libc/md/Makefile.inc 
/usr/src/lib/libc/nameser/Makefile.inc /usr/src/lib/libc/net/Makefile.inc 
/usr/src/lib/libc/nls/Makefile.inc /usr/src/lib/libc/posix1e/Makefile.inc 
/usr/src/lib/libc/regex/Makefile.inc /usr/src/lib/libc/resolv/Makefile.inc 
/usr/src/lib/libc/stdio/Makefile.inc /usr/src/lib/libc/stdlib/Makefile.inc 
/usr/src/lib/libc/amd64/stdlib/Makefile.inc 
/usr/src/lib/libc/stdlib/jemalloc/Makefile.inc 
/usr/src/lib/libc/stdtime/Makefile.inc /usr/src/lib/libc/string/Makefile.inc 
/usr/src/lib/libc/amd64/string/Makefile.inc /usr/src/lib/libc/sys/Makefile.inc 
/usr/src/sys/sys/syscall.mk /usr/src/lib/libc/amd64/sys/Makefile.inc 
/usr/src/lib/libc/secure/Makefile.inc /usr/src/lib/libc/rpc/Makefile.inc 
/usr/src/lib/libc/uuid/Makefile.inc /usr/src/lib/libc/xdr/Makefile.inc 
/usr/src/lib/libc/x86/
 sys/Makefile.inc /usr/src/lib/libc/yp/Makefile.inc /
> .PATH='. /usr/src/lib/libc /usr/src/lib/libc/db/btree /usr/src/lib/libc/db/db 
> /usr/src/lib/libc/db/hash /usr/src/lib/libc/db/man /usr/src/lib/libc/db/mpool 
> /usr/src/lib/libc/db/recno /usr/src/lib/libc/compat-43 
> /usr/src/lib/libc/gdtoa /usr/src/lib/libc/amd64/gen /usr/src/lib/libc/gen 
> /usr/src/contrib/libc-pwcache /usr/src/contrib/libc-vis 
> /usr/src/lib/libc/gmon /usr/src/lib/libc/iconv /usr/src/lib/libc/inet 
> /usr/src/lib/libc/isc /usr/src/lib/libc/locale /usr/src/lib/libmd 
> /usr/src/lib/libc/nameser /usr/src/lib/libc/net /usr/src/lib/libc/nls 
> /usr/src/lib/libc/posix1e /usr/src/lib/libc/regex /usr/src/lib/libc/resolv 
> /usr/src/lib/libc/stdio /usr/src/lib/libc/amd64/stdlib 
> /usr/src/lib/libc/stdlib /usr/src/lib/libc/stdlib/jemalloc 
> /usr/src/lib/libc/stdtime /usr/src/contrib/tzcode/stdtime 
> /usr/src/lib/libc/amd64/string /usr/src/lib/libc/string /usr/src/sys/libkern 
> /usr/src/lib/lib

Re: ino64? r318606 -> r318739 OK; r318739 -> r318781 fails SIGSEGV

2017-05-24 Thread Dimitry Andric 
On 24 May 2017, at 13:59, David Wolfskill  wrote:
> 
> Yesterday's in-place src update (r318606 -> r318739) was a bit more
> "interesting" than usual; as has been noted elsewhere, it really is
> necessary to boot the new kernel before the "make installworld"
> completes successfully.  That said, it ("make installworld") did
> complete successfully, and a followup reboot/smoke test worked without
> incident.
> 
> For today's update, sources are now at r318781; both laptop and build
> machine fail identically during ">>> stage 4.2: building libraries":
> 
> ...
> Building /common/S4/obj/usr/src/lib/libc/strsignal.pico
> Building /common/S4/obj/usr/src/lib/libc/libc.a
> --- libc.a ---
> building static c library
> Building /common/S4/obj/usr/src/lib/libc/libc.so.7
> Building /common/S4/obj/usr/src/lib/libc/libc_pic.a
> --- libc.so.7 ---
> building shared library libc.so.7
> --- libc_pic.a ---
> building special pic c library
> --- libc.so.7 ---
> cc: error: unable to execute command: Segmentation fault (core dumped)
> cc: error: linker command failed due to signal (use -v to see invocation)
> *** [libc.so.7] Error code 254

Looks like your linker is crashing.  Can you figure out:
1) The exact linker command being run
2) The path to the linker executable that crashes
3) Backtrace of the crash

-Dimitry



signature.asc
Description: Message signed with OpenPGP

ino64? r318606 -> r318739 OK; r318739 -> r318781 fails SIGSEGV

2017-05-24 Thread David Wolfskill 
Yesterday's in-place src update (r318606 -> r318739) was a bit more
"interesting" than usual; as has been noted elsewhere, it really is
necessary to boot the new kernel before the "make installworld"
completes successfully.  That said, it ("make installworld") did
complete successfully, and a followup reboot/smoke test worked without
incident.

For today's update, sources are now at r318781; both laptop and build
machine fail identically during ">>> stage 4.2: building libraries":

...
Building /common/S4/obj/usr/src/lib/libc/strsignal.pico
Building /common/S4/obj/usr/src/lib/libc/libc.a
--- libc.a ---
building static c library
Building /common/S4/obj/usr/src/lib/libc/libc.so.7
Building /common/S4/obj/usr/src/lib/libc/libc_pic.a
--- libc.so.7 ---
building shared library libc.so.7
--- libc_pic.a ---
building special pic c library
--- libc.so.7 ---
cc: error: unable to execute command: Segmentation fault (core dumped)
cc: error: linker command failed due to signal (use -v to see invocation)
*** [libc.so.7] Error code 254

bmake[4]: stopped in /usr/src/lib/libc
.ERROR_TARGET='libc.so.7'
.ERROR_META_FILE='/common/S4/obj/usr/src/lib/libc/libc.so.7.meta'
.MAKE.LEVEL='4'
MAKEFILE=''
.MAKE.MODE='meta missing-filemon=yes missing-meta=yes silent=yes verbose'
.CURDIR='/usr/src/lib/libc'
.MAKE='/usr/obj/usr/src/make.amd64/bmake'
.OBJDIR='/usr/obj/usr/src/lib/libc'
.TARGETS='all'
DESTDIR='/usr/obj/usr/src/tmp'
LD_LIBRARY_PATH=''
MACHINE='amd64'
MACHINE_ARCH='amd64'
MAKEOBJDIRPREFIX='/usr/obj'
MAKESYSPATH='/usr/src/share/mk'
MAKE_VERSION='20160604'
PATH='/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin'
SRCTOP='/usr/src'
OBJTOP='/usr/obj/usr/src'
.MAKE.MAKEFILES='/usr/src/share/mk/sys.mk /usr/src/share/mk/local.sys.env.mk 
/usr/src/share/mk/src.sys.env.mk /etc/src-env.conf 
/usr/src/share/mk/bsd.mkopt.mk /usr/src/share/mk/bsd.suffixes.mk /etc/make.conf 
/usr/src/share/mk/local.sys.mk /usr/src/share/mk/src.sys.mk /etc/src.conf 
/usr/src/lib/libc/Makefile /usr/src/share/mk/src.opts.mk 
/usr/src/share/mk/bsd.own.mk /usr/src/share/mk/bsd.opts.mk 
/usr/src/share/mk/bsd.cpu.mk /usr/src/share/mk/bsd.compiler.mk 
/usr/src/share/mk/bsd.compiler.mk /usr/src/lib/libc/amd64/Makefile.inc 
/usr/src/lib/libc/db/Makefile.inc /usr/src/lib/libc/db/btree/Makefile.inc 
/usr/src/lib/libc/db/db/Makefile.inc /usr/src/lib/libc/db/hash/Makefile.inc 
/usr/src/lib/libc/db/man/Makefile.inc /usr/src/lib/libc/db/mpool/Makefile.inc 
/usr/src/lib/libc/db/recno/Makefile.inc 
/usr/src/lib/libc/compat-43/Makefile.inc /usr/src/lib/libc/gdtoa/Makefile.inc 
/usr/src/lib/libc/gen/Makefile.inc /usr/src/lib/libc/amd64/gen/Makefile.inc 
/usr/src/lib/libc/gmon/Makefile.inc /usr/src/lib/libc/iconv/Makefile.inc 
/usr/src/lib/libc_nonshared/Makefile.iconv /usr/src/lib/libc/inet/Makefile.inc 
/usr/src/lib/libc/isc/Makefile.inc /usr/src/lib/libc/locale/Makefile.inc 
/usr/src/lib/libc/md/Makefile.inc /usr/src/lib/libc/nameser/Makefile.inc 
/usr/src/lib/libc/net/Makefile.inc /usr/src/lib/libc/nls/Makefile.inc 
/usr/src/lib/libc/posix1e/Makefile.inc /usr/src/lib/libc/regex/Makefile.inc 
/usr/src/lib/libc/resolv/Makefile.inc /usr/src/lib/libc/stdio/Makefile.inc 
/usr/src/lib/libc/stdlib/Makefile.inc 
/usr/src/lib/libc/amd64/stdlib/Makefile.inc 
/usr/src/lib/libc/stdlib/jemalloc/Makefile.inc 
/usr/src/lib/libc/stdtime/Makefile.inc /usr/src/lib/libc/string/Makefile.inc 
/usr/src/lib/libc/amd64/string/Makefile.inc /usr/src/lib/libc/sys/Makefile.inc 
/usr/src/sys/sys/syscall.mk /usr/src/lib/libc/amd64/sys/Makefile.inc 
/usr/src/lib/libc/secure/Makefile.inc /usr/src/lib/libc/rpc/Makefile.inc 
/usr/src/lib/libc/uuid/Makefile.inc /usr/src/lib/libc/xdr/Makefile.inc 
/usr/src/lib/libc/x86/sys/Makefile.inc /usr/src/lib/libc/yp/Makefile.inc 
/usr/src/lib/libc/capability/Makefile.inc /usr/src/share/mk/bsd.lib.mk 
/usr/src/share/mk/bsd.init.mk /usr/src/share/mk/local.init.mk 
/usr/src/share/mk/src.init.mk /usr/src/lib/libc/../Makefile.inc 
/usr/src/share/mk/bsd.libnames.mk /usr/src/share/mk/src.libnames.mk 
/usr/src/share/mk/bsd.symver.mk /usr/src/share/mk/bsd.nls.mk 
/usr/src/share/mk/bsd.files.mk /usr/src/share/mk/bsd.incs.mk 
/usr/src/share/mk/bsd.confs.mk /usr/src/share/mk/bsd.links.mk 
/usr/src/share/mk/bsd.dep.mk /usr/src/share/mk/bsd.clang-analyze.mk 
/usr/src/share/mk/bsd.obj.mk /usr/src/share/mk/bsd.subdir.mk 
/usr/src/share/mk/bsd.sys.mk'
.PATH='. /usr/src/lib/libc /usr/src/lib/libc/db/btree /usr/src/lib/libc/db/db 
/usr/src/lib/libc/db/hash /usr/src/lib/libc/db/man /usr/src/lib/libc/db/mpool 
/usr/src/lib/libc/db/recno /usr/src/lib/libc/compat-43 /usr/src/lib/libc/gdtoa 
/usr/src/lib/libc/amd64/gen /usr/src/lib/libc/gen /usr/src/contrib/libc-pwcache 
/usr/src/contrib/libc-vis /usr/src/lib/libc/gmon /usr/src/lib/libc/iconv 
/usr/src/lib/libc/inet /usr/src/lib/libc/isc /usr/src/lib/libc/locale 
/usr/src/lib/libmd /usr/src/lib/libc/n