Hi Alan I'm replying to this without my code in front of me, but I wanted to keep you informed.
>you can use the CC and CXX environment variables >_before_ you invoke cmake in an empty build directory, e.g., > >export CC="gcc -g" >export CXX="g++ -g" I tried that without the -g but it had no effect. I will try with the -g when I'm back in. > [Re CMake dependancies] I have commited that change on my local wxwidgets > topic branch and attach >the patch. Thanks Alan, I'll git am that. >Your recent commits to this topic did solve the memory management >issue at exit that was reported by valgrind. However, there appear to >still be lots of sources of allocated memory that need to be freed on exit. I suspect these are related to the memory leaks Laurent reported with the buffer. Some leaks like these were also reported a couple of years ago, but were blamed on the wxWidgets driver or wxWidgets itself, but never got change to hunt them out. If they are actually related to the buffer then I'm not actually sure if any other drivers use the buffer for redraws so I'm not entirely surprised that they got blamed on wxWidgets. I will hunt them out anyway. >One extremely interesting result was for example 4 which segfaulted >when GUI->File->exit was executed despite no memory management issue >reported by valgrind. Hmmm, interesting. I also got a spurious diagonal line on this example I think. I would guess that there is some buffer issue here, I will try to hunt this out too. >>[...]So once I get to the bottom of the hangs I will try to sort out the >>remaining rendering problems and memory leaks. > >I did not experience any hangs myself I have been trying to get past this. I just found out how to attach a gdb session to a running process and found that the hang occurs in some gtk module and is a threading deadlock. It occurs before the first frame is even initialised - the threading is occurring in gtk by the way, I am not doing any multithreading. So it turns out my instinct about multiprocess code was correct - it was just that it is gtk threads that are at fault not my multiprocess code. This problem has been described by others at https://forums.wxwidgets.org/viewtopic.php?t=37151&p=151356, and then at http://trac.wxwidgets.org/ticket/16202. The wxWidgets devs have blamed an Ubuntu bug, but have put a workaround in their code - http://trac.wxwidgets.org/changeset/76398/svn-wx. Unfortunately it is only 9 months old so I guess it will only be in trunk. A workaround was mentioned on the forum of adding a delay in the initialisation so I guess I will have to do this. So I will keep you informed on all these items. Thanks for the help so far Phil On 23 January 2015 at 22:19, Alan W. Irwin <ir...@beluga.phys.uvic.ca> wrote: > On 2015-01-23 10:41-0000 Phil Rosenberg wrote: > >> Hi Alan >> Thanks for your tests, they are very useful. I have made some further >> changes and attached a new patch. As I know you like interleaved >> posting so much I will try to go through point by point ;-) > > > Thanks for that kindness. :-) > > >> >>>> Just as an experiment I attempted to build the wxwidgets device against >>>> version 2.8 >> >> of the external wxwidgets software >> >> Yes I too was surprised to find that the code built with wxWidgets 2.8 >> on my work Linux machine, although it is here I get the missing >> library runtime error. This machine also has the intel compiler and >> CentOS, rather than gcc and Ubuntu. That said, it does have gcc, but >> icc was being picked up by CMake and I couldn't seem to get it to >> change. I had thought that wxGCDC which was needed to access >> antialiased high quality graphics was a wxWidgets 2.9+ introduction, >> but I was obviously mistaken. I have made an effort therefore to keep >> the driver 2.8 compatible, given many academic users (including >> myself) are probably using enterprise Linux which tend to use older >> software versions. > > > In light of what you said above I will stick with 2.8 for now. Also, with > regard to > your gcc point, you can use the CC and CXX environment variables > _before_ you invoke cmake in an empty build directory, e.g., > > export CC="gcc -g" > export CXX="g++ -g" > > to specify both compiler and compiler flags (if any). > >> >>>> sh: 1: wxPLViewer: not found >>>> That issue is a build-system dependency issue, where to solve it >>>> you need to add the line >>>> >>>> add_dependencies(wxwidgets wxPLViewer) >> >> Thanks Alan. I'm not entirely sure where to put this. The wxWidgets >> driver code is included in the plplot library, so I feel wxPLViewer >> needs to be a dependency of the plplot library. > > > CMake terminology for "dependency" is confusing here so you have to be > very precise in your mental model of what a CMake dependency means. When > target A depends on target B (as specified by add_dependencies(A > B)) that means B is always built first, i.e., it is a prerequisite of > A. So I think what you meant to say above is the target wxPLViewer > should depend on target plplot (i.e., the plplot library). > > It turns out that dependency is enforced indirectly but not directly > (which is fine). The line > > ./utils/CMakeLists.txt: target_link_libraries(wxPLViewer > plplotwxwidgets plplotcxx ${wxwidgets_LINK_FLAGS} ${MATH_LIB}) > > automatically means that wxPLViewer depends on the targets > plplotwxwidgets (the wxwidgets binding for PLplot, libplplotwxwidgets) > and plplotcxx (the C++ binding for PLplot, libplplotcxx)), but not > directly on the target plplot (libplplot, our core C library), i.e., the > wxPLViewer source code directly refers to code both in > libplplotwidgets and libplplotcxx, but not to code in libplplot. (You should > double-check that conclusion is correct.) Of > course, in any case, libplplot will be built first because both the > plplotwidgets and plplotcxx targets depend on the plplot target. > > If memory serves the wxwidgets device (i.e., the wxwidgets target) > already depends on libplplotwidgets. So we currently have two > independent dependency chains set up by our current build system; one > for the wxPLViewer target and one for the wxwidgets target. But it > appears that the wxwidgets device depends on the wxPLViewer utility to > work correctly. Therefore, the two independent dependency chains > should be merged together with > > add_dependencies(wxwidgets wxPLViewer) > > as I stated above. (This logic in no way conflicts with the existing > independent dependency chains. Instead, it simply insures that if the > user builds the wxwidgets target, that the wxPLViewer target will > always be built automatically first.) > > To answer your question about the location of the above logic, you > will see in the top-level CMakeLists.txt file, that the drivers and > src subdirectories are processed before the utils directory so the > appropriate place to put that logic (inside a test whether the > wxwidgets target exists) is utils/CMakeLists.txt. > > I have commited that change on my local wxwidgets topic branch and attach > the patch (created with > > git format-patch --stdout -1 --start-number=38 -n >/tmp/wxAWI_addedpatch > > ) > > Note that patch is just for my single commit and not for the whole > series of commits on the topic branch so you should be able to apply > it with "git am" on top of your own topic branch with no need to > select a patch using the -i option. The above --start-number=38 -n > options are just to remind you that I have applied it as the 38th > commit on my topic branch (i.e., after your 37 commits are applied to > create that topic branch), but that should not preclude you applying > it in some different order if you already have made some further > changes on your own topic branch. > > Of course, you may just be tempted to type in this small change, but > please do not do that. It is important to continue our git knowledge > expansion by using git tools like git am to collaborate. Also, using > git am preserves credit for my first small contribution to this topic. > :-) > >> >>>> examples/c/x01c -dev wxwidgets >>>> worked with no hangs or other obvious run-time issues like segfaults >> >> Thanks for running that test. Would it be possible for you to try a >> handful of other examples too? The hangs I got were generally >> intermittent. Examples 3 and 4 were quite temperamental I seem to >> remember. > > > Your recent commits to this topic did solve the memory management > issue at exit that was reported by valgrind. However, there appear to > still be lots of sources of allocated memory that need to be freed on exit. > > software@raven> !valgrind > valgrind examples/c/x01c -dev wxwidgets > ==7712== Memcheck, a memory error detector > ==7712== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al. > ==7712== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info > ==7712== Command: examples/c/x01c -dev wxwidgets > ==7712== PLplot library version: 5.10.0 > ==7712== ==7712== HEAP SUMMARY: > ==7712== in use at exit: 90,589 bytes in 255 blocks > ==7712== total heap usage: 49,087 allocs, 48,832 frees, 34,890,762 bytes > allocated > ==7712== ==7712== LEAK SUMMARY: > ==7712== definitely lost: 88 bytes in 1 blocks > ==7712== indirectly lost: 68 bytes in 2 blocks > ==7712== possibly lost: 0 bytes in 0 blocks > ==7712== still reachable: 90,433 bytes in 252 blocks > ==7712== suppressed: 0 bytes in 0 blocks > ==7712== Rerun with --leak-check=full to see details of leaked memory > ==7712== ==7712== For counts of detected and suppressed errors, rerun with: > -v > ==7712== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 6 from 6) > > (From what you said, I think you are already aware of such issues from > your own debugging tools. However, let me remind you the issue may be > in version 2.8 of wxwidgets rather than in the wxwidgets-related > PLplot code so there may be nothing that you need to do here.) > > I also tried similar valgring experiments with examples 0, 10, 2, 3 and 4 > (the > first two are because those are such simple examples) with similar > results. They all > showed no memory management issues, and unfreed memory issues like > above. I think 10 rendered OK, but 0, 2, 3, and 4 (like 1) showed > substantial rendering issues (large parts of the plot missing > (examples 0, 1 and 4) > character alignment problems (example 2), and/or orientation of string > problems (example 3). > > One extremely interesting result was for example 4 which segfaulted > when GUI->File->exit was executed despite no memory management issue > reported by valgrind. That is the first time I have ever seen valgrind > give 0 errors in the summary when a segfault occurred, and > I have no idea of how that is even possible. > However, gdb should be able to help you quickly find the > answer. To help you get started with that > I rebuilt from scratch using > > CXXFLAGS=-g -lpthread > CFLAGS=-g -lpthread > FFLAGS=-g -lpthread > > (the -lpthread option is needed in order for gdb to work for -dev > wxwidgets which apparently uses threading). You can also set the > -lpthread option with the CXX, CC, and FC environment variables. > > Here was the initial (but currently rather uninteresting since I set no > break points) result from gdb. > > software@raven> gdb examples/c/x04c > GNU gdb (GDB) 7.4.1-debian > Copyright (C) 2012 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later > <http://gnu.org/licenses/gpl.html> > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. Type "show copying" > and "show warranty" for details. > This GDB was configured as "x86_64-linux-gnu". > For bug reporting instructions, please see: > <http://www.gnu.org/software/gdb/bugs/>... > Reading symbols from > /home/software/plplot/HEAD/build_dir/examples/c/x04c...done. > (gdb) run -dev wxwidgets > Starting program: /home/software/plplot/HEAD/build_dir/examples/c/x04c -dev > wxwidgets > [Thread debugging using libthread_db enabled] > Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". > Segmentation fault > [Inferior 1 (process 14645) exited normally] > (gdb) quit > > So this proves gdb works for this threaded case (it did not work at > all for me if I just used the -g compiler option). Setting some break > points in the wxwidgets code that is executed during exits should > quickly lead to the source of the segfault for example 4. However, I > leave that to you since you are more much more familiar with the > wxwidgets code than I am. > >> [...]So once I get to the bottom of the hangs I will try to sort out the >> remaining rendering problems and memory leaks. > > > I did not experience any hangs myself so I suspect your hangs are due > to CMake picking a bad compiler by default on Ubuntu, but now you know > how to override that default (see above) and set up gdb (using the -g > -lpthread compile options for gcc, g++, and gfortran). Therefore, > once you do that, I assume the hangs will go away and you will be left > with "simple" segfaults like above to debug with gdb. I also > assume that example 4 is needed to trigger the segfault > because it likely sets up the PLplot pages in a valid but distinct > way from other examples which triggers the segfault because > of some minor deficiency in the current wxwidgets device code. > > If you cannot get past the hangs on Ubuntu even when the gcc compiler > suite is used, then you have the options of (1) trying a different Linux > distribution or (2) helping me to navigate through your > your new wxwidgets implementation so I can debug it myself with > gdb. But I think option 2 would take much more of your time than > option 1, and let's hope option 1 isn't necessary either. > > > 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 > __________________________ ------------------------------------------------------------------------------ New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
