Hi Alan
I think our emails just crossed.
Thanks for the comments - in particular about the memory vs segfault issues and
wxWidgets initialization. It seems like a minefield - I write regular GUI apps
normally so don't delve into the guts of wxWidgets that's needed for writing
amalgamations of console and GUI apps.
I will try to shuffle the code round this week so that we can avoid
uninitializing wxWidgets and also effectively keep track of the frames as we
go. It's not a massive task, it's just finding the time (a problem we all have).
Phil
________________________________
From: Alan W. Irwin <[email protected]>
To: phil rosenberg <[email protected]>; Andrew Ross
<[email protected]>
Cc: Werner Smekal <[email protected]>; Werner Smekal
<[email protected]>; fulvio ciriaco <[email protected]>;
"[email protected]" <[email protected]>;
"[email protected]" <[email protected]>
Sent: Sunday, 24 February 2013, 22:54
Subject: Re: [Plplot-devel] [ plplot-Bugs-3604554 ] wxwidgets window
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
