Re: [Plplot-devel] wxPLplotDemo.cpp errors
Hi Pedro
I have included the devel list on this email, so the thread will get
documented on the mailing list.
It is very strange that the OnCreate function is not being called. If
you are calling Create then you should be generating a create event.
Am I correct in saying that you are getting this segfault with the
unchanged demo app?
This location really is the best (and maybe only) place this
initialisation should be done. It cannot be included in the
constructor, because the generic nature of the template specification
means the code in the constructor does not know which type of wxWindow
we are inheriting from so cannot pass the correct parameters to the
constructor. By the time OnPaint is called it is really too late,
because we would like to already have the plot initialised and ready
to draw and it would be a real pain for you in your code if you had to
somehow wait for the first paint or resize event.
I do have access to a CentOS machine at work, although I think I have
only got access to wxWidgets 2.8 on that system. I will check. I may
be able to build 3.1 from source. I presume you are using 3.1.0 as
released in February, rather than the head of the master branch?
On 10 December 2016 at 07:52, Pedro Vicente
wrote:
> Hi Phil
>
> My idea for a fix is to move the stream initialization that is now on
>
> void wxPLplotwindow::OnCreate( wxWindowCreateEvent &event
> {
> if ( !m_created )
>
> either to the OnSize or onPaint events
>
> void wxPLplotwindow::OnSize( wxSizeEvent& WXUNUSED( event ) )
>
> and also in the plot call do this
>
> template< class WXWINDOW >
> void Plot( wxPLplotwindow *plotwindow )
> {
>wxPLplotstream* pls = plotwindow->GetStream();
>
>if (pls == NULL)
>{
> return;
>}
>
>
> Like this , in this sequence
>
>
> wxPLplotwindow *frame = new wxPLplotwindow();
>frame->Create( NULL, wxID_ANY, wxT( "wxPLplotDemo" ) );
>frame->SetIcon( wxIcon( graph ) );
>frame->Show();
>Plot( frame );
>
>
> first we go to
> Plot( frame );
>
> but the stream is NULL because
> :OnCreate
> was not called, but the function returns, avoiding the seg fault
>
> then the window gets a paint or size event, and the stream initialization
> code is called
> at this time I have a PLplot empty black window
>
> but because
> Plot( frame );
> was only called at start, it is not called again, so there is no draw
>
> any ideas here ?
>
> of course making the Plot() call in another app function should work
>
>
> If you could replicate this issue, that would be great.
> I am using CentOS 6.8, PLplot.5.11.1 , wxWidgets 3.1.0
>
>
>
>
>
> - Original Message - From: Pedro Vicente
> To: plplot-devel@lists.sourceforge.net ; Phil Rosenberg
> Sent: Saturday, December 10, 2016 12:59 AM
> Subject: Re: [Plplot-devel] wxPLplotDemo.cpp errors
>
>
> Hi Phil
>
> So, the issue seems to be the same that I have been reporting
>
>
> In the wxPLplotDemo.cpp code you have these callling functions
>
>
> wxPLplotwindow *frame = new wxPlDemoFrame();
> frame->Create( NULL, wxID_ANY, wxT( "wxPLplotDemo" ) );
>
>
> that make 2 calls to the PLplot library, or the wxWidgets driver of it
> all these calls are in the header file wxPLplotwindow.h
>
> first the constructor is called
>
> template
> wxPLplotwindow::wxPLplotwindow( bool useGraphicsContext, wxSize
> clientSize )
>: m_created( false ), m_initialSize( clientSize )
>
>
> then this call OnCreate() is called, like you mentioned
> and the !m_created bool makes the initialization of the stream happen
>
> the problem is that this function id *NOT* called on my linux build (it is
> on the Windows build)
> so therefore later
> wxPLplotstream* pls = plotwindow->GetStream();
>
> this is NULL, so therefore it seg faults on the plot calls
>
> //! This is called when the widow is created i.e. after WXWINDOW::Create
> // has been called. We note that this has been called to avoid attempting
> // to redraw a plot on a window that hasn't been created yet.
> template
> void wxPLplotwindow::OnCreate( wxWindowCreateEvent &event )
> {
> if ( !m_created )
>
> so, one quick try is to put the code of
>
> void wxPLplotwindow::OnCreate
> that is not called on the constructor maybe ?
>
> -Pedro
>
> - Original Message - From: Pedro Vicente
> To: plplot-devel@lists.sourceforge.net ; Phil Rosenberg
> Sent: Friday, December 09, 2016 11:57 PM
> Subject: [Plplot-devel] wxPLplotDemo.cpp errors
>
>
> Hi Phil
>
> So, resuming the last thread about wxWidgets, what I did was to build and
> run wxPLplotDemo.cpp from PLpplot 5.11.1 on CentOS 6.8
>
> all builds fine, but when I do run , I get a seg fault
>
> [pedro.vicente@rhw9121 c++]$ cd
> /data/home002/pvicente/plplot/build/examples/c++
> [pedro.vicente@rhw9121 c++]$ ./wxPLplotDemo
> Segmentation fault
>
> I know that only this information is not much help to you to debug, but in
> the next couple of days I'll be debugging this and posting here any
> solution.
>
> my cmake call was
>
> cmake .. -G "Unix Makefiles" -DBUIL
Re: [Plplot-devel] wxPLplotDemo.cpp errors
Hi Phil
I tested on a different setting
Ubuntu i686 GNU/Linux
Using wxWidgets installed from packages
using the PLplot from git
git clone http://git.code.sf.net/p/plplot/plplot plplot-plplot
cd plplot-plplot/
mkdir build
cd build
cmake .. -G "Unix
Makefiles" -DCMAKE_BUILD_TYPE=Debug -DBUILD_SHARED_LIBS:BOOL=OFF
-DENABLE_f95:BOOL=OFF
-DENABLE_tcl:BOOL=OFF -DENABLE_tk:BOOL=OFF
-DCMAKE_INSTALL_PREFIX:PATH=/home/pvn/install/plplot-5.11.1
-DPL_HAVE_PTHREAD:BOOL=OFF -DPLD_xwin:BOOL=OFF -DPLD_wxwidgets:BOOL=ON
-DwxWidgets_ROOT_DIR:PATH=/usr/lib/i386-linux-gnu
-DwxWidgets_LIB_DIR:PATH=/usr/lib/i386-linux-gnu
-DwxWidgets_CONFIGURATION=mswud
-DENABLE_MIX_CXX=ON -DwxWidgets_EXCLUDE_COMMON_LIBRARIES:BOOL=OFF
-DBUILD_TEST:BOOL=ON
>& cmake.txt &
make >& make.txt &
cd /home/pvn/svn/plot/plplot-5.11.1/build/examples/c++/
./wxPLplotDemo
Segmentation fault (core dumped)
-Pedro
- Original Message -
From: "Pedro Vicente"
To: ; "Phil Rosenberg"
Sent: Saturday, December 10, 2016 2:52 AM
Subject: Re: [Plplot-devel] wxPLplotDemo.cpp errors
> Hi Phil
>
> My idea for a fix is to move the stream initialization that is now on
>
> void wxPLplotwindow::OnCreate( wxWindowCreateEvent &event
> {
> if ( !m_created )
>
> either to the OnSize or onPaint events
>
> void wxPLplotwindow::OnSize( wxSizeEvent& WXUNUSED( event ) )
>
> and also in the plot call do this
>
> template< class WXWINDOW >
> void Plot( wxPLplotwindow *plotwindow )
> {
>wxPLplotstream* pls = plotwindow->GetStream();
>
>if (pls == NULL)
>{
> return;
>}
>
>
> Like this , in this sequence
>
>
> wxPLplotwindow *frame = new wxPLplotwindow();
>frame->Create( NULL, wxID_ANY, wxT( "wxPLplotDemo" ) );
>frame->SetIcon( wxIcon( graph ) );
>frame->Show();
>Plot( frame );
>
>
> first we go to
> Plot( frame );
>
> but the stream is NULL because
> :OnCreate
> was not called, but the function returns, avoiding the seg fault
>
> then the window gets a paint or size event, and the stream initialization
> code is called
> at this time I have a PLplot empty black window
>
> but because
> Plot( frame );
> was only called at start, it is not called again, so there is no draw
>
> any ideas here ?
>
> of course making the Plot() call in another app function should work
>
>
> If you could replicate this issue, that would be great.
> I am using CentOS 6.8, PLplot.5.11.1 , wxWidgets 3.1.0
>
>
>
>
>
> - Original Message -
> From: Pedro Vicente
> To: plplot-devel@lists.sourceforge.net ; Phil Rosenberg
> Sent: Saturday, December 10, 2016 12:59 AM
> Subject: Re: [Plplot-devel] wxPLplotDemo.cpp errors
>
>
> Hi Phil
>
> So, the issue seems to be the same that I have been reporting
>
>
> In the wxPLplotDemo.cpp code you have these callling functions
>
>
> wxPLplotwindow *frame = new wxPlDemoFrame();
> frame->Create( NULL, wxID_ANY, wxT( "wxPLplotDemo" ) );
>
>
> that make 2 calls to the PLplot library, or the wxWidgets driver of it
> all these calls are in the header file wxPLplotwindow.h
>
> first the constructor is called
>
> template
> wxPLplotwindow::wxPLplotwindow( bool useGraphicsContext, wxSize
> clientSize )
>: m_created( false ), m_initialSize( clientSize )
>
>
> then this call OnCreate() is called, like you mentioned
> and the !m_created bool makes the initialization of the stream happen
>
> the problem is that this function id *NOT* called on my linux build (it
> is
> on the Windows build)
> so therefore later
> wxPLplotstream* pls = plotwindow->GetStream();
> this is NULL, so therefore it seg faults on the plot calls
>
> //! This is called when the widow is created i.e. after WXWINDOW::Create
> // has been called. We note that this has been called to avoid attempting
> // to redraw a plot on a window that hasn't been created yet.
> template
> void wxPLplotwindow::OnCreate( wxWindowCreateEvent &event )
> {
> if ( !m_created )
>
> so, one quick try is to put the code of
>
> void wxPLplotwindow::OnCreate
> that is not called on the constructor maybe ?
>
> -Pedro
>
> - Original Message -
> From: Pedro Vicente
> To: plplot-devel@lists.sourceforge.net ; Phil Rosenberg
> Sent: Friday, December 09, 2016 11:57 PM
> Subject: [Plplot-devel] wxPLplotDemo.cpp errors
>
>
> Hi Phil
>
> So, resuming the last thread about wxWidgets, what I did was to build and
> run wxPLplotDemo.cpp from PLpplot 5.11.1 on CentOS 6.8
>
> all builds fine, but when I do run , I get a seg fault
>
> [pedro.vicente@rhw9121 c++]$ cd
> /data/home002/pvicente/plplot/build/examples/c++
> [pedro.vicente@rhw9121 c++]$ ./wxPLplotDemo
> Segmentation fault
>
> I know that only this information is not much help to you to debug, but in
> the next couple of days I'll be debugging this and posting here any
> solution.
>
> my cmake call was
>
> cmake .. -G "Unix
> Makefiles" -DBUILD_SHARED_LIBS:BOOL=OFF -DENABLE_f95:BOOL=OFF
> -DENABLE_tcl:BOOL=OFF
> -DENABLE_tk:BOOL=OFF
> -DCMAKE_INSTALL_PREFIX:PATH=/data/data127/pvicente/install/plplot-5.1
Re: [Plplot-devel] wxPLplotDemo.cpp errors
Hi Phil
> I have included the devel list on this email, so the thread will get
> documented on the mailing list.
I have been posting everything to the list
> Am I correct in saying that you are getting this segfault with the
> unchanged demo app?
yes, correct
>It cannot be included in the
> constructor, because the generic nature of the template specification
yes, exactly
>>> I do have access to a CentOS machine at work, although I think I have
> only got access to wxWidgets 2.8 on that system.
I just did a build on Ubuntu with wxWidgets installed from package (not sure
which version, I will check)
see last email
>> I presume you are using 3.1.0 as
> released in February,
yes, on CentOS
-Pedro
- Original Message -
From: "Phil Rosenberg"
To: "Pedro Vicente" ;
Sent: Saturday, December 10, 2016 3:57 AM
Subject: Re: [Plplot-devel] wxPLplotDemo.cpp errors
> Hi Pedro
> I have included the devel list on this email, so the thread will get
> documented on the mailing list.
>
> It is very strange that the OnCreate function is not being called. If
> you are calling Create then you should be generating a create event.
> Am I correct in saying that you are getting this segfault with the
> unchanged demo app?
>
> This location really is the best (and maybe only) place this
> initialisation should be done. It cannot be included in the
> constructor, because the generic nature of the template specification
> means the code in the constructor does not know which type of wxWindow
> we are inheriting from so cannot pass the correct parameters to the
> constructor. By the time OnPaint is called it is really too late,
> because we would like to already have the plot initialised and ready
> to draw and it would be a real pain for you in your code if you had to
> somehow wait for the first paint or resize event.
>
> I do have access to a CentOS machine at work, although I think I have
> only got access to wxWidgets 2.8 on that system. I will check. I may
> be able to build 3.1 from source. I presume you are using 3.1.0 as
> released in February, rather than the head of the master branch?
>
> On 10 December 2016 at 07:52, Pedro Vicente
> wrote:
>> Hi Phil
>>
>> My idea for a fix is to move the stream initialization that is now on
>>
>> void wxPLplotwindow::OnCreate( wxWindowCreateEvent &event
>> {
>> if ( !m_created )
>>
>> either to the OnSize or onPaint events
>>
>> void wxPLplotwindow::OnSize( wxSizeEvent& WXUNUSED( event ) )
>>
>> and also in the plot call do this
>>
>> template< class WXWINDOW >
>> void Plot( wxPLplotwindow *plotwindow )
>> {
>>wxPLplotstream* pls = plotwindow->GetStream();
>>
>>if (pls == NULL)
>>{
>> return;
>>}
>>
>>
>> Like this , in this sequence
>>
>>
>> wxPLplotwindow *frame = new wxPLplotwindow();
>>frame->Create( NULL, wxID_ANY, wxT( "wxPLplotDemo" ) );
>>frame->SetIcon( wxIcon( graph ) );
>>frame->Show();
>>Plot( frame );
>>
>>
>> first we go to
>> Plot( frame );
>>
>> but the stream is NULL because
>> :OnCreate
>> was not called, but the function returns, avoiding the seg fault
>>
>> then the window gets a paint or size event, and the stream initialization
>> code is called
>> at this time I have a PLplot empty black window
>>
>> but because
>> Plot( frame );
>> was only called at start, it is not called again, so there is no draw
>>
>> any ideas here ?
>>
>> of course making the Plot() call in another app function should work
>>
>>
>> If you could replicate this issue, that would be great.
>> I am using CentOS 6.8, PLplot.5.11.1 , wxWidgets 3.1.0
>>
>>
>>
>>
>>
>> - Original Message - From: Pedro Vicente
>> To: plplot-devel@lists.sourceforge.net ; Phil Rosenberg
>> Sent: Saturday, December 10, 2016 12:59 AM
>> Subject: Re: [Plplot-devel] wxPLplotDemo.cpp errors
>>
>>
>> Hi Phil
>>
>> So, the issue seems to be the same that I have been reporting
>>
>>
>> In the wxPLplotDemo.cpp code you have these callling functions
>>
>>
>> wxPLplotwindow *frame = new wxPlDemoFrame();
>> frame->Create( NULL, wxID_ANY, wxT( "wxPLplotDemo" ) );
>>
>>
>> that make 2 calls to the PLplot library, or the wxWidgets driver of it
>> all these calls are in the header file wxPLplotwindow.h
>>
>> first the constructor is called
>>
>> template
>> wxPLplotwindow::wxPLplotwindow( bool useGraphicsContext, wxSize
>> clientSize )
>>: m_created( false ), m_initialSize( clientSize )
>>
>>
>> then this call OnCreate() is called, like you mentioned
>> and the !m_created bool makes the initialization of the stream happen
>>
>> the problem is that this function id *NOT* called on my linux build (it
>> is
>> on the Windows build)
>> so therefore later
>> wxPLplotstream* pls = plotwindow->GetStream();
>>
>> this is NULL, so therefore it seg faults on the plot calls
>>
>> //! This is called when the widow is created i.e. after WXWINDOW::Create
>> // has been called. We note that this has been called to avoid attempting
>> // to redraw a plot on a window
Re: [Plplot-devel] wxPLplotDemo.cpp errors
Hi Phil
>>I do have access to a CentOS machine at work, although I think I have
>>only got access to wxWidgets 2.8 on that system.
What I usually do when I want to quick test on many unices , I install
Virtual Box
https://www.virtualbox.org/
For example on my Windows PC I have a CentOS and Ubuntu as virtual guests
(not the ones I did the PLplot test)
-Pedro
- Original Message -
From: "Phil Rosenberg"
To: "Pedro Vicente" ;
Sent: Saturday, December 10, 2016 3:57 AM
Subject: Re: [Plplot-devel] wxPLplotDemo.cpp errors
> Hi Pedro
> I have included the devel list on this email, so the thread will get
> documented on the mailing list.
>
> It is very strange that the OnCreate function is not being called. If
> you are calling Create then you should be generating a create event.
> Am I correct in saying that you are getting this segfault with the
> unchanged demo app?
>
> This location really is the best (and maybe only) place this
> initialisation should be done. It cannot be included in the
> constructor, because the generic nature of the template specification
> means the code in the constructor does not know which type of wxWindow
> we are inheriting from so cannot pass the correct parameters to the
> constructor. By the time OnPaint is called it is really too late,
> because we would like to already have the plot initialised and ready
> to draw and it would be a real pain for you in your code if you had to
> somehow wait for the first paint or resize event.
>
> I do have access to a CentOS machine at work, although I think I have
> only got access to wxWidgets 2.8 on that system. I will check. I may
> be able to build 3.1 from source. I presume you are using 3.1.0 as
> released in February, rather than the head of the master branch?
>
> On 10 December 2016 at 07:52, Pedro Vicente
> wrote:
>> Hi Phil
>>
>> My idea for a fix is to move the stream initialization that is now on
>>
>> void wxPLplotwindow::OnCreate( wxWindowCreateEvent &event
>> {
>> if ( !m_created )
>>
>> either to the OnSize or onPaint events
>>
>> void wxPLplotwindow::OnSize( wxSizeEvent& WXUNUSED( event ) )
>>
>> and also in the plot call do this
>>
>> template< class WXWINDOW >
>> void Plot( wxPLplotwindow *plotwindow )
>> {
>>wxPLplotstream* pls = plotwindow->GetStream();
>>
>>if (pls == NULL)
>>{
>> return;
>>}
>>
>>
>> Like this , in this sequence
>>
>>
>> wxPLplotwindow *frame = new wxPLplotwindow();
>>frame->Create( NULL, wxID_ANY, wxT( "wxPLplotDemo" ) );
>>frame->SetIcon( wxIcon( graph ) );
>>frame->Show();
>>Plot( frame );
>>
>>
>> first we go to
>> Plot( frame );
>>
>> but the stream is NULL because
>> :OnCreate
>> was not called, but the function returns, avoiding the seg fault
>>
>> then the window gets a paint or size event, and the stream initialization
>> code is called
>> at this time I have a PLplot empty black window
>>
>> but because
>> Plot( frame );
>> was only called at start, it is not called again, so there is no draw
>>
>> any ideas here ?
>>
>> of course making the Plot() call in another app function should work
>>
>>
>> If you could replicate this issue, that would be great.
>> I am using CentOS 6.8, PLplot.5.11.1 , wxWidgets 3.1.0
>>
>>
>>
>>
>>
>> - Original Message - From: Pedro Vicente
>> To: plplot-devel@lists.sourceforge.net ; Phil Rosenberg
>> Sent: Saturday, December 10, 2016 12:59 AM
>> Subject: Re: [Plplot-devel] wxPLplotDemo.cpp errors
>>
>>
>> Hi Phil
>>
>> So, the issue seems to be the same that I have been reporting
>>
>>
>> In the wxPLplotDemo.cpp code you have these callling functions
>>
>>
>> wxPLplotwindow *frame = new wxPlDemoFrame();
>> frame->Create( NULL, wxID_ANY, wxT( "wxPLplotDemo" ) );
>>
>>
>> that make 2 calls to the PLplot library, or the wxWidgets driver of it
>> all these calls are in the header file wxPLplotwindow.h
>>
>> first the constructor is called
>>
>> template
>> wxPLplotwindow::wxPLplotwindow( bool useGraphicsContext, wxSize
>> clientSize )
>>: m_created( false ), m_initialSize( clientSize )
>>
>>
>> then this call OnCreate() is called, like you mentioned
>> and the !m_created bool makes the initialization of the stream happen
>>
>> the problem is that this function id *NOT* called on my linux build (it
>> is
>> on the Windows build)
>> so therefore later
>> wxPLplotstream* pls = plotwindow->GetStream();
>>
>> this is NULL, so therefore it seg faults on the plot calls
>>
>> //! This is called when the widow is created i.e. after WXWINDOW::Create
>> // has been called. We note that this has been called to avoid attempting
>> // to redraw a plot on a window that hasn't been created yet.
>> template
>> void wxPLplotwindow::OnCreate( wxWindowCreateEvent &event )
>> {
>> if ( !m_created )
>>
>> so, one quick try is to put the code of
>>
>> void wxPLplotwindow::OnCreate
>> that is not called on the constructor maybe ?
>>
>> -Pedro
>>
>> - Original Message - From: Pedro Vicente
>> To: plplot-devel@li
Re: [Plplot-devel] More on IPC
Hi Phil: If you review my results from much earlier this year that had a screen shot attached in the next e-mail of my cpumeter results, the test being run was for a case with absolutely no text data being written to wxPLViewer. So your concern (expressed off list to me) about the efficiency of IPC of text may be well taken, but they are not relevant to this particular result of huge idle times. Your other thought that inefficient IPC method may not be the direct cause of this issue is likely correct. For why, read on. One working hypothesis I could think of to generate these excessive idle times on Linux is that shared memory is not being shm_unlink'd properly so we have a shared memory leak that in a heavy-duty testing environment (such as when building the test_c_wxwidgets target) means the Linux kernel is soon right up against it (since it probably only allows a rather small proportion of actual memory to be used for the special purpose of shared memory). So the extraordinary measures that would be needed to supply shared memory ==> huge idle times. To investigate that possibility further I introduced (as of commit dcae24e) rudimentary but proper debug reporting of when the creation of shared memory is a success. I also did that for the shm_unlink call (but only for the case when there is success for PLMemoryMap::create followed by a call to PLMemoryMap::close). The results from building the test_c_wxwidgets target (before I ^C'd out of it) are as follows: Testing subset of C examples for device wxwidgets x01c PLMemoryMap::create: shm_open was a success for plplotMemoryMapIFWDQVRLBF PLMemoryMap::create: shm_open was a success for plplotMemoryMapIFWDQVRLBF PLMemoryMap::close: shm_unlink was a success for plplotMemoryMapIFWDQVRLBF x04c PLMemoryMap::create: shm_open was a success for plplotMemoryMapBTDCASTECJ PLMemoryMap::create: shm_open was a success for plplotMemoryMapBTDCASTECJ PLMemoryMap::close: shm_unlink was a success for plplotMemoryMapBTDCASTECJ PLMemoryMap::close: shm_unlink error PLMemoryMap::close: No such file or directory x08c PLMemoryMap::create: shm_open was a success for plplotMemoryMapYKNFFXNKGJ PLMemoryMap::create: shm_open was a success for plplotMemoryMapYKNFFXNKGJ PLMemoryMap::close: shm_unlink was a success for plplotMemoryMapYKNFFXNKGJ PLMemoryMap::close: shm_unlink error PLMemoryMap::close: No such file or directory x14c PLMemoryMap::create: shm_open was a success for plplotMemoryMapNYBYKUHKXR PLMemoryMap::create: shm_open was a success for plplotMemoryMapNYBYKUHKXR PLMemoryMap::create: shm_open was a success for plplotMemoryMapIJIAMCSBUP PLMemoryMap::create: shm_open was a success for plplotMemoryMapIJIAMCSBUP PLMemoryMap::close: shm_unlink was a success for plplotMemoryMapIJIAMCSBUP PLMemoryMap::close: shm_unlink was a success for plplotMemoryMapNYBYKUHKXR x16c PLMemoryMap::create: shm_open was a success for plplotMemoryMapQPXDPGRVTF PLMemoryMap::create: shm_open was a success for plplotMemoryMapQPXDPGRVTF PLMemoryMap::close: shm_unlink was a success for plplotMemoryMapQPXDPGRVTF PLMemoryMap::close: shm_unlink error PLMemoryMap::close: No such file or directory x17c ^C So these results completely shoot down that hypothesis because for every successful shm_open of a particular name there is also a successful shm_unlink for that same name ==> no shared memory leak! Oh well, on to the next idea. :-) For a bit I was excited about the above shm_unlink error messages that are also emitted for all but the first and 14th examples, but I now believe that pattern is the expected one, i.e., -dev wxwidgets finishes so it calls the PLMemoryMap destructor or PLMemoryMap::close directly which destroys the shared memory. Then wxPLViewer finishes so when it calls the PLMemoryMap destructor or PLMemoryMap::close directly those error messages must be emitted. But I frankly do not understand why no such error messages were emitted for the first and 14th examples. Yet for the first example experiments below, the error messages are always emitted. I have rerun both types of tests any number of times and these patterns always repeat. But I cannot figure out why different error messages are emitted for x01c results in the two contexts. Do you have some intelligent guess or even definitive response about that? Note the above form of results always take a very long time to create so the excessive idle time is still with us. In fact to see that directly, I ran x01c twice in a row as follows: software@raven> time examples/c/x01c -dev wxwidgets -np; echo "done x01c"; time examples/c/x01c -dev wxwidgets -np;echo "done x01c" PLplot library version: 5.11.1 PLMemoryMap::create: shm_open was a success for plplotMemoryMapRZZQSYHRAO PLMemoryMap::create: shm_open was a success for plplotMemoryMapRZZQSYHRAO PLMemoryMap::close: shm_unlink was a success for plplotMemoryMapRZZQSYHRAO real0m0.258s user0m0.040s sys 0m0.016s done x01c PLplot library version: 5.11.1 PLMemoryMap::close:
Re: [Plplot-devel] Soft freeze on December 3rd and release on December 17th?
On 2016-12-09 18:02-0500 Pedro Vicente wrote: > ok, simple issue , ignore > > I tool a quick look at the ouput , it's just > > > CMake 3.0.2 or higher is required. You are running version 2.8.12.2 OK. So please fix that (run scripts/comprehensive_test.sh --help to see how to specify the cmake command exactly). Once you run scripts/comprehensive_test.sh with the correct cmake, then as I suggested before please follow up by sending me the report tarball to help figure out what is wrong for the wxwidgets case on CentOS. 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
Re: [Plplot-devel] Soft freeze on December 3rd and release on December 17th?
On 2016-12-10 05:08-0800 Alan W. Irwin wrote: > On 2016-12-09 18:02-0500 Pedro Vicente wrote: > >> ok, simple issue , ignore >> >> I tool a quick look at the ouput , it's just >> >> >> CMake 3.0.2 or higher is required. You are running version 2.8.12.2 > > OK. So please fix that (run scripts/comprehensive_test.sh --help to > see how to specify the cmake command exactly). Once you run > scripts/comprehensive_test.sh with the correct cmake, then as I > suggested before please follow up by sending me the report tarball to > help figure out what is wrong for the wxwidgets case on CentOS. Never mind. I should have checked my incoming mail first to see you have gone another way. But in general, creating a report tarball is a good way to report errors since it gives all sorts of details that otherwise are a pain to collect consistently for an error report. 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
Re: [Plplot-devel] More on IPC
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. Thanks again Phil Sent from my Windows 10 phone From: Alan W. Irwin Sent: 10 December 2016 13:00 To: Phil Rosenberg Cc: PLplot development list Subject: Re: More on IPC Hi Phil: If you review my results from much earlier this year that had a screen shot attached in the next e-mail of my cpumeter results, the test being run was for a case with absolutely no text data being written to wxPLViewer. So your concern (expressed off list to me) about the efficiency of IPC of text may be well taken, but they are not relevant to this particular result of huge idle times. Your other thought that inefficient IPC method may not be the direct cause of this issue is likely correct. For why, read on. One working hypothesis I could think of to generate these excessive idle times on Linux is that shared memory is not being shm_unlink'd properly so we have a shared memory leak that in a heavy-duty testing environment (such as when building the test_c_wxwidgets target) means the Linux kernel is soon right up against it (since it probably only allows a rather small proportion of actual memory to be used for the special purpose of shared memory). So the extraordinary measures that would be needed to supply shared memory ==> huge idle times. To investigate that possibility further I introduced (as of commit dcae24e) rudimentary but proper debug reporting of when the creation of shared memory is a success. I also did that for the shm_unlink call (but only for the case when there is success for PLMemoryMap::create followed by a call to PLMemoryMap::close). The results from building the test_c_wxwidgets target (before I ^C'd out of it) are as follows: Testing subset of C examples for device wxwidgets x01c PLMemoryMap::create: shm_open was a success for plplotMemoryMapIFWDQVRLBF PLMemoryMap::create: shm_open was a success for plplotMemoryMapIFWDQVRLBF PLMemoryMap::close: shm_unlink was a success for plplotMemoryMapIFWDQVRLBF x04c PLMemoryMap::create: shm_open was a success for plplotMemoryMapBTDCASTECJ PLMemoryMap::create: shm_open was a success for plplotMemoryMapBTDCASTECJ PLMemoryMap::close: shm_unlink was a success for plplotMemoryMapBTDCASTECJ PLMemoryMap::close: shm_unlink error PLMemoryMap::close: No such file or directory x08c PLMemoryMap::create: shm_open was a success for plplotMemoryMapYKNFFXNKGJ PLMemoryMap::create: shm_open was a success for plplotMemoryMapYKNFFXNKGJ PLMemoryMap::close: shm_unlink was a success for plplotMemoryMapYKNFFXNKGJ PLMemoryMap::close: shm_unlink error PLMemoryMap::close: No such file or directory x14c PLMemoryMap::create: shm_open was a success for plplotMemoryMapNYBYKUHKXR PLMemoryMap::create: shm_open was a success for plplotMemoryMapNYBYKUHKXR PLMemoryMap::create: shm_open was a success for plplotMemoryMapIJIAMCSBUP PLMemoryMap::create: shm_open was a success for plplotMemoryMapIJIAMCSBUP PLMemoryMap::close: shm_unlink was a success for plplotMemoryMapIJIAMCSBUP PLMemoryMap::close: shm_unlink was a success for plplotMemoryMapNYBYKUHKXR x16c PLMemoryMap::create: shm_open was a success for plplotMemoryMapQPXDPGRVTF PLMemoryMap::create: shm_open was a success for plplotMemoryMapQPXDPGRVTF PLMemoryMap::close: shm_unlink was a success for plplotMemoryMapQPXDPGRVTF PLMemoryMap::close: shm_unlink error PLMemoryMap::close: No such file or directory x17c ^C So these results completely shoot down that hypothesis because for every successful shm_open of a particular name there is also a successful shm_unlink for that same name ==> no shared memory leak! Oh well, on to the next idea. :-) For a bit I was excited about the above shm_unlink error messages that are also emitted for all but the first and 14th examples, but I now believe that pattern is the expected one, i.e., -dev wxwidgets finishes so it calls the PLMemoryMap destructor or PLMemoryMap::close directly which destroys the shared memory. Then wxPLViewer finishes so when it calls the PLMemoryMap destructor or PLMemoryMap::close directly those error messages must be emitted. But I frankly do not un
Re: [Plplot-devel] build plplot using CMAKE using MSYS makefiles on windows 10
Hi phil,
Thanks for your answer.
I have try to solve problem in a bad way :
I have changed some lines in pkg-config.cmake : line298--305 are now :
if(_list_element STREQUAL "-l${_list_element1}")
set(_library_pathname "_library_pathname-NOTFOUND")
find_library(
_library_pathname
${_list_element1}
PATHS ${_link_directory_list} "f:/lib/wxWidgets-3.1.0/lib"
"F:/mingw-w64/x86_64-6.2.0-posix-sjlj-rt_v5-rev1/mingw64/x86_64-w64-mingw32/lib32"
NO_DEFAULT_PATH
)
I can start build plplot using MSYS-mingw64. Now I have some compilation
errors and try to understand it
$ make
[ 3%] Built target csirocsa
[ 6%] Built target deltaT-gen
[ 7%] Built target deltaT.h_built
[ 9%] Built target tai-utc-gen
[ 10%] Built target tai-utc.h_built
[ 15%] Built target qsastime
[ 16%] Built target plhershey-unicode-gen
[ 18%] Built target plhershey-unicode.h_built
[ 19%] Building CXX object
src/CMakeFiles/plplot.dir/__/drivers/wxwidgets_comms.cpp.obj
In file included from
F:/mingw-w64/x86_64-6.2.0-posix-sjlj-rt_v5-rev1/mingw64/x86_64-w64-mingw32/include/Windows.h:72:0,
from G:/Lib/plplot/drivers/wxwidgets_comms.h:25,
from G:/Lib/plplot/drivers/wxwidgets_comms.cpp:20:
F:/lib/wxWidgets-3.1.0/include/wx/msw/winundef.h: In function 'HWND__*
CreateDialog(HINSTANCE, LPCTSTR, HWND, DLGPROC)':
F:/lib/wxWidgets-3.1.0/include/wx/msw/winundef.h:38:20: error: cannot
convert 'LPCTSTR {aka const char*}' to 'LPCWSTR {aka const wchar_t*}'
for argument '2' to 'HWND__* CreateDialogParamW(HINSTANCE, LPCWSTR,
HWND, DLGPROC, LPARAM)'
return CreateDialogW(hInstance, pTemplate, hwndParent,
pDlgProc);
^
In file included from F:/lib/wxWidgets-3.1.0/include/wx/defs.h:3302:0,
from F:/lib/wxWidgets-3.1.0/include/wx/font.h:18,
from G:/Lib/plplot/drivers/wxwidgets_comms.h:34,
from G:/Lib/plplot/drivers/wxwidgets_comms.cpp:20:
F:/lib/wxWidgets-3.1.0/include/wx/msw/winundef.h: In function 'HFONT__*
CreateFont(int, int, int, int, int, DWORD, DWORD, DWORD, DWORD, DWORD,
DWORD, DWORD, DWORD, LPCTSTR)':
F:/lib/wxWidgets-3.1.0/include/wx/msw/winundef.h:69:48: error: cannot
convert 'LPCTSTR {aka const char*}' to 'LPCWSTR {aka const wchar_t*}'
for argument '14' to 'HFONT__* CreateFontW(int, int, int, int, int,
DWORD, DWORD, DWORD, DWORD, DWORD, DWORD, DWORD, DWORD, LPCWSTR)'
family, facename);
^
In file included from
F:/mingw-w64/x86_64-6.2.0-posix-sjlj-rt_v5-rev1/mingw64/x86_64-w64-mingw32/include/Windows.h:72:0,
from G:/Lib/plplot/drivers/wxwidgets_comms.h:25,
from G:/Lib/plplot/drivers/wxwidgets_comms.cpp:20:
F:/lib/wxWidgets-3.1.0/include/wx/msw/winundef.h: In function 'HWND__*
CreateWindow(LPCTSTR, LPCTSTR, DWORD, int, int, int, int, HWND, HMENU,
HINSTANCE, LPVOID)':
F:/lib/wxWidgets-3.1.0/include/wx/msw/winundef.h:94:20: error: cannot
convert 'LPCTSTR {aka const char*}' to 'LPCWSTR {aka const wchar_t*}'
for argument '2' to 'HWND__* CreateWindowExW(DWORD, LPCWSTR, LPCWSTR,
DWORD, int, int, int, int, HWND, HMENU, HINSTANCE, LPVOID)'
return CreateWindowW(lpClassName, lpWndClass, dwStyle, x,
y, w, h,
^
In file included from F:/lib/wxWidgets-3.1.0/include/wx/defs.h:3302:0,
from F:/lib/wxWidgets-3.1.0/include/wx/font.h:18,
from G:/Lib/plplot/drivers/wxwidgets_comms.h:34,
from G:/Lib/plplot/drivers/wxwidgets_comms.cpp:20:
F:/lib/wxWidgets-3.1.0/include/wx/msw/winundef.h: In function 'HMENU__*
LoadMenu(HINSTANCE, LPCTSTR)':
F:/lib/wxWidgets-3.1.0/include/wx/msw/winundef.h:111:44: error: cannot
convert 'LPCTSTR {aka const char*}' to 'LPCWSTR {aka const wchar_t*}'
for argument '2' to 'HMENU__* LoadMenuW(HINSTANCE, LPCWSTR)'
return LoadMenuW(instance, name);
^
F:/lib/wxWidgets-3.1.0/include/wx/msw/winundef.h: In function 'HWND__*
FindText(LPFINDREPLACE)':
F:/lib/wxWidgets-3.1.0/include/wx/msw/winundef.h:126:43: error: cannot
convert 'LPFINDREPLACE {aka tagFINDREPLACEA*}' to 'LPFINDREPLACEW {aka
tagFINDREPLACEW*}' for argument '1' to 'HWND__* FindTextW(LPFINDREPLACEW)'
return FindTextW(lpfindreplace);
^
F:/lib/wxWidgets-3.1.0/include/wx/msw/winundef.h: In function 'HICON__*
LoadIcon(HINSTANCE, LPCTSTR)':
F:/lib/wxWidgets-3.1.0/include/wx/msw/winundef.h:311:51: error: cannot
convert 'LPCTSTR {aka const char*}' to 'LPCWSTR {aka const wchar_t*}'
for argument '2' to 'HICON__* LoadIconW(HINSTANCE, LPCWSTR)'
return LoadIconW(hInstance, lpIconName);
^
F:/lib/wxWidgets-3.1.0/include/wx/msw/winundef.h: In function
'HBITMAP__* LoadBitmap(HINSTANCE, LPCTSTR)':
F:/lib/w
Re: [Plplot-devel] build plplot using CMAKE using MSYS makefiles on windows 10
An error in path but error is still here :
if(_list_element STREQUAL "-l${_list_element1}")
set(_library_pathname "_library_pathname-NOTFOUND")
find_library(
_library_pathname
${_list_element1}
PATHS ${_link_directory_list} "f:/lib/wxWidgets-3.1.0/lib"
"F:/mingw-w64/x86_64-6.2.0-posix-sjlj-rt_v5-rev1/mingw64/x86_64-w64-mingw32/lib"
NO_DEFAULT_PATH
)
and make clean and make gives
make
[ 1%] Building C object lib/csa/CMakeFiles/csirocsa.dir/csa.c.obj
[ 3%] Linking C static library libcsirocsa.a
[ 3%] Built target csirocsa
[ 3%] Building C object
lib/qsastime/CMakeFiles/deltaT-gen.dir/deltaT-gen.c.obj
[ 4%] Building C object
lib/qsastime/CMakeFiles/deltaT-gen.dir/dspline.c.obj
[ 6%] Linking C executable deltaT-gen.exe
[ 6%] Built target deltaT-gen
[ 7%] Generating deltaT.h
[ 7%] Built target deltaT.h_built
[ 9%] Building C object
lib/qsastime/CMakeFiles/tai-utc-gen.dir/tai-utc-gen.c.obj
[ 9%] Linking C executable tai-utc-gen.exe
[ 9%] Built target tai-utc-gen
[ 10%] Generating tai-utc.h
[ 10%] Built target tai-utc.h_built
Scanning dependencies of target qsastime
[ 12%] Building C object lib/qsastime/CMakeFiles/qsastime.dir/qsastime.c.obj
[ 13%] Building C object lib/qsastime/CMakeFiles/qsastime.dir/dsplint.c.obj
[ 15%] Linking C static library libqsastime.a
[ 15%] Built target qsastime
[ 15%] Building C object
include/CMakeFiles/plhershey-unicode-gen.dir/__/fonts/plhershey-unicode-gen.c.obj
[ 16%] Linking C executable plhershey-unicode-gen.exe
[ 16%] Built target plhershey-unicode-gen
[ 18%] Generating plhershey-unicode.h
[ 18%] Built target plhershey-unicode.h_built
Scanning dependencies of target plplot
[ 19%] Building C object src/CMakeFiles/plplot.dir/pdfutils.c.obj
[ 21%] Building C object src/CMakeFiles/plplot.dir/plmem.c.obj
[ 21%] Building C object src/CMakeFiles/plplot.dir/plaffine.c.obj
[ 22%] Building C object src/CMakeFiles/plplot.dir/plarc.c.obj
[ 24%] Building C object src/CMakeFiles/plplot.dir/plargs.c.obj
[ 25%] Building C object src/CMakeFiles/plplot.dir/plbox.c.obj
[ 27%] Building C object src/CMakeFiles/plplot.dir/plcont.c.obj
[ 28%] Building C object src/CMakeFiles/plplot.dir/plcore.c.obj
[ 28%] Building C object src/CMakeFiles/plplot.dir/plctrl.c.obj
[ 30%] Building C object src/CMakeFiles/plplot.dir/plcvt.c.obj
[ 31%] Building C object src/CMakeFiles/plplot.dir/pldtik.c.obj
[ 33%] Building C object src/CMakeFiles/plplot.dir/plf2ops.c.obj
[ 34%] Building C object src/CMakeFiles/plplot.dir/plfill.c.obj
[ 34%] Building C object src/CMakeFiles/plplot.dir/plfreetype.c.obj
[ 36%] Building C object src/CMakeFiles/plplot.dir/plgradient.c.obj
[ 37%] Building C object src/CMakeFiles/plplot.dir/plhist.c.obj
[ 39%] Building C object src/CMakeFiles/plplot.dir/plimage.c.obj
[ 40%] Building C object src/CMakeFiles/plplot.dir/plline.c.obj
[ 40%] Building C object src/CMakeFiles/plplot.dir/plmetafile.c.obj
[ 42%] Building C object src/CMakeFiles/plplot.dir/plot3d.c.obj
[ 43%] Building C object src/CMakeFiles/plplot.dir/plpage.c.obj
[ 45%] Building C object src/CMakeFiles/plplot.dir/plsdef.c.obj
[ 46%] Building C object src/CMakeFiles/plplot.dir/plshade.c.obj
[ 48%] Building C object src/CMakeFiles/plplot.dir/plstdio.c.obj
[ 48%] Building C object src/CMakeFiles/plplot.dir/plstripc.c.obj
[ 50%] Building C object src/CMakeFiles/plplot.dir/plsym.c.obj
[ 51%] Building C object src/CMakeFiles/plplot.dir/pltick.c.obj
[ 53%] Building C object src/CMakeFiles/plplot.dir/plvpor.c.obj
[ 54%] Building C object src/CMakeFiles/plplot.dir/plwind.c.obj
[ 54%] Building C object src/CMakeFiles/plplot.dir/plbuf.c.obj
[ 56%] Building C object src/CMakeFiles/plplot.dir/plgridd.c.obj
[ 57%] Building C object src/CMakeFiles/plplot.dir/plvect.c.obj
[ 59%] Building C object src/CMakeFiles/plplot.dir/mt19937ar.c.obj
[ 60%] Building C object src/CMakeFiles/plplot.dir/pltime.c.obj
[ 60%] Building C object src/CMakeFiles/plplot.dir/pllegend.c.obj
[ 62%] Building C object src/CMakeFiles/plplot.dir/plmap.c.obj
[ 63%] Building C object src/CMakeFiles/plplot.dir/__/drivers/mem.c.obj
[ 65%] Building C object src/CMakeFiles/plplot.dir/__/drivers/null.c.obj
[ 66%] Building C object src/CMakeFiles/plplot.dir/__/drivers/ps.c.obj
[ 68%] Building C object src/CMakeFiles/plplot.dir/__/drivers/svg.c.obj
[ 68%] Building C object src/CMakeFiles/plplot.dir/__/drivers/wingcc.c.obj
[ 69%] Building CXX object
src/CMakeFiles/plplot.dir/__/drivers/wxwidgets.cpp.obj
[ 71%] Building CXX object
src/CMakeFiles/plplot.dir/__/drivers/wxwidgets_comms.cpp.obj
In file included from
F:/mingw-w64/x86_64-6.2.0-posix-sjlj-rt_v5-rev1/mingw64/x86_64-w64-mingw32/include/Windows.h:72:0,
from G:/Lib/plplot/drivers/wxwidgets_comms.h:25,
from G:/Lib/plplot/drivers/wxwidgets_comms.cpp:20:
F:/lib/wxWidgets-3.1.0/include/wx/msw/winundef.h: In function 'HWND__*
CreateDialog(HINSTANCE, LPCTSTR, HWND, DLGPROC)':
F:/lib/wxWidgets-3.1.0/include/w
Re: [Plplot-devel] build plplot using CMAKE using MSYS makefiles onwindows 10
Hi Laurent
So those errors seem to be caused by unicode issues. The native windows
functions have ansi versions which accept 8bit strings and unicode versions
which accept 16 bit wide strings. There is also a generic form of each which
uses #ifdefs which call the ansi or unicode versions depending on whether
_UNICODE is #defined. You can see from the w suffix that the wide version is
being used, however 8bit strings appear to be being passed in from wxWidgets.
This is really rather surprising. wxWidgets hasn't really used ansi strings
since v2.8. I have a feeling there may be a legacy option to build with ansi
strings, but I haven't tried this, nor do i know how well it works.
Is it possible you have built or attempted to build the ansi version of
wxWidgets and somewhere it is getting confused?
Phil
Sent from my Windows 10 phone
From: Laurent Berger
Sent: 10 December 2016 14:58
To: Phil Rosenberg
Cc: PLplot development list
Subject: Re: [Plplot-devel] build plplot using CMAKE using MSYS makefiles
onwindows 10
Hi phil,
Thanks for your answer.
I have try to solve problem in a bad way :
I have changed some lines in pkg-config.cmake : line298--305 are now :
if(_list_element STREQUAL "-l${_list_element1}")
set(_library_pathname "_library_pathname-NOTFOUND")
find_library(
_library_pathname
${_list_element1}
PATHS ${_link_directory_list} "f:/lib/wxWidgets-3.1.0/lib"
"F:/mingw-w64/x86_64-6.2.0-posix-sjlj-rt_v5-rev1/mingw64/x86_64-w64-mingw32/lib32"
NO_DEFAULT_PATH
)
I can start build plplot using MSYS-mingw64. Now I have some compilation
errors and try to understand it
$ make
[ 3%] Built target csirocsa
[ 6%] Built target deltaT-gen
[ 7%] Built target deltaT.h_built
[ 9%] Built target tai-utc-gen
[ 10%] Built target tai-utc.h_built
[ 15%] Built target qsastime
[ 16%] Built target plhershey-unicode-gen
[ 18%] Built target plhershey-unicode.h_built
[ 19%] Building CXX object
src/CMakeFiles/plplot.dir/__/drivers/wxwidgets_comms.cpp.obj
In file included from
F:/mingw-w64/x86_64-6.2.0-posix-sjlj-rt_v5-rev1/mingw64/x86_64-w64-mingw32/include/Windows.h:72:0,
from G:/Lib/plplot/drivers/wxwidgets_comms.h:25,
from G:/Lib/plplot/drivers/wxwidgets_comms.cpp:20:
F:/lib/wxWidgets-3.1.0/include/wx/msw/winundef.h: In function 'HWND__*
CreateDialog(HINSTANCE, LPCTSTR, HWND, DLGPROC)':
F:/lib/wxWidgets-3.1.0/include/wx/msw/winundef.h:38:20: error: cannot
convert 'LPCTSTR {aka const char*}' to 'LPCWSTR {aka const wchar_t*}'
for argument '2' to 'HWND__* CreateDialogParamW(HINSTANCE, LPCWSTR,
HWND, DLGPROC, LPARAM)'
return CreateDialogW(hInstance, pTemplate, hwndParent,
pDlgProc);
^
In file included from F:/lib/wxWidgets-3.1.0/include/wx/defs.h:3302:0,
from F:/lib/wxWidgets-3.1.0/include/wx/font.h:18,
from G:/Lib/plplot/drivers/wxwidgets_comms.h:34,
from G:/Lib/plplot/drivers/wxwidgets_comms.cpp:20:
F:/lib/wxWidgets-3.1.0/include/wx/msw/winundef.h: In function 'HFONT__*
CreateFont(int, int, int, int, int, DWORD, DWORD, DWORD, DWORD, DWORD,
DWORD, DWORD, DWORD, LPCTSTR)':
F:/lib/wxWidgets-3.1.0/include/wx/msw/winundef.h:69:48: error: cannot
convert 'LPCTSTR {aka const char*}' to 'LPCWSTR {aka const wchar_t*}'
for argument '14' to 'HFONT__* CreateFontW(int, int, int, int, int,
DWORD, DWORD, DWORD, DWORD, DWORD, DWORD, DWORD, DWORD, LPCWSTR)'
family, facename);
^
In file included from
F:/mingw-w64/x86_64-6.2.0-posix-sjlj-rt_v5-rev1/mingw64/x86_64-w64-mingw32/include/Windows.h:72:0,
from G:/Lib/plplot/drivers/wxwidgets_comms.h:25,
from G:/Lib/plplot/drivers/wxwidgets_comms.cpp:20:
F:/lib/wxWidgets-3.1.0/include/wx/msw/winundef.h: In function 'HWND__*
CreateWindow(LPCTSTR, LPCTSTR, DWORD, int, int, int, int, HWND, HMENU,
HINSTANCE, LPVOID)':
F:/lib/wxWidgets-3.1.0/include/wx/msw/winundef.h:94:20: error: cannot
convert 'LPCTSTR {aka const char*}' to 'LPCWSTR {aka const wchar_t*}'
for argument '2' to 'HWND__* CreateWindowExW(DWORD, LPCWSTR, LPCWSTR,
DWORD, int, int, int, int, HWND, HMENU, HINSTANCE, LPVOID)'
return CreateWindowW(lpClassName, lpWndClass, dwStyle, x,
y, w, h,
^
In file included from F:/lib/wxWidgets-3.1.0/include/wx/defs.h:3302:0,
from F:/lib/wxWidgets-3.1.0/include/wx/font.h:18,
from G:/Lib/plplot/drivers/wxwidgets_comms.h:34,
from G:/Lib/plplot/drivers/wxwidgets_comms.cpp:20:
F:/lib/wxWidgets-3.1.0/include/wx/msw/winundef.h: In function 'HMENU__*
LoadMenu(HINSTANCE, LPCTSTR)':
F:/lib/wxWidgets-3.1.0/include/wx/msw/winundef.h:111:44: error: cannot
convert 'LPCTSTR {aka const char*}' to 'LPCWSTR {aka const wchar_t*}'
for argument '2' to 'HMENU__* LoadMenuW(HINSTANCE, LPCWSTR)
Re: [Plplot-devel] wxPLplotDemo.cpp errors
Hi Phil
I tested on a third Linux, with libwxgtk3.0-dev from package (the latest
ubuntu package)
uname -a
Linux glace 3.13.0-92-generic #139-Ubuntu SMP Tue Jun 28 20:42:26 UTC 2016
x86_64 x86_64 x86_64 GNU/Linux
lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 14.04.5 LTS
Release: 14.04
Codename: trusty
then
git clone http://git.code.sf.net/p/plplot/plplot plplot-plplot
sudo apt-get install libwxgtk3.0-dev
cd plplot-plplot/build/
cmake .. -DBUILD_TEST=ON -DENABLE_f95:BOOL=OFF
make
cd /home/pvicente/plplot-plplot/build/examples/c++
pvicente@glace:~/plplot-plplot/build/examples/c++$ ./wxPLplotDemo
Segmentation fault (core dumped)
- Original Message -
From: "Pedro Vicente"
To: "Phil Rosenberg" ;
Sent: Saturday, December 10, 2016 4:18 AM
Subject: Re: [Plplot-devel] wxPLplotDemo.cpp errors
> Hi Phil
>
>>>I do have access to a CentOS machine at work, although I think I have
>>>only got access to wxWidgets 2.8 on that system.
>
> What I usually do when I want to quick test on many unices , I install
> Virtual Box
>
> https://www.virtualbox.org/
>
> For example on my Windows PC I have a CentOS and Ubuntu as virtual guests
> (not the ones I did the PLplot test)
>
> -Pedro
>
>
>
>
> - Original Message -
> From: "Phil Rosenberg"
> To: "Pedro Vicente" ;
>
> Sent: Saturday, December 10, 2016 3:57 AM
> Subject: Re: [Plplot-devel] wxPLplotDemo.cpp errors
>
>
>> Hi Pedro
>> I have included the devel list on this email, so the thread will get
>> documented on the mailing list.
>>
>> It is very strange that the OnCreate function is not being called. If
>> you are calling Create then you should be generating a create event.
>> Am I correct in saying that you are getting this segfault with the
>> unchanged demo app?
>>
>> This location really is the best (and maybe only) place this
>> initialisation should be done. It cannot be included in the
>> constructor, because the generic nature of the template specification
>> means the code in the constructor does not know which type of wxWindow
>> we are inheriting from so cannot pass the correct parameters to the
>> constructor. By the time OnPaint is called it is really too late,
>> because we would like to already have the plot initialised and ready
>> to draw and it would be a real pain for you in your code if you had to
>> somehow wait for the first paint or resize event.
>>
>> I do have access to a CentOS machine at work, although I think I have
>> only got access to wxWidgets 2.8 on that system. I will check. I may
>> be able to build 3.1 from source. I presume you are using 3.1.0 as
>> released in February, rather than the head of the master branch?
>>
>> On 10 December 2016 at 07:52, Pedro Vicente
>> wrote:
>>> Hi Phil
>>>
>>> My idea for a fix is to move the stream initialization that is now on
>>>
>>> void wxPLplotwindow::OnCreate( wxWindowCreateEvent &event
>>> {
>>> if ( !m_created )
>>>
>>> either to the OnSize or onPaint events
>>>
>>> void wxPLplotwindow::OnSize( wxSizeEvent& WXUNUSED( event ) )
>>>
>>> and also in the plot call do this
>>>
>>> template< class WXWINDOW >
>>> void Plot( wxPLplotwindow *plotwindow )
>>> {
>>>wxPLplotstream* pls = plotwindow->GetStream();
>>>
>>>if (pls == NULL)
>>>{
>>> return;
>>>}
>>>
>>>
>>> Like this , in this sequence
>>>
>>>
>>> wxPLplotwindow *frame = new wxPLplotwindow();
>>>frame->Create( NULL, wxID_ANY, wxT( "wxPLplotDemo" ) );
>>>frame->SetIcon( wxIcon( graph ) );
>>>frame->Show();
>>>Plot( frame );
>>>
>>>
>>> first we go to
>>> Plot( frame );
>>>
>>> but the stream is NULL because
>>> :OnCreate
>>> was not called, but the function returns, avoiding the seg fault
>>>
>>> then the window gets a paint or size event, and the stream
>>> initialization
>>> code is called
>>> at this time I have a PLplot empty black window
>>>
>>> but because
>>> Plot( frame );
>>> was only called at start, it is not called again, so there is no draw
>>>
>>> any ideas here ?
>>>
>>> of course making the Plot() call in another app function should work
>>>
>>>
>>> If you could replicate this issue, that would be great.
>>> I am using CentOS 6.8, PLplot.5.11.1 , wxWidgets 3.1.0
>>>
>>>
>>>
>>>
>>>
>>> - Original Message - From: Pedro Vicente
>>> To: plplot-devel@lists.sourceforge.net ; Phil Rosenberg
>>> Sent: Saturday, December 10, 2016 12:59 AM
>>> Subject: Re: [Plplot-devel] wxPLplotDemo.cpp errors
>>>
>>>
>>> Hi Phil
>>>
>>> So, the issue seems to be the same that I have been reporting
>>>
>>>
>>> In the wxPLplotDemo.cpp code you have these callling functions
>>>
>>>
>>> wxPLplotwindow *frame = new wxPlDemoFrame();
>>> frame->Create( NULL, wxID_ANY, wxT( "wxPLplotDemo" ) );
>>>
>>>
>>> that make 2 calls to the PLplot library, or the wxWidgets driver of it
>>> all these calls are in the header file wxPLplotwindow.h
>>>
>>> first the constructor is called
>>>
>>> template
>>> wxPLplotwindow::wxPLplotwindow( bool useGraphicsConte
Re: [Plplot-devel] More on IPC
On 2016-12-10 13:41- 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
Re: [Plplot-devel] More on IPC
On 2016-12-10 13:21-0800 Alan W. Irwin wrote: [...] > 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. Hi Phil: See commit 7756f60 for the tonne of new debug print statements I have inserted. With those I got what appears naively to me is a "deadlock" situation when attempting to delete m_name. (However, I emphasize naive because I don't really understand C++ that well so I may be missing something obvious). Anyhow, I hope you will have a fast look at these results and give me your comments on this "deadlock" and also my other conclusions assuming it is not a deadlock at all. First here are the results of the latest "two x01c example execution" test. software@raven> time examples/c/x01c -dev wxwidgets -np; echo "done x01c"; time examples/c/x01c -dev wxwidgets -np;echo "done x01c" PLplot library version: 5.11.1 [from -dev wxwidgets?] PLMemoryMap::close: just entering close PLMemoryMap::create: (mustNotExist) calling shm_open PLMemoryMap::create: shm_open was a success for plplotMemoryMapSNULFSEKQE PLMemoryMap::create: (mustNotExist) calling ftruncate PLMemoryMap::create: calling mmap PLMemoryMap::create: finished with call of mmap [from wxPLViewer?] PLMemoryMap::close: just entering close PLMemoryMap::create: (mustExist) calling shm_open PLMemoryMap::create: shm_open was a success for plplotMemoryMapSNULFSEKQE PLMemoryMap::create: calling mmap PLMemoryMap::create: finished with call of mmap [from -dev wxwidgets?] PLMemoryMap::close: just entering close PLMemoryMap::close: calling munmap PLMemoryMap::close: calling shm_unlink PLMemoryMap::close: shm_unlink was a success for plplotMemoryMapSNULFSEKQE PLMemoryMap::close: start deleting m_name PLMemoryMap::close: end deleting m_name real0m0.280s user0m0.036s sys 0m0.020s done x01c PLplot library version: 5.11.1 [from wxPLViewer] PLMemoryMap::close: just entering close PLMemoryMap::close: calling munmap PLMemoryMap::close: calling shm_unlink PLMemoryMap::close: shm_unlink error PLMemoryMap::close: No such file or directory PLMemoryMap::close: start deleting m_name PLMemoryMap::close: end deleting m_name PLMemoryMap::close: just entering close [long pause] [from -dev wxwidgets?] PLMemoryMap::close: just entering close PLMemoryMap::create: (mustNotExist) calling shm_open PLMemoryMap::create: shm_open was a success for plplotMemoryMapRZUTHPBSHB PLMemoryMap::create: (mustNotExist) calling ftruncate PLMemoryMap::create: calling mmap PLMemoryMap::create: finished with call of mmap [from wxPLViewer?] PLMemoryMap::close: just entering close PLMemoryMap::create: (mustExist) calling shm_open PLMemoryMap::create: shm_open was a success for plplotMemoryMapRZUTHPBSHB PLMemoryMap::create: calling mmap PLMemoryMap::create: finished with call of mmap [from -dev wxwidgets?] PLMemoryMap::close: just entering close PLMemoryMap::close: calling munmap PLMemoryMap::close: calling shm_unlink PLMemoryMap::close: shm_unlink was a success for plplotMemoryMapRZUTHPBSHB PLMemoryMap::close: start deleting m_name PLMemoryMap::close: end deleting m_name real0m11.311s user0m0.048s sys 0m0.008s done x01c [from wxPLViewer] software@raven> PLMemoryMap::close: just entering close PLMemoryMap::close: calling munmap PLMemoryMap::close: calling shm_unlink PLMemoryMap::close: shm_unlink error PLMemoryMap::close: No such file or directory PLMemoryMap::close: start deleting m_name PLMemoryMap::close: end deleting m_name PLMemoryMap::close: just entering close As you can see from the above results and the commit, I have inserted debug printout almost everywhere in PLMemoryMap::create and PLMemoryMap::close. Note I have tentatively (note question marks) identified which sections of output belong to -dev wxwidgets and which to wxPLViewer (except after the "done x01c" output it must be wxPLViewer so I have dropped the question marks in those cases). Do you agree with those identifications? Also note that several times we have PLMemoryMap::close: just entering close with nothing happening in close afterwards meaning your if statements are set up for that particular call to close in such a way that nothing is executed in close. Anyhow, the "deadlock" that concerns me is in the messages that must be purely from wxPLViewer where just before the long pause we have [from wxPLViewer] PLMemoryMap::close: just entering close PLMemoryMap::close: calling munmap PLMemoryMap::close: calling shm_unlink PLMemoryMap::close: shm_unlink error PLMemoryMap::close: No s
Re: [Plplot-devel] More on IPC
Hi (again) Phil: Two further thoughts. * All those preprocessing directives and fprintf calls I inserted make it extremely hard to understand the code. Thus, feel free to revert my two commits completely that inserted the debug output in PLMemoryMap:create and PLMemoryMap:close when you finally isolate exactly what system call is causing the long pause. But make that reverting commit a clean one (nothing else then exactly reverting my changes alone) to make it easy to reinstate my debug output again if we ever need it again. And I suggest you use a similar process for the debugging printout you insert (i.e., one clean commit to put in your own debug printout statements, one clean commit to remove that code again once you finally isolate the issue). * You will have to look at what your further debug print statements say to get the definitive answer, but my current guess is a call from -dev wxwidgets to some method of PLNamedMutex (or PLNamedMutexLocker) will turn out to be the cause of the long-pause issue. 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
Re: [Plplot-devel] wxPLplotDemo.cpp errors - FIXED , with workaround
Hi Phil
There is actually a very simple solution.
Instead of figuring out why the OnCreate event is not triggered in some
linux cases, you can explicitally call that code with some function.
I did just that, like this, where
frame->CreatePLplotstream();
is a function that contains your code that is in OnCreate()
this makes it needed to a user to call this extra function, but well, you
can't win them all
this code below makes a plot in Windows and Linux
Note:
I did my own class
wx_PLplotFrame
that is virtually identical to wxPLplotwindow, but not templated
I'll put this code in github when I have a chance later
bool wxAppPlot::OnInit()
{
wx_PLplotFrame *frame = new wx_PLplotFrame();
frame->Create(NULL, wxID_ANY, wxT("wxPLplot"),
wxDefaultPosition,
wxSize(900, 700));
frame->CreatePLplotstream();
frame->Show();
wxPLplotstream* pls = frame->GetStream();
assert(pls);
PLFLT x[4] = { 1, 2, 3, 4 };
PLFLT y[4] = { 1, 2, 3, 4 };
pls->env(0, 5, 0, 5, 0, 0);
pls->line(4, x, y);
return true;
}
-Pedro
- Original Message -
From: "Phil Rosenberg"
To: "Pedro Vicente" ;
Sent: Saturday, December 10, 2016 3:57 AM
Subject: Re: [Plplot-devel] wxPLplotDemo.cpp errors
> Hi Pedro
> I have included the devel list on this email, so the thread will get
> documented on the mailing list.
>
> It is very strange that the OnCreate function is not being called. If
> you are calling Create then you should be generating a create event.
> Am I correct in saying that you are getting this segfault with the
> unchanged demo app?
>
> This location really is the best (and maybe only) place this
> initialisation should be done. It cannot be included in the
> constructor, because the generic nature of the template specification
> means the code in the constructor does not know which type of wxWindow
> we are inheriting from so cannot pass the correct parameters to the
> constructor. By the time OnPaint is called it is really too late,
> because we would like to already have the plot initialised and ready
> to draw and it would be a real pain for you in your code if you had to
> somehow wait for the first paint or resize event.
>
> I do have access to a CentOS machine at work, although I think I have
> only got access to wxWidgets 2.8 on that system. I will check. I may
> be able to build 3.1 from source. I presume you are using 3.1.0 as
> released in February, rather than the head of the master branch?
>
> On 10 December 2016 at 07:52, Pedro Vicente
> wrote:
>> Hi Phil
>>
>> My idea for a fix is to move the stream initialization that is now on
>>
>> void wxPLplotwindow::OnCreate( wxWindowCreateEvent &event
>> {
>> if ( !m_created )
>>
>> either to the OnSize or onPaint events
>>
>> void wxPLplotwindow::OnSize( wxSizeEvent& WXUNUSED( event ) )
>>
>> and also in the plot call do this
>>
>> template< class WXWINDOW >
>> void Plot( wxPLplotwindow *plotwindow )
>> {
>>wxPLplotstream* pls = plotwindow->GetStream();
>>
>>if (pls == NULL)
>>{
>> return;
>>}
>>
>>
>> Like this , in this sequence
>>
>>
>> wxPLplotwindow *frame = new wxPLplotwindow();
>>frame->Create( NULL, wxID_ANY, wxT( "wxPLplotDemo" ) );
>>frame->SetIcon( wxIcon( graph ) );
>>frame->Show();
>>Plot( frame );
>>
>>
>> first we go to
>> Plot( frame );
>>
>> but the stream is NULL because
>> :OnCreate
>> was not called, but the function returns, avoiding the seg fault
>>
>> then the window gets a paint or size event, and the stream initialization
>> code is called
>> at this time I have a PLplot empty black window
>>
>> but because
>> Plot( frame );
>> was only called at start, it is not called again, so there is no draw
>>
>> any ideas here ?
>>
>> of course making the Plot() call in another app function should work
>>
>>
>> If you could replicate this issue, that would be great.
>> I am using CentOS 6.8, PLplot.5.11.1 , wxWidgets 3.1.0
>>
>>
>>
>>
>>
>> - Original Message - From: Pedro Vicente
>> To: plplot-devel@lists.sourceforge.net ; Phil Rosenberg
>> Sent: Saturday, December 10, 2016 12:59 AM
>> Subject: Re: [Plplot-devel] wxPLplotDemo.cpp errors
>>
>>
>> Hi Phil
>>
>> So, the issue seems to be the same that I have been reporting
>>
>>
>> In the wxPLplotDemo.cpp code you have these callling functions
>>
>>
>> wxPLplotwindow *frame = new wxPlDemoFrame();
>> frame->Create( NULL, wxID_ANY, wxT( "wxPLplotDemo" ) );
>>
>>
>> that make 2 calls to the PLplot library, or the wxWidgets driver of it
>> all these calls are in the header file wxPLplotwindow.h
>>
>> first the constructor is called
>>
>> template
>> wxPLplotwindow::wxPLplotwindow( bool useGraphicsContext, wxSize
>> clientSize )
>>: m_created( false ), m_initialSize( clientSize )
>>
>>
>> then this call OnCreate() is called, like you mentioned
>> and the !m_created bool makes the initialization of the stream happen
>>
>> the problem is that this function id *NOT* called on my linux build (it
>> is
>> on the Windows build)
>>
