On 2017-02-24 00:19-0800 Alan W. Irwin wrote: > I am currently trying to track down a bug (uncaught exception on the > wxPLViewer side) that shows up whenever there is an attempt to plot > multiple pages. I tried to copy the code stanzas from the old > wxplframe.cpp code to the #ifdef PL_WXWIDGETS_IPC2 case for each > transmission type, but I may have missed something that is critical to > the multipage case. Also for #ifdef PL_WXWIDGETS_IPC2, one call to > ReadTransmission reads all pages of plbuf and should plot those pages. > That's a big chance in design from ReadTransmission which for the > #ifndef PL_WXWIDGETS_IPC2 case reads and plots at most one page. > > Is there something more I have to do to accomodate that design change > so that the multipage case is displayed properly by wxPLViewer > when #ifdef PL_WXWIDGETS_IPC?
Hi Phil: You should ignore the above question because it turns out there is no general multipage issue for the -DPL_WXWIDGETS_IPC2=ON case! I discovered that result by doing extensive tests (running every single C example by hand using -dev wxwidgets) today. In fact, those tests showed everything working now for -DPL_WXWIDGETS_IPC2=ON with the following exceptions: 1. Examples 9 and 16 failed the first time I executed them with the throw message "PLMemoryMap::moveBytesWriter: attempt to start transfer with semaphores not in correct blocked state." That exception is thrown when m_twoSemaphores.areBothSemaphoresBlocked() fails when starting PLMemoryMap::moveBytesWriter. And the problem occurred on the first call to moveBytesWriter just after transfer of header information from wxPLViewer to -dev wxwidgets using moveBytesReaderReversed and moveBytesWriterReversed. But that failure (one or both semaphores are not blocked with zero values) should be impossible because the fact is both semaphores are initialized in that expected (blocked) state (that check succeeded for the initial call to moveBytesReaderReversed on the wxPLViewer side), and at the end of moveBytesReaderReversed when that header transfer succeeded (as measured on the -dev wxwidgets side) the check is made again that the semaphores are left in the proper blocked state. So I am pretty sure something must be clobbering the semaphores after the call to moveBytesReaderReversed is finished on the wxPLViewer side and before moveBytesWriter is called on the -dev wxwidgets side. But what? What severely complicates debugging this issue, is examples 9 and 16 have run flawlessly today after the first attempt that generated the above message. And the exact same generic sequence (transfer header from wxPLViewer to -dev wxwidgets and start tranferring data the other way with that call to moveBytesWriter) happens for every example with no occurrences of this error (at least so far). However, if something is getting clobbered (the only hypothesis that seems to make sense to me concerning the above results), then valgrind on -dev wxwidgets and/or wxPLViewer should be able to find what the trouble is. 2. I still have not implemented interactivity so I didn't bother to try example 1 with the -locate option. And for the same reason you should not expect example 20 to work (the only one of our examples that is interactive by default). 3. Examples 2 and 14 fail with wxPLViewer issuing the following message: Caught unhandled unknown exception; terminating This was the issue I incorrectly thought was a multipage issue yesterday, but it instead it is confined to just these two examples and must be due to some different way these examples set up plots that exposes an actual reproducible bug in the present -DPL_WXWIDGETS_IPC2=ON case which I am attempting to track down now. I cannot find this throw message anywhere in our own code, and indeed it instead appears (see <http://wxwidgets.10942.n7.nabble.com/Better-exception-handling-td87900.html>) that message is a generic wxwidgets response to uncaught exceptions. So my first step for this issue is to attempt to catch all exceptions in our code rather than passing them on, uncaught, to wxwidgets. In sum, the -DPL_WXWIDGETS_IPC2=ON has been largely matured with the only issues left being 1. an extremely elusive bug that ends up as an "impossible" "PLMemoryMap::moveBytesWriter: attempt to start transfer with semaphores not in correct blocked state." error message on rare and irreproducible occasions. 2. Interactivity not implemented. 3. Some easily reproduced bug exposed by example 2 and 14. I think 2 and 3 should be straightforward to deal with, and if my "something getting clobbered" hypothesis to explain 1 is correct, then with the help of valgrind that should be straightforward to solve as well. So I am extremely pleased that today's results showed so many of the examples are actually working fine now, and I am hoping to get all of them (and also the -locate option for example 1) working soon with -DPL_WXWIDGETS_IPC2=ON code. So stay tuned.... 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 __________________________ ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
