Thanks for your bug report.
On Wed, Sep 19, 2018 at 11:47:08PM +0200, Vincent Lefevre wrote:
> gnuplot-qt crashed, see attached backtrace. I didn't get any error
> message, but the backtrace shows "corrupted double-linked list":
>
> [...]
> #3 0x00007f1f2a52ae0a in malloc_printerr (str=str@entry=0x7f1f2a62c3d6
> "corrupted double-linked list") at malloc.c:5350
> #4 0x00007f1f2a52e386 in _int_malloc (av=av@entry=0x7f1f2a663c40
> <main_arena>, bytes=bytes@entry=32) at malloc.c:3926
> #5 0x00007f1f2a52f7dd in __GI___libc_malloc (bytes=32) at malloc.c:3065
> #6 0x00007f1f2a8ccfa8 in operator new(unsigned long) () at
> /usr/lib/x86_64-linux-gnu/libstdc++.so.6
> #7 0x00007f1f2c702944 in wxFont::Create(int, wxFontFamily, wxFontStyle,
> wxFontWeight, bool, wxString const&, wxFontEncoding)
> (this=this@entry=0x7fffe5eaf8f0, pointSize=10,
> family=family@entry=wxFONTFAMILY_SWISS, style=style@entry=wxFONTSTYLE_NORMAL,
> weight=weight@entry=wxFONTWEIGHT_NORMAL, underlined=underlined@entry=false,
> face=..., encoding=wxFONTENCODING_SYSTEM) at ../src/gtk/font.cpp:304
> [...]
This is saying that glibc detected malloc heap corruption when
wxWidgets tried to allocate memory. However that doesn't tell us
anything about what caused that corruption - it's likely due to
something writing off the end or start of an allocated block, or
writing to an block that's already been released. That bad code
could be in wxWidgets but it could just as easily be in another
library that's in use, or in gnuplot itself.
> This is not reproducible. Perhaps a race condition or memory corruption
> that does not always produce a crash.
I'm afraid that makes it very hard for us to usefully do anything, since
we don't even know what software the bug is in.
If it's something that happens sporadically I'd suggest you try
habitually running gnuplot under a malloc debugger (e.g. valgrind if the
slowdown is tolerable), and hope that catches the corruption as it
happens.
Cheers,
Olly
