Bug#750045: gnuplot: no longer works: assert "m_window" failed in DoGetSize()
sfeam
sfeam at users.sourceforge.net
Mon Jun 2 00:18:30 UTC 2014
On Monday, 02 June 2014 12:58:38 AM Olly Betts wrote:
> On Sun, Jun 01, 2014 at 11:56:40PM +0100, Olly Betts wrote:
> > I'm just rebuilding gnuplot with debug symbols to see if that shows
> > where this is coming from.
>
> OK, the attached patch shows the line in gnuplot from which we get to
> the assertion and crash.
>
> It looks like the reason disabling the assertion doesn't help is that
> there's a crash after this (in libgdk-x11 according to gdb). Running under
> valgrind shows a use after free in X11:
>
> $ valgrind gnuplot
> ==9723== Memcheck, a memory error detector
> ==9723== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
> ==9723== Using Valgrind-3.9.0 and LibVEX; rerun with -h for copyright info
> ==9723== Command: gnuplot
> ==9723==
>
> G N U P L O T
> Version 4.6 patchlevel 5 last modified February 2014
> Build System: Linux x86_64
>
> Copyright (C) 1986-1993, 1998, 2004, 2007-2014
> Thomas Williams, Colin Kelley and many others
>
> gnuplot home: http://www.gnuplot.info
> faq, bugs, etc: type "help FAQ"
> immediate help: type "help" (plot window: hit 'h')
>
> Terminal type set to 'wxt'
> gnuplot> plot x
> ==9723== Invalid read of size 8
> ==9723== at 0x8E0AC32: _XReply (in /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0)
> ==9723== by 0x8E0681C: XSync (in /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0)
> ==9723== by 0x9FEB3C0: gdk_flush (in /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0.2400.23)
> ==9723== by 0x9FBBD3D: ??? (in /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0.2400.23)
> ==9723== by 0x9FBC72F: ??? (in /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0.2400.23)
> ==9723== by 0x9FC9FDD: ??? (in /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0.2400.23)
> ==9723== by 0x9FCBA5F: gdk_draw_rgb_image (in /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0.2400.23)
> ==9723== by 0x57700F4: wxBitmap::CreateFromImageAsPixmap(wxImage const&, int) (in /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0.0.0)
> ==9723== by 0x5770C99: wxBitmap::wxBitmap(wxImage const&, int) (in /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0.0.0)
> ==9723== by 0x23422A: wxtPanel::wxt_cairo_create_bitmap() (wxt_gui.cpp:3236)
> ==9723== by 0x23B467: wxtPanel::wxt_cairo_refresh() (wxt_gui.cpp:2526)
> ==9723== by 0x23B7BC: wxt_text (wxt_gui.cpp:1847)
> ==9723== Address 0x15395288 is 8 bytes inside a block of size 24 free'd
> ==9723== at 0x4C2870C: free (vg_replace_malloc.c:468)
> ==9723== by 0x8E0AD12: _XReply (in /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0)
> ==9723== by 0x8E011F4: XQueryPointer (in /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0)
> ==9723== by 0x9FFF583: ??? (in /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0.2400.23)
> ==9723== by 0x9FB3601: ??? (in /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0.2400.23)
> ==9723== by 0x9FB4273: gdk_display_get_window_at_pointer (in /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0.2400.23)
> ==9723== by 0x9B56FCA: gtk_tooltip_trigger_tooltip_query (in /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.23)
> ==9723== by 0x687A6B7: g_slist_foreach (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4000.0)
> ==9723== by 0x9B92AC8: ??? (in /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.23)
> ==9723== by 0x9FB1CF6: ??? (in /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0.2400.23)
> ==9723== by 0x685DCE4: g_main_context_dispatch (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4000.0)
> ==9723== by 0x685E047: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4000.0)
> ==9723==
> [xcb] Unknown request in queue while dequeuing
> [xcb] Most likely this is a multi-threaded client and XInitThreads has not been called
> [xcb] Aborting, sorry about that.
> gnuplot: ../../src/xcb_io.c:179: dequeue_pending_request: Assertion `!xcb_xlib_unknown_req_in_deq' failed.
> ==9723==
> ==9723== HEAP SUMMARY:
> ==9723== in use at exit: 3,615,268 bytes in 17,965 blocks
> ==9723== total heap usage: 66,059 allocs, 48,094 frees, 7,894,552 bytes allocated
> ==9723==
> ==9723== LEAK SUMMARY:
> ==9723== definitely lost: 9,312 bytes in 31 blocks
> ==9723== indirectly lost: 15,332 bytes in 646 blocks
> ==9723== possibly lost: 103,300 bytes in 1,298 blocks
> ==9723== still reachable: 3,388,868 bytes in 15,463 blocks
> ==9723== suppressed: 0 bytes in 0 blocks
> ==9723== Rerun with --leak-check=full to see details of leaked memory
> ==9723==
> ==9723== For counts of detected and suppressed errors, rerun with: -v
> ==9723== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 6 from 6)
> Killed
>
> Running under gdb with a breakpoint on XInitThreads() suggests it isn't
> being called. The man page for XInitThreads says:
>
> It is only necessary to call this function if multiple threads might use
> Xlib concurrently. If all calls to Xlib functions are protected by
> some other access mechanism (for example, a mutual exclusion lock in
> a toolkit or through explicit client programming), Xlib thread
> initialization is not required. It is recommended that
> single-threaded programs not call this function.
>
> But http://docs.wxwidgets.org/trunk/overview_thread.html says:
>
> When writing a multi-threaded application, it is strongly
> recommended that no secondary threads call GUI functions.
>
> I don't really follow the wx startup code in gnuplot, but if it is
> trying to use wx GUI functions from secondary threads, that may be what
> the problem is. That could mean whether the problem manifests itself is
> sensitive to the exact timing of events, which may be why I didn't see
> it originally (I was probably testing on a different machine then).
>
> Or perhaps that warning about XInitThreads is a red herring.
The upstream gnuplot source has already been patched to call XInitThreads.
I didn't realize you were testing without it.
As I said in a separate post, for me this allows running with wx3 but
does not remove the separate stream of error messages starting with
assert "m_window" failed in DoGetSize(): GetSize() doesn't work without window
Ethan
More information about the debian-science-maintainers
mailing list