Control: tag -1 + unreproducible
Tagging based on "This is not reproducible" in the initial report. If
you've since found a way to reproduce, please remove the tag and provide
details.
On Mon, Aug 17, 2015 at 10:36:20PM +0200, Vincent Lefevre wrote:
> On 2015-08-11 23:30:21 +0200, Vincent Lefevre wrote:
> > On 2015-08-11 18:38:06 +0100, Olly Betts wrote:
> > > On Tue, Aug 11, 2015 at 05:59:59PM +0200, Vincent Lefevre wrote:
> > > > On 2015-08-11 16:22:04 +0100, Olly Betts wrote:
> > > > > On Thu, Aug 06, 2015 at 08:54:19PM +0200, Vincent Lefevre wrote:
> > > > > > gnuplot5 crashed due to an assertion failure in libwxgtk3.0-0.
> > > > > > This is not reproducible.
> > > > >
> > > > > You don't seem to have included the assertion message which was
> > > > > displayed, which would be the most useful information to have.
> > > >
> > > > IIRC, there wasn't more information.
> > >
> > > There wasn't an assertion dialog on screen?
> >
> > There was a dialog saying that there was an assertion failure in
> > libwxgtk3.0-0, but I don't think there was more information. Or
> > perhaps it disappeared before I could get the information.
>
> I now remember that I had saved the file:
>
> ASSERT INFO:
> ../src/gtk/dcclient.cpp(250): assert "Assert failure" failed in
> wxFreePoolGC(): Wrong GC
This situation seems "impossible". I suspect (especially given the
unreproducibility) that there's a stray memory write corrupting either
the wxGCPool array, or one of the members (m_penGC, etc) such that when
it comes time to remove the pool entry it isn't found.
It's hard to know if that's a bug in wxWidgets, the application or
another library in use. We don't have a pile of reports suggesting a
memory corruption bug in wx, but it could be one which requires
particular circumstances to trigger.
Cheers,
Olly
