On 2016-12-10 13:41-0000 p.d.rosenb...@gmail.com wrote:

> Many thanks Alan for pushing this and getting the debug statements into the 
> code. You have confirmed that i was looking in the wrong place for the 
> problem.
>
> I was mulling things over this morning and wondered about the same thing as 
> you, some sort of memory leak with the shared memory. You have obviously 
> shown that not to be the case.
>
> The error messages are a bit of a surprise. I would have thought that the 
> memory map would count the number of system wide open calls that had been 
> made and only close when all those open calls was matched with a close. I 
> will have to check the documentation to be sure. Maybe this is related to the 
> long delay somehow.
>
> I think the next step is probably to add some timing code to the viewer. My 
> plan is to try to sort the other bugs i mentioned this evening. Then if there 
> is still time I may try that.
>
> If you do anything else in the meantime then let me know so we can avoid 
> duplicated effort.

Hi Phil:

I was just going to leave this issue to you until post-release because there
is lot of other stuff on my pre-release agenda, but if we could solve
this issue for the release it would be great so I am perfectly willing
to be flexible on the release timing if that will make a difference.
Also after I got some much-needed sleep I woke up just now with huge
curiosity about what is going on with the really obvious and reliably
generated long pause for the second (!) time an example is executed if
too close to the first execution.

So instead of pursuing this with inserting timing statements like you
are thinking about, instead I plan to simply insert more debug prints,
e.g., "PLMemoryMap::create: entering", PLMemoryMap::create: calling
close" in the PLMemoryMap::create and PLMemoryMap::close code. With
the idea I do a binary search to find exactly which system call is
causing that long pause.  Of course, my initial result might be the
long pause might not be in PLMemoryMap at all.  So we will see how
this goes, and I hope to have some results for you in an hour or so
from now.

Also, it strikes me that since Pedro is finding those segfaults on
three different Linux systems for his own work, clearly there is
something going on that is different for Linux compared to Windows,
and it might be related to this long pause issue I am investigating.

Meanwhile, I would appreciate it if you and everybody else here with
access to wxwidgets and Linux tried my experiment on Linux of

time examples/c/x01c -dev wxwidgets -np; echo "done x01c"; time examples/c/x01c 
-dev wxwidgets -np;echo "done x01c"

just to make absolutely sure the reliable long pause (> 5 seconds and
often > 10 seconds) I am getting for this experiment is not just some
bug with a particular system call for the Debian Jessie version of
that and instead is there for all Linux systems we have access to
here.  Laurent confirmed the long pause with a somewhat similar
experiment a few weeks ago for a quite different Linux kernel (I have
forgotten the distribution), but it would be good to get confirmation
on a variety of Linux systems.

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
__________________________

------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Reply via email to