Hi All I have hit a bit of a snag with the wxWidgets driver and would like some advice.
At some point the driver has to make a decision as to whether the user is going to pass the driver a wxDC to draw on, or whether the driver has to execute wxPLViewer to do the drawing. An ideal point to do that would be the first call to plP_bop(). It feels right that at this point when the first rendering begins to clear the page that by this point the decision should be made and technically if we leave it until after this point then we have to somehow replay the begin of page call, which it turns out can't be done by simply replaying the buffer. However plP_bop() is called from c_plinit, so there is no opportunity for the user to actually pass in the wxDC. To me it would make sense to call plP_bop when pladv() is first called, i.e. at the point at which the user decides to begin the first page. This is also symmetric with other calls to plP_bop which happen at page advances. However I don't know if this is would it totally mess up other devices? I have looked as carefully as I can and there doesn't appear to be any requirement within c_plinit for plP_bop() to be called. Any thoughts anyone? On 25 February 2015 at 23:06, Andrew Ross <andrewr...@users.sourceforge.net> wrote: > On Wed, Feb 25, 2015 at 12:16:02PM +0000, Phil Rosenberg wrote: >> Hi Alan >> > >> > It appears there are two remaining release-critical issues. >> > >> > 1. You should do one last check of Ubuntu and CentOS to make sure my >> > recent drop of explicit linking to the rt library does not cause >> > problems on those platforms. (And if it does, a one-line change >> > should fix it). >> >> I have checked this on Centos and it works fine. I can check on Ubuntu >> this evening. > > I've checked on my Ubuntu machine and your latest patch fixes things > again for me. > >> > >> > 2. I haven't experienced xwin crashes myself. Could you give me an >> > explicit test that fails for you so I can verify this regression? >> >> I rebuilt in a new build tree on Centos and I still get this. Sorry I >> hadn't looked at the error in detail before as I was in the middle of >> something else. In both case the error is a double free or corruption. >> In x13c I get a gdb backtrace, which points me to plP_fill, in x15c I >> just get a segmentation fault message. In x13 and x15 (c++) I get a >> backtrace which again points to plP_fill. >> >> By the looks of it plP_fill has no free calls, so I expect this is >> some memory overflow or bad pointer issue. As I am using the intel >> compiler it probably arranges things in memory differently to gcc, so >> perhaps that is why you aren't seeing this. > > As another data point, I do not see this behaviour on Ubuntu 14.10. > > Andrew ------------------------------------------------------------------------------ Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
