Current-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: firefox dumping core after NetBSD upgrade





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.
>
>


--
----


Home | Main Index | Thread Index | Old Index