Hi Alan and Jim Just a further note: >One extremely interesting result was for example 4 which segfaulted >when GUI->File->exit was executed despite no memory management issue >reported by valgrind. This occurs due to some sort of buffer corruption. I haven't looked into the details yet, however, the segfault is generated when wxPLViewer tries to display the second page. One of the commands it reads from the buffer indicates it should try to draw a polyline with 0.7 billion points. When it calls rd_data with such a large buffer size which clearly doesn't actually exist it generates the segfault. So the issue here is probably in the buffer code, not the wxWidgets driver. It is just that this driver highlights the problem. I am going to leave this for now as Jim is looking at various bits of buffer code and memory leaks there so there is little point in us writing clashing code.
Jim - Related to this and your work - I'm not exactly sure how you are approaching writing the buffer output code, but it might be useful to concentrate on the actual input and output sections at which point we can then compare the output of drivers from direct instructions and buffered instructions and view the differences. Phil On 25 January 2015 at 11:19, Phil Rosenberg <p.d.rosenb...@gmail.com> wrote: > >I haven't tried >> >>export CC=gcc >>export CXX=g++ >> >>in a while, but they used to always "just work" for me > To be honest it wouldn't surprise me if it is linked to how the intel > compiler is installed on my system. I can probably remove it as we > have a distributed system and the applications are installed at each > login. > >>So my advice is to give up on Ubuntu wxwidgets for a >>development platform until that more official fix propagates and >>actually is proved to fix the issue. >> >>So do you confirm no-hangs (so far) on your CentOS? > I have added a 100 ms delay into my code and so far (fingers crossed) > I have seen no hangs. On centos I have to date not been able to get > the new wxWidgets driver to run at all due to the missing library > problem I reported previously. > > Phil > > > > On 24 January 2015 at 20:35, Alan W. Irwin <ir...@beluga.phys.uvic.ca> wrote: >> On 2015-01-24 16:51-0000 Phil Rosenberg wrote: >> >>> 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. >> >> >> I haven't tried >> >> export CC=gcc >> export CXX=g++ >> >> in a while, but they used to always "just work" for me whether or not >> I added additional compiler options such as -g (which also used to >> "just work"). And I just checked the CMake-3.0.2 module code, >> and it appears it still looks for the CC and CXX environment variables. >> But if you really cannot get it to work with your version of CMake, then >> let me know that version of CMake, and I will try it here (and if I >> can confirm the issue I will report it as a CMake regression). >> >>>>> [...]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. >> >> >> From the above URL's the speculative consensus seems to be this ugly >> hang issue is due to some long-standing (many different Ubuntu versions >> apparently show the wxwidgets hang problem) Ubuntu modification of >> GTK+. And that hypothesis of Ubuntu-only seems to be confirmed not only by >> my >> experience (no hangs on two separate wxwidgets platforms) but also the >> no-hang experience of many other Linux wxwidgets users. Furthermore, on >> Ubuntu >> the timeout fix did not work for all users and the more official fix >> above (which does not involve timeouts as far as I can tell) is a >> speculative one. So my advice is to give up on Ubuntu wxwidgets for a >> development platform until that more official fix propagates and >> actually is proved to fix the issue. >> >> So do you confirm no-hangs (so far) on your CentOS? If so, I would >> stick with that platform for your development work or use an epa_built >> result on any Linux platform since that is apparently free of hangs >> as well (since it builds not only wxwidgets, but an unmodified >> form of the GTK+ software packages it depends on). >> >> In case you are interested in trying the epa_build approach here is the >> cookbook. >> >> 1. Set up required environment variables. >> >> source >> ~software/plplot/HEAD/plplot.git/cmake/epa_build/setup/setup_linux_makefiles >> >> (Note you would have to tailor your equivalent of >> cmake/epa_build/setup/setup_linux_makefiles for your own >> needs such as your preferred cmake version, the install prefix for all >> epa_built packages, your >> preferred compiler flags, etc.) >> >> 2. Clean start. Empty your previous build tree and completely remove >> your previous install tree for epa_build. In >> my case, I did that with >> >> rm -rf /home/wine/newstart/build_script/build_dir-linux/* \ >> /home/wine/newstart/build_script/install-linux >> >> 3. Change directory to empty build tree >> In my case, >> cd /home/wine/newstart/build_script/build_dir-linux/ >> >> 4. Configure epa_build (this takes advantage of environment >> variables that are automatically set up as part of sourcing >> your equivalent of cmake/epa_build/setup/setup_linux_makefiles >> >> cmake -DCMAKE_VERBOSE_MAKEFILE=ON -G"$GENERATOR_STRING" \ >> -DCMAKE_INSTALL_PREFIX:PATH=${INSTALL_PREFIX} \ >> -DBUILD_THE_BUILDTOOLS=OFF $EPA_BUILD_SOURCE_PATH >& cmake.out >> >> 5. Build wxwidgets and the subset of the GTK+ sofware packages >> it depends on. (This took 45 minutes in my case.) >> >> time make build_wxwidgets >& build_wxwidgets.out >> >> 6. Let subsequent invocations of CMake find this new wxwidgets >> version by putting the new wx-config on your PATH >> In my case >> >> PATH=${INSTALL_PREFIX}/bin:$PATH >> >> 7. Check the results to see what system dependencies are still left >> in the epa_built version. >> >> ldd ${INSTALL_PREFIX}/lib/libwx_gtk3u_core-3.0.so | \ >> grep -v ${INSTALL_PREFIX} >> linux-vdso.so.1 => (0x00007fff673b2000) >> librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fe48df4e000) >> libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6 >> (0x00007fe48d8b3000) >> libXxf86vm.so.1 => /usr/lib/x86_64-linux-gnu/libXxf86vm.so.1 >> (0x00007fe48d6ac000) >> libSM.so.6 => /usr/lib/x86_64-linux-gnu/libSM.so.6 >> (0x00007fe48d4a5000) >> libpng12.so.0 => /lib/x86_64-linux-gnu/libpng12.so.0 >> (0x00007fe48d27e000) >> libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fe48d066000) >> libjpeg.so.8 => /usr/lib/x86_64-linux-gnu/libjpeg.so.8 >> (0x00007fe48ce2c000) >> libtiff.so.4 => /usr/lib/x86_64-linux-gnu/libtiff.so.4 >> (0x00007fe48cbc6000) >> libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fe48c9c1000) >> libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fe48c2a7000) >> libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 >> (0x00007fe48bf9f000) >> libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 >> (0x00007fe48bd89000) >> libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 >> (0x00007fe48bb6d000) >> libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fe48b7e1000) >> libXinerama.so.1 => /usr/lib/x86_64-linux-gnu/libXinerama.so.1 >> (0x00007fe48b5df000) >> libXrandr.so.2 => /usr/lib/x86_64-linux-gnu/libXrandr.so.2 >> (0x00007fe48b3d7000) >> libXcursor.so.1 => /usr/lib/x86_64-linux-gnu/libXcursor.so.1 >> (0x00007fe48b1cc000) >> libXi.so.6 => /usr/lib/x86_64-linux-gnu/libXi.so.6 >> (0x00007fe48ad60000) >> libXcomposite.so.1 => /usr/lib/x86_64-linux-gnu/libXcomposite.so.1 >> (0x00007fe48ab5d000) >> libXdamage.so.1 => /usr/lib/x86_64-linux-gnu/libXdamage.so.1 >> (0x00007fe48a95b000) >> libXfixes.so.3 => /usr/lib/x86_64-linux-gnu/libXfixes.so.3 >> (0x00007fe48a755000) >> libxcb-shm.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-shm.so.0 >> (0x00007fe48a290000) >> libxcb-render.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-render.so.0 >> (0x00007fe48a086000) >> libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 >> (0x00007fe489e65000) >> libXrender.so.1 => /usr/lib/x86_64-linux-gnu/libXrender.so.1 >> (0x00007fe489c5c000) >> libXext.so.6 => /usr/lib/x86_64-linux-gnu/libXext.so.6 >> (0x00007fe489a4a000) >> libICE.so.6 => /usr/lib/x86_64-linux-gnu/libICE.so.6 >> (0x00007fe4893d3000) >> libdbus-1.so.3 => /lib/x86_64-linux-gnu/libdbus-1.so.3 >> (0x00007fe48918c000) >> libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1 >> (0x00007fe48885f000) >> libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 >> (0x00007fe488445000) >> /lib64/ld-linux-x86-64.so.2 (0x00007fe4909a6000) >> libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 >> (0x00007fe488037000) >> libjbig.so.0 => /usr/lib/x86_64-linux-gnu/libjbig.so.0 >> (0x00007fe487e28000) >> libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 >> (0x00007fe487c25000) >> libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6 >> (0x00007fe487a1f000) >> >> This is certainly still a long list of system dependencies (i.e., >> libraries not built (yet) by epa_build, but it does appear epa_build >> has done its job because these all appear to be fundamental system >> libraries and not system libraries that are normally part of wxwidgets >> or GTK+. >> >> If you do decide to try an epa_built version of wxwidgets and all its >> GTK+ dependencies, I would be happy to help with any issues you might >> find. However, I honestly think there will be no issues at all >> (assuming you have working compilers) since I have just done all the >> above steps myself, and all those steps are so straightforward so long >> as your system has the *.so versions (which are installed by >> installing development versions of the X, etc., packages) of all the >> above system libraries installed. >> >> >> 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
