Re: firefox52 core dump on RPI2 NetBSD9.1

[tlaronde%polynum.com@localhost]

On Fri, Nov 27, 2020 at 08:46:08PM +0530, Mayuresh wrote:
> On Fri, Nov 27, 2020 at 01:52:02PM +0100, tlaronde%polynum.com@localhost wrote:
> > Then Mayuresh has to verify that his versions of the packages were
> > not built "long" ago. Because this is an "old" version of Firefox
> > that is been used, hence its dependencies---the version of its
> > dependencies---have not changed since, and one or several of the
> > dependencies can have been compiled before the fix to the binutils.
> 
> The chronology is this:
> 
> 1. I first tried the binary packages only and faced the issue (see first
> post).
> 
> 2. Then I used a qemu instance on amd64 machine. As it became very slow, I
> decided to build on my RPI3B+ device. While I was arranging for the disk I
> kept qemu instance running. Once the device was up I first installed the
> packages built on the qemu instance and started compiling further.
> 
> 3. I ran into some other issues (discussed on different threads), hence
> aborted the whole processes, cleaned up all packages that were from qemu
> instance and retained only those built afresh on RPI3B+ device. Since I
> identified packages from the qemu instance by timestamp, a small
> probability is I  may have erred in removing all of them - though even
> that instance was of daily build of 10 Nov of 9.1 (the one hyperlinked
> from the qemu instructions page, its link is in my first post.)
> 
> So I don't think there is anything too old lurking on my system, 24Nov is
> the oldest I am having.
> 
> Is there any other clue, such as running nm to look for some symbol etc.
> that can help me spot a faulty library?
> 
> In the meantime, as the error showed libfribidi, I am just rebuilding it.
> 

If on the remote NetBSD pkg directory there is the "good" version for 
your system, in order to gain time, I would suggest to force remove
of the library giving error (not a recursive removal; just force remove
this one, keeping it as a package somewhere in
case of blunder) and install the corresponding one from the remote
server.

If the problem for _this_ library disappears and another message is
printed about the "next" one, we will at least know that there is 
something wrong with the packages you have (and the cure will
be---at least for the strtab message---to replace all the packages
installed with the corresponding version on the server).

If the problem is still here, I will try next week the test case I used
initially to pinpoint the problem (about the mishandling of the strtab),
to know if the exact same thing is here again.

Just to be sure: on your RPI, the kernel is 9.1 but the userland is not
8.x?
-- 
        Thierry Laronde <tlaronde +AT+ polynum +dot+ com>
                     http://www.kergis.com/
                    http://kertex.kergis.com/
                       http://www.sbfa.fr/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C