On 2009-08-27 09:47+0100 Andrew Ross wrote: > > Sorry, > > Scrub that. What I was actually doing was pressing return so the second plot > was with the xwin driver not the xcairo / qtwidget driver. This explains the > different size windows. > > It is interesting that qtwidget followed by xwin crashes. This still looks > like qtwidget is not correctly cleaning up something. The crash occurs deep > inside the xlib libraries from a call to OpenXWin. The actual crash is while > calling getenv which seems bizarre. Perhaps Qt is messing up the process > environment in a bad way? > > When I run with qtwidget for both windows the program runs but is not > valgrind clean. I often get a grey window for the first plot when running > with valgrind, although it seems ok running normally. > > Now when I run with xcairo for both windows I get a crash on the second > window with lots of font-related messages from glib / pango. Note that > having xwin for the second window runs fine. > > So we seem to have two separate bugs here. One with qtwidget / xwin > possibly related to the process environment somehow and one with > xcairo / xcairo related to font resources. > > I have made some progress with the qtwidget issue. If, rather than starting > a second plot you make a call to getenv searching for an environment variable > which is not set then you should get a NULL pointer returned. Instead you > get a segmentation fault. This seems to pin down the problem to the qtwidget > driver messing up the environment. The same getenv call before the first > plinit / plend works correctly. Whatever is messing things up is in plend > but not in plend1.
Thanks for your further investigations. I just tried qtwidget/xwin and valgrind confirms on my platform (Qt4.5.1, 64bit Debian stable) the getenv issue (invalid read followed by segfault) you discovered for that combination. However, qtwidget/qtwidget remains valgrind clean. I view your problems with qtwidget/qtwidget to be much higher priority than the qtwidget/xwin issue since few will ever use that latter combination. Since our platforms are very similar in most respects (including 64 bit) I wonder if you would get the valgrind clean result for qtwidget/qtwidget if you moved from Qt4.5.0 to 4.5.1? That's a pretty easy download and install from trolltech, and to get our build system to use that version rather than the system version, simply put the correct version of qmake on your path with a result similar to mine: softw...@raven> which qmake /home/software/qtsdk-2009.02/qt/bin/qmake Here is what my current qmake says about version: softw...@raven> qmake --version QMake version 2.01a Using Qt version 4.5.1 in /home/software/qtsdk-2009.02/qt/lib Hope that idea of moving to 4.5.1 helps with qtwidget/qtwidget. 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); PLplot scientific plotting software package (plplot.org); 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 __________________________ ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
