Current-Users archive

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

Re: firefox dumping core after NetBSD upgrade



I also have xfwm4 crash, but only if there is .config/xfce4 directory.
So far if I remove it, xfce4 works fine. Otherwise the trace appeared
similar to the above.

On Wed, 16 Oct 2019 at 11:03, David H. Gutteridge <david%gutteridge.ca@localhost> wrote:
>
> On Tue, 15 Oct 2019, at 12:00:42 +0100, Robert Swindells wrote:
> > I wrote:
> > >From the stack trace that Paul Goyette provided it looks to me like
> > >a Firefox bug is triggering one in Mesa.
> >
> > I have now got a debug system and firefox build with debug-info, a
> > firefox build with debug wouldn't display an URL.
> >
> > I commented out the locking code to see what happened:
> >
> > Index: errors.c
> > ===================================================================
> > RCS file: /cvsroot/xsrc/external/mit/MesaLib/dist/src/mesa/main/errors.c,v
> > retrieving revision 1.1.1.4
> > diff -u -r1.1.1.4 errors.c
> > --- errors.c    24 Sep 2019 18:10:11 -0000      1.1.1.4
> > +++ errors.c    15 Oct 2019 10:57:17 -0000
> > @@ -306,6 +306,7 @@
> >
> >     do_output = should_output(ctx, error, fmtString);
> >
> > +#if 0
> >     simple_mtx_lock(&ctx->DebugMutex);
> >     if (ctx->Debug) {
> >        do_log = _mesa_debug_is_message_enabled(ctx->Debug,
> > @@ -318,6 +319,9 @@
> >        do_log = GL_FALSE;
> >     }
> >     simple_mtx_unlock(&ctx->DebugMutex);
> > +#else
> > +   do_log = GL_FALSE;
> > +#endif
> >
> >     if (do_output || do_log) {
> >        char s[MAX_DEBUG_MESSAGE_LENGTH], s2[MAX_DEBUG_MESSAGE_LENGTH];
> [...]
>
> FWIW, aside from Firefox (where I also see this issue), I've found
> since the recent Mesa upgrade, Xfce4's window manager consistently
> crashes during startup. These's a correlation with Firefox in the
> backtrace:
>
> Core was generated by `xfwm4'.
> Program terminated with signal SIGSEGV, Segmentation fault.
> (gdb) bt full
> #0  debug_namespace_get (severity=MESA_DEBUG_SEVERITY_HIGH, id=1, ns=0x79f288af02ef) at /usr/xsrc/external/mit/MesaLib/dist/src/mesa/main/debug_output.c:393
>         elem = 0x0
>         node = 0x0
>         state = 0
>         node = <optimized out>
>         state = <optimized out>
>         elem = <optimized out>
> #1  _mesa_debug_is_message_enabled (debug=0x79f288af77a0, source=source@entry=MESA_DEBUG_SOURCE_API, type=type@entry=MESA_DEBUG_TYPE_ERROR, id=1,
>     severity=severity@entry=MESA_DEBUG_SEVERITY_HIGH) at /usr/xsrc/external/mit/MesaLib/dist/src/mesa/main/debug_output.c:623
>         gstack = 0
>         grp = 0x79f288af02ef
>         nspace = 0x79f288af02ef
> #2  0x000079f26fa440b0 in _mesa_error (ctx=ctx@entry=0x79f288ae5898, error=error@entry=1282, fmtString=fmtString@entry=0x79f271815ee4 "Inside glBegin/glEnd")
>     at /usr/xsrc/external/mit/MesaLib/dist/src/mesa/main/errors.c:311
>         do_output = <optimized out>
>         do_log = <optimized out>
>         error_msg_id = 1
> #3  0x000079f26fa5e256 in _mesa_GetString (name=7937) at /usr/xsrc/external/mit/MesaLib/dist/src/mesa/main/getstring.c:124
>         ctx = 0x79f288ae5898
>         vendor = 0x79f271833414 "Brian Paul"
>         renderer = 0x79f2718214ab "Mesa"
> #4  0x000000000041b1b5 in ?? ()
> No symbol table info available.
> #5  0x0000000000442bb8 in ?? ()
> No symbol table info available.
> [...]
>
> (I haven't had any time to look into this further, so I haven't enabled
> debugging symbols for xfwm4 itself.)
>
> Regards,
>
> Dave
>
>


-- 
----


Home | Main Index | Thread Index | Old Index