Hi Phil: Most of this is directed to you, but I also have a question for Andrew below.
On 2013-02-24 02:03-0800 phil rosenberg wrote: > Hi Alan > I'll run the tests you suggest today some time (balancing kids and decorating at the moment) and send in the patch. I have also found that simply not calling wxUninitialize() when we destroy the first window allows the second window to work as normal. For some reason it seems that on Linix wxWidgets does not like being repeatedly initialise and uninitialized. If I can sort out a source code build of wxWidgets I will try to dig deeper. > Looking through the source on Windows it looks like initializing multiple times does not cause problems as there is a check to avoid this. I'm not sure if failing to unitialize will cause a memory leak on exit - perhaps this is less bad than a segfault anyway? @Phil: Having some left-over memory hanging around due to not closing libraries is far preferred to segfaults. See also my question to Andrew below concerning using lt_dlclose rather than lt_dlexit. > Alternatively is there a point in the plplot initialization/uninitialization which could allow wxWidgets to be initialized/uninitialized exactly once per application? I checked the code, and it appears (see additional background information below, but you should double-check me) that initialization of the wxwidgets library should only happen once, and it should never be uninitialized (until that happens automatically when the whole app exits). > I will post something on the wxWidgets forum to see if thereis something I'm missing. Just to give you some more background, we handle device driver DLL's at run time using calls to lt_dlinit, lt_dlopenext, lt_dlmakeresident, lt_dlerror, lt_dlsym, and lt_dlexit. On Unix systems those are calls to the ltdl library API documented at http://www.delorie.com/gnu/docs/libtool/libtool_46.html. Note, for example, that the call to lt_dlmakeresident (which happens for all our device drivers that depend on external libraries) should make sure that the wxwidgets library remains resident, i.e., it should not be be closed and then reopened on each call to plend followed by a call to plinit. This call to lt_dlmakeresident greatly improves behaviour for the plend/plinit case (e.g. as used in test.c) for the Qt and Cairo external libraries and _should_ improve the behaviour for that case for the wxwidgets external library as well, i.e., the wxwidgets library should never be uninitialized. But that is relying on some interpretation of the ltdl documentation and the improved results we got for the Qt and Cairo cases. For example, I am concerned we call lt_dlexit (to exit the entire libltdl library) rather than lt_dlclose, and I don't really see how lt_dlmakeresident survives that. Perhaps the combination of lt_dlmakeresident and lt_dlexit works because of special ways that the Qt and Cairo libraries are linked on Linux, and wxwidgets does not have this linking? @Andrew: Can you comment on the possibility of using lt_dlclose rather than lt_dlexit? My feeling is we used lt_dlexit in the past to reduce leftover memory reported by valgrind, but I don't care about that if it makes run-time dlopening of our device drivers more reliable. @Phil: In stark contrast to the Unix case, on Windows these lt_* calls are calls to routines defined in src/ltdl_win32.c. So this difference may be the source of the differences between the behaviours of the wxwidgets device driver on Linux and Windows, but the confusing thing is I would have expected problems to show up for the Windows case (since lt_dlmakeresident is a no-op for this case) rather than the Linux case. Hope this background helps you to sort out the issues, and I look forward to your patch. 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
