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 not reproducible. Perhaps a race condition or memory corruption
that does not always produce a crash.

Thanks for your bug report.

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.

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

Thanks for your bug report.

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.

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

Hi,

I can see lots of "Conditional jump or move depends on uninitialised
value(s)", and also:

==32184== Invalid read of size 32
==32184==    at 0x790FFD1: __wcsnlen_avx2 (strlen-avx2.S:62)
==32184==    by 0x78578C1: wcsrtombs (wcsrtombs.c:104)
==32184==    by 0x5B12FAF: wcsrtombs (wchar2.h:519)
==32184==    by 0x5B12FAF: wxWC2MB(char*, wchar_t const*, unsigned long) (wxcrt.cpp:127)
==32184==    by 0x5AC1405: wxMBConv::FromWChar(char*, unsigned long, wchar_t const*, unsigned long) const (strconv.cpp:353)
==32184==    by 0x5ACE173: wxString::AsChar(wxMBConv const&) const (string.cpp:554)
==32184==    by 0x5514B96: AsCharBuf (string.h:3546)
==32184==    by 0x5514B96: mb_str (string.h:1829)
==32184==    by 0x5514B96: wxAtoi (wxcrt.h:797)
==32184==    by 0x5514B96: wxImage::GetOptionInt(wxString const&) const (image.cpp:2331)
==32184==    by 0x53B564F: wxCursor::InitFromImage(wxImage const&) (cursor.cpp:252)
==32184==    by 0x53B58B3: wxCursor::wxCursor(wxImage const&) (cursor.cpp:97)
==32184==    by 0x24653C: wxtApp::LoadCursor(wxCursor&, char const**) (wxt_gui.cpp:359)
==32184==    by 0x24BCE6: wxtApp::OnInit() (wxt_gui.cpp:314)
==32184==    by 0x24B539: CallOnInit (app.h:93)
==32184==    by 0x24B539: wxt_init (wxt_gui.cpp:1917)
==32184==    by 0x22DAA2: term_initialise (term.c:499)
==32184==  Address 0xece80d0 is 0 bytes inside a block of size 8 alloc'd
==32184==    at 0x48357BF: malloc (vg_replace_malloc.c:299)
==32184==    by 0x5AC14DF: wxCharTypeBuffer (buffer.h:271)
==32184==    by 0x5AC14DF: wxWCharBuffer (buffer.h:392)
==32184==    by 0x5AC14DF: wxMBConv::FromWChar(char*, unsigned long, wchar_t const*, unsigned long) const (strconv.cpp:306)
==32184==    by 0x5ACE173: wxString::AsChar(wxMBConv const&) const (string.cpp:554)
==32184==    by 0x5514B96: AsCharBuf (string.h:3546)
==32184==    by 0x5514B96: mb_str (string.h:1829)
==32184==    by 0x5514B96: wxAtoi (wxcrt.h:797)
==32184==    by 0x5514B96: wxImage::GetOptionInt(wxString const&) const (image.cpp:2331)
==32184==    by 0x53B564F: wxCursor::InitFromImage(wxImage const&) (cursor.cpp:252)
==32184==    by 0x53B58B3: wxCursor::wxCursor(wxImage const&) (cursor.cpp:97)
==32184==    by 0x24653C: wxtApp::LoadCursor(wxCursor&, char const**) (wxt_gui.cpp:359)
==32184==    by 0x24BCE6: wxtApp::OnInit() (wxt_gui.cpp:314)
==32184==    by 0x24B539: CallOnInit (app.h:93)
==32184==    by 0x24B539: wxt_init (wxt_gui.cpp:1917)
==32184==    by 0x22DAA2: term_initialise (term.c:499)
==32184==    by 0x17FAE7: do_plot (graphics.c:553)
==32184==    by 0x1A5187: eval_plots (plot2d.c:3428)

The original report says "This is not reproducible" so tagging as such.

This looks like valgrind lacking a suppression for an optimised version
of wcslen() for AVX-capable CPUs which deliberately overreads the
string.  I don't think it's connected to this bug report.

Cheers,
    Olly

Similarly to #794799, I'm going to close this as it's not reproducible
and we've no reports of it since 2018.  The problem seems to be a corrupted
malloc heap, and as I said before, the backtrace points to wxWidgets
simply because the corruption is detected when wxWidgets tries to
allocate memory - there's no reason to think it's the wxWidgets code
that caused the corruption - it could be gnuplot or another library in
use by gnuplot (it might be the same root cause as #794799 even).

Cheers,
    Olly