Menu
▾
▴
gnuplot-info
|
From: Frantisek K. <fkl...@re...> - 2014-02-03 17:31:02
|
Hi, wxt terminal always crashes on a haswell machine. It works reliably on older ivy bridge. It seems like wxt terminal on several places unlocks mutexes which are not locked. That combined with XBEGIN/XEND instructions on haswell produces a crash in glibc. wxwidgets documentation (http://docs.wxwidgets.org/stable/group__group__funcmacro__thread.html#ga6671c1599fd4ccf6a7c7bb90b2304709) says: void wxMutexGuiEnter Note Under GTK, no creation of top-level windows is allowed in any thread but the main one. [1] Gnuplot source (gnuplot-4.6.3/src/wxterminal/wxt_gui.cpp:222) says: /* Workaround for a deadlock when the main thread will Wait() for this one. * This issue comes from the fact that our gui main loop is not in the * main thread as wxWidgets was written for. */ wxt_MutexGuiLeave(); This is not the only place where a crash occurs. It depends on whether gnuplot runs with -p argument and whether it gets the plot command as a command line argument or interactively, but there is always some extra unlocking somewhere. Is it possible to run Gnuplot with gtk as a wxWidgets backend? Thanks. Fero PS: My system is Fedora 20 Thread no. 1 (8 frames) #0 _xend at ../nptl/sysdeps/unix/sysv/linux/x86/elision-unlock.c:33 #1 __lll_unlock_elision at ../nptl/sysdeps/unix/sysv/linux/x86/elision-unlock.c:29 #2 wxMutexInternal::Unlock at src/unix/threadpsx.cpp:297 #3 wxMutex::Unlock at include/wx/thrimpl.cpp:60 #4 wxMutexGuiLeave at src/unix/threadpsx.cpp:1737 #5 wxt_MutexGuiLeave at ../../src/wxterminal/wxt_gui.cpp:3671 #6 wxtThread::Entry at ../../src/wxterminal/wxt_gui.cpp:222 #7 wxThreadInternal::PthreadStart at src/unix/threadpsx.cpp:766 |
|
From: Ethan M. <eam...@gm...> - 2014-02-03 18:22:11
|
The following code appears in .../src/wxterminal/wxt_gui.h
/* depending on the platform, and mostly because of the Windows terminal
which
* already has its event loop, we may or may not be multithreaded */
#if defined(__WXGTK__)
# define WXT_MULTITHREADED
#elif defined(__WXMSW__) || defined(__WXMAC__)
# define WXT_MONOTHREADED
#else
# error "wxt does not know if this platform has to be mono- or
multi-threaded"
#endif
On linux this normally results in the MULTITHREADED option being chosen.
Could you please try forcing the MONOTHREADED option instead and reporting
back whether that fixes your problem?
(haven't yet acquired any Haswell machines to test on)
Ethan
On Mon, Feb 3, 2014 at 9:30 AM, Frantisek Kluknavsky <fkl...@re...>wrote:
> Hi,
>
> wxt terminal always crashes on a haswell machine. It works reliably on
> older ivy bridge. It seems like wxt terminal on several places unlocks
> mutexes which are not locked. That combined with XBEGIN/XEND
> instructions on haswell produces a crash in glibc.
>
> wxwidgets documentation
> (
> http://docs.wxwidgets.org/stable/group__group__funcmacro__thread.html#ga6671c1599fd4ccf6a7c7bb90b2304709
> )
> says:
> void wxMutexGuiEnter
> Note
> Under GTK, no creation of top-level windows is allowed in any
> thread but the main one. [1]
>
>
> Gnuplot source (gnuplot-4.6.3/src/wxterminal/wxt_gui.cpp:222) says:
> /* Workaround for a deadlock when the main thread will Wait() for this one.
> * This issue comes from the fact that our gui main loop is not in the
> * main thread as wxWidgets was written for. */
> wxt_MutexGuiLeave();
>
> This is not the only place where a crash occurs. It depends on whether
> gnuplot runs with -p argument and whether it gets the plot command as a
> command line argument or interactively, but there is always some extra
> unlocking somewhere.
>
> Is it possible to run Gnuplot with gtk as a wxWidgets backend?
>
> Thanks.
>
> Fero
>
> PS: My system is Fedora 20
> Thread no. 1 (8 frames)
> #0 _xend at ../nptl/sysdeps/unix/sysv/linux/x86/elision-unlock.c:33
> #1 __lll_unlock_elision at
> ../nptl/sysdeps/unix/sysv/linux/x86/elision-unlock.c:29
> #2 wxMutexInternal::Unlock at src/unix/threadpsx.cpp:297
> #3 wxMutex::Unlock at include/wx/thrimpl.cpp:60
> #4 wxMutexGuiLeave at src/unix/threadpsx.cpp:1737
> #5 wxt_MutexGuiLeave at ../../src/wxterminal/wxt_gui.cpp:3671
> #6 wxtThread::Entry at ../../src/wxterminal/wxt_gui.cpp:222
> #7 wxThreadInternal::PthreadStart at src/unix/threadpsx.cpp:766
>
>
> ------------------------------------------------------------------------------
> Managing the Performance of Cloud-Based Applications
> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
> Read the Whitepaper.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk
> _______________________________________________
> gnuplot-info mailing list
> gnu...@li...
> Membership management via:
> https://lists.sourceforge.net/lists/listinfo/gnuplot-info
>
|
|
From: Frantisek K. <fkl...@re...> - 2014-02-04 09:29:38
|
The crash disappeared with #define WXT_MONOTHREADED. gnuplot plot gnuplot -p plot gnuplot <<< "load 'plot'" all work now. Thanks. On 02/03/2014 07:22 PM, Ethan Merritt wrote: > The following code appears in .../src/wxterminal/wxt_gui.h > > /* depending on the platform, and mostly because of the Windows terminal > which > * already has its event loop, we may or may not be multithreaded */ > #if defined(__WXGTK__) > # define WXT_MULTITHREADED > #elif defined(__WXMSW__) || defined(__WXMAC__) > # define WXT_MONOTHREADED > #else > # error "wxt does not know if this platform has to be mono- or > multi-threaded" > #endif > > On linux this normally results in the MULTITHREADED option being chosen. > Could you please try forcing the MONOTHREADED option instead and > reporting back whether that fixes your problem? > > (haven't yet acquired any Haswell machines to test on) > > Ethan > > > > On Mon, Feb 3, 2014 at 9:30 AM, Frantisek Kluknavsky > <fkl...@re... <mailto:fkl...@re...>> wrote: > > Hi, > > wxt terminal always crashes on a haswell machine. It works reliably on > older ivy bridge. It seems like wxt terminal on several places unlocks > mutexes which are not locked. That combined with XBEGIN/XEND > instructions on haswell produces a crash in glibc. > > wxwidgets documentation > (http://docs.wxwidgets.org/stable/group__group__funcmacro__thread.html#ga6671c1599fd4ccf6a7c7bb90b2304709) > says: > void wxMutexGuiEnter > Note > Under GTK, no creation of top-level windows is allowed in any > thread but the main one. [1] > > > Gnuplot source (gnuplot-4.6.3/src/wxterminal/wxt_gui.cpp:222) says: > /* Workaround for a deadlock when the main thread will Wait() for > this one. > * This issue comes from the fact that our gui main loop is not in the > * main thread as wxWidgets was written for. */ > wxt_MutexGuiLeave(); > > This is not the only place where a crash occurs. It depends on whether > gnuplot runs with -p argument and whether it gets the plot command as a > command line argument or interactively, but there is always some extra > unlocking somewhere. > > Is it possible to run Gnuplot with gtk as a wxWidgets backend? > > Thanks. > > Fero > > PS: My system is Fedora 20 > Thread no. 1 (8 frames) > #0 _xend at ../nptl/sysdeps/unix/sysv/linux/x86/elision-unlock.c:33 > #1 __lll_unlock_elision at > ../nptl/sysdeps/unix/sysv/linux/x86/elision-unlock.c:29 > #2 wxMutexInternal::Unlock at src/unix/threadpsx.cpp:297 > #3 wxMutex::Unlock at include/wx/thrimpl.cpp:60 > #4 wxMutexGuiLeave at src/unix/threadpsx.cpp:1737 > #5 wxt_MutexGuiLeave at ../../src/wxterminal/wxt_gui.cpp:3671 > #6 wxtThread::Entry at ../../src/wxterminal/wxt_gui.cpp:222 > #7 wxThreadInternal::PthreadStart at src/unix/threadpsx.cpp:766 > > ------------------------------------------------------------------------------ > Managing the Performance of Cloud-Based Applications > Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. > Read the Whitepaper. > http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk > _______________________________________________ > gnuplot-info mailing list > gnu...@li... > <mailto:gnu...@li...> > Membership management via: > https://lists.sourceforge.net/lists/listinfo/gnuplot-info > > |
