Hallo, it seems to me that the message coming from the ~wxPLDevGC was due to deleting wxPLDevGC after calling wxuninitialize. In fact, reverting the things the message disappears, but the ill behaviour is still there. The backtrace of segfault:
#0 0x00007ff9b206c6ff in _L_unlock_532 () from /lib/x86_64-linux-gnu/libpthread.so.0 #1 0x00007ff9b206c704 in _L_unlock_532 () from /lib/x86_64-linux-gnu/libpthread.so.0 #2 0x00007ff9b206c634 in __pthread_mutex_unlock_usercnt (mutex=0xd1b6f0, decr=<optimized out>) at pthread_mutex_unlock.c:52 #3 0x00007ff9b301f44e in wxMutexInternal::Unlock (this=0xd1b6f0) at ../src/unix/threadpsx.cpp:297 #4 0x00007ff9b3021c10 in wxMutex::Unlock (this=0xbfb280) at ../include/wx/thrimpl.cpp:60 #5 0x00007ff9b3021a34 in wxMutexGuiLeave () at ../src/unix/threadpsx.cpp:1737 #6 0x00007ff9b29e3116 in wxapp_poll_func (ufds=0xd29a60, nfds=2, timeout=0) at ../src/gtk/app.cpp:263 ...............174600 equal calls of wxapp_poll_func #174608 0x00007ff9b29e3136 in wxapp_poll_func (ufds=0xd29a60, nfds=2, timeout=0) at ../src/gtk/app.cpp:266 #174609 0x00007ff9b0023624 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #174610 0x00007ff9b0023a82 in g_main_loop_run () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #174611 0x00007ff9b1b5f797 in IA__gtk_main () at /tmp/buildd/gtk+2.0-2.24.10/gtk/gtkmain.c:1256 #174612 0x00007ff9b29ff02b in wxEventLoop::Run (this=0xc5a690) at ../src/gtk/evtloop.cpp:76 #174613 0x00007ff9b2a971d3 in wxAppBase::MainLoop (this=0xd25e40) at ../src/common/appcmn.cpp:312 #174614 0x00007ff9b2a9734a in wxAppBase::OnRun (this=0xd25e40) at ../src/common/appcmn.cpp:367 #174615 0x00007ff9b32f03f9 in wxRunApp (pls=0x7ff9b4ec17e0, runonce=false) at /home/fc/Downloads/plplot-5.9.9/drivers/wxwidgets.cpp:1371 #174616 0x00007ff9b32ef042 in plD_eop_wxwidgets (pls=0x7ff9b4ec17e0) at /home/fc/Downloads/plplot-5.9.9/drivers/wxwidgets.cpp:685 #174617 0x00007ff9b4c65fcf in plP_eop () at /home/fc/Downloads/plplot-5.9.9/src/plcore.c:174 #174618 0x00007ff9b4c6bed7 in c_plend1 () at /home/fc/Downloads/plplot-5.9.9/src/plcore.c:2427 #174619 0x00007ff9b4c6ba1c in c_plend () at /home/fc/Downloads/plplot-5.9.9/src/plcore.c:2377 #174620 0x0000000000400f19 in do_it_once () #174621 0x0000000000400f6a in main () Fulvio From: phil rosenberg <[email protected]> Subject: Re: [Plplot-devel] [ plplot-Bugs-3604554 ] wxwidgets window Date: Fri, 22 Feb 2013 16:19:18 -0800 (PST) > Hi All > I've just tested the situation with a fresh download of the latest plplot > source using the test from Fulvio. As I'm on Windows I had to replace > sleep(3) with Sleep(3000) and #include<windows.h>, but that should make no > difference to the behaviour. > > Without the patch the plot appears fine the first time, closes immediately if > I right click off a plot and then fails when trying to access a null pointer > when I try to display the plots again. > > With the patch the plot appears fine the first time, closes immediately if I > right click the plot. It then appears fine the second time, closes > immediately when I right click off a plot - there is then a 3 second wait at > the command line before the example exits. As far as I can tell this is > exactly the expected behaviour. I've tested both release and debug builds. > > I'm not really sure where to go next. It's not easy to fix a bug that I can't > reproduced. Unfortunately I don't have the time at the moment to set up > plplot on a linux machine. > Does someone happen to be able to run the test in a debugger e.g. by using > Eclipse? In this case the debugger should catch the segfault and show the > exact line where it occurs, and be able to see the call stack (you may need > the development version of wxWidgets with source code). On Windows it is in a > wxwidgets file called toplevel in the CreateFrame member of a class called > wxTopLevelWindowMSW. I guess it's not surprising the bug is slightly > different on Linux then :-). > This was called by wxFrame::Create() which was in turn called by the wxFrame > constructor. Fundamentally it's caused by the wxTheApp macro or > wxApp::GetInstance() returning NULL because wxWidgets isn't initialised. > Knowing where the crash occurs in linux and if it's for the same reason would > be a good start at least. > > Some possible lines of enquirey though if no one has access to a debugger. > Maybe you could try these Fulvio > 1) Which version of wxWidgets are you using? I have 2.8.10. > 2) What is the behaviour if you close the first plot by clicking the x of > selecting exit from the menu? For me this exits the entire application. > 3) Try comment out lines 1396 and 1397 of wxwidgets.cpp - these should be > wxPLGetApp().OnExit(); and plexit( "" );. Now what is the behaviour after > closing the first window using the x or selecting Exit from the menu. > 4) Finaly what is the behaviour for item 3 if the patch has been applied? > > Sorry we're not at the root cause yet > > Phil > > > > ________________________________ > From: Alan W. Irwin <[email protected]> > To: phil rosenberg <[email protected]> > Cc: fulvio ciriaco <[email protected]>; > "[email protected]" <[email protected]>; > "[email protected]" <[email protected]> > Sent: Friday, 22 February 2013, 0:40 > Subject: Re: [Plplot-devel] [ plplot-Bugs-3604554 ] wxwidgets window > > On 2013-02-21 15:14-0800 phil rosenberg wrote: > >> Thanks for the report Fulvio >> In that case I will download a clean version of plplot tomorrow and check >> how it works with that. Unfortunately I do almost all my coding on a windows >> environment - mostly because the debugging tools are so good. >> >> Speak soon >> Phil > > Hi Phil: > > I confirm fulvio's results on my own Debian (wheezy) system. With > Fulvio's test.c example the wxwidgets (wxGC) GUI from the first plinit > does not disappear, and the second plinit segfaults. These (bad) > results occur regardless of whether your wxwidgets patch is applied > or not. > > So I suspect your wxwidgets patch (which, by the way, does apply > cleanly to the svn trunk version of PLplot) addresses part of the > issue but not all of it. > > Will you try test.c yourself for testing purposes rather than your > modified x00c ? I have attached a slightly modified form of it here > (plwid ==> plwidth is required for the trunk version) for your > convenience. Note I have tried this test.c for a number of interactive > devices and the only device where there are issues appears to be > wxwidgets. > > Note, I normally run the default backend=2 (wxGC) but I also just now > tried -drvopt backend=0 (basic) and got the same (bad) results with > test.c. I have not tried backend=1 (AGG) for the wxwidgets device > because the AGG library is not installed on my system. > > Alan > __________________________ > Alan W. Irwin > > Astronomical research affiliation with Department of Physics and Astronomy, > University of Victoria (astrowww.phys.uvic.ca). > > Programming affiliations with the FreeEOS equation-of-state > implementation for stellar interiors (freeeos.sf.net); the Time > Ephemerides project (timeephem.sf.net); PLplot scientific plotting > software package (plplot.sf.net); the libLASi project > (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); > and the Linux Brochure Project (lbproject.sf.net). > __________________________ > > Linux-powered Science > __________________________ ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb _______________________________________________ Plplot-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/plplot-devel
