Re: firefox dumping core after NetBSD upgrade

[Chavdar Ivanov <ci4ic4%gmail.com@localhost>]

Good question.

My "build server" is an old(-ish, maybe 6 years old) HP Elite 8570
laptop with damaged screen and non-functional FireGL graphics card,
which resets the moment it is touched (I disable radeon in the boot
configuration); on top of that, the CPU heatsink is also probably off,
so it regularly overheats and I have to make all my builds using
single core. It does have 20GB memory and a reasonable SSD, though, to
the builds are reasonably decent. It takes me some three-four hours of
a full rust buld (with rust-llvm option), and then another few hours
over firefox; I also usually use ccache (although I see now I have
switched it off - I found a package which builds fine without ccache
and consistently fails with it). So firefox builds are not that hard
now, in my opinion. It used to be, shall we say, rather flaky months
ago, whereas now it has been rock solid for me.

I also build -current nightly (and then routinely update it using
sysupdate), plus I run a few - up to 5 at a time - nvmm virtual
machines on this box, which use zvols as a backend...

Your mileage may vary, as they say.

On Fri, 11 Oct 2019 at 19:06, bch <brad.harder%gmail.com@localhost> wrote:
>
>
>
> On Fri, Oct 11, 2019 at 10:43 Chavdar Ivanov <ci4ic4%gmail.com@localhost> wrote:
>>
>> I wouldn't bother chasing this. My firefox 69.0.2 runs perfectly well
>> under 9.99.15, so I'd rebuild. You would need rust 1.38 though, my
>> build failed with 1.37.
>
>
> I quit running Firefox on my (-current) laptop months ago because the build process (rust, esp) was so brutal. Have there been any community efforts to organize the build artifacts from bleeding-edge environments to avoid repeating (and failing, in my case) this most horrible build?
>
> -bch
>
>>
>> There were some rather substantial changes in the last few versions.
>>
>> On Fri, 11 Oct 2019 at 17:40, Sad Clouds <cryintothebluesky%gmail.com@localhost> wrote:
>> >
>> > On Fri, 11 Oct 2019 08:27:31 -0700 (PDT)
>> > Paul Goyette <paul%whooppee.com@localhost> wrote:
>> >
>> > > Core was generated by `firefox'.
>> > > Program terminated with signal SIGSEGV, Segmentation fault.
>> > > #0  0x00007af20d009a7b in _atomic_cas_ptr (new=<optimized out>,
>> > > #old=0x0,
>> > >      ptr=0x7af20d3cb730)
>> > >      at /build/netbsd-local/src_ro/lib/libpthread/arch/x86_64/pthread_md.h:77
>> > > 77              __asm __volatile ("lock; cmpxchgq %2, %1"
>> > > [Current thread is 1 (process 1)]
>> > > (gdb)
>> >
>> > void *atomic_cas_ptr(volatile void *ptr, void *old, void *new);
>> >
>> > So assuming setting old to NULL is allowed, then I guess either ptr or
>> > new are pointing to invalid memory locations.
>> >
>> > Can you step through the first 5 frames and see if you can narrow down
>> > which pointer is corrupt? You have debug symbols for NetBSD libraries.
>> >
>> >
>>
>>
>> --
>> ----



-- 
----