Re: HEADS-UP: /bin/sh memory management bug fixes committed

["Thomas Mueller" <mueller6725%twc.com@localhost>]

from Robert Elz:

>     Date:        Sun, 18 Jun 2017 19:28:19 +0000
>     From:        "Thomas Mueller" <mueller6725%twc.com@localhost>
>     Message-ID:  <79.F6.01815.A54D6495@dnvrco-omsmta03>

>   | What do you use instead of pkg_rolling-replace, while waiting for
>   | portupgrade and portmaster to be imported from FreeBSD ports (wishful
>   | thinking)?
  |
>   | What do you do when you want to update many packages?
        
> I have my own scripts from before pkg_rolling-replace (or almost any of the
> various other tools) existed.   They work out what I have installed that
> is out of date (well, lintpkgsrc does that), figure out the dependencies,
> sort them all into the correct build order, and build binary packages for
> all of the packages that need rebuilding.
        
> Once that's all done (which can take time, as not all packages
> always build properly all the time...) I just install a complete new set of
> packages into an empty /usr/pkg from the binary packages I have built.
> This step only takes a few minutes.   If there's a problem, I just
> move the old /usr/pkg back, while I fix (or wait for someone else to fix)
> whatever went wrong.

>   | Was graphics/graphite2 one of the packages seen to have problems?

> No - or more correctly, that isn't one that I knew of.
        
>   | Trying to configure that segfaulted and dumped core, no informative log.

> That would be the kind of problem I expect the sh bug may have caused.
> That is, just flat out breakage (the bug was subtle, and rare, the effects
> anything but.)
        
> So for that, just try again with a new shell (and a rebuilt libtool I
> would suggest as well.)

> I will try building it on my test system, if it doesn't take too long
> (including whatever dependencies it needs that aren't already there from
> my other pkgsrc building tests.)

>   | My last system update dates were Jun 14 (i386) and Jun 11 (amd64),
>   | within the vulnerable time for /bin/sh bugs.

> Yes.

I suspect sh bug might have been at fault at least in part for pkg_rolling-replace strange behavior, and "make update" compiling a bundle of unrelated stuff.

Finally, mercifully, the mass compilation seemed to run out of memory, crashed and rebooted.

I chose to boot back into the same NetBSD installation to replay log to disk and thereby fix root partition, and then I ran fsck_ffs on two partitions that were mounted, one active, at time of crash.

I don't think I want to do anything serious before upgrading /bin/sh.  Then I can rebuild libtool (make package), then, I think, "make deinstall install".  This would be for both i386 and amd64.

>   | Was graphics/graphite2 one of the packages seen to have problems?

> Just finished build of that (using fixed shell, and all new,
> post sh fix) /usr/pkg, no issues.

I guess I can try that again after seeing where it fits in the schedule of updating other packages.

I have to consider the likelihood that many installed packages will no longer work after updating kernel and userland from 7.99.15 to 7.99.71 to 8.99.1 because shared libraries figure to be out of sync.

This has stung me several times in FreeBSD, shared libraries being out of sync.

Tom