On 2015-02-21 21:25-0000 Phil Rosenberg wrote: > Hi Alan > I have fixed the valgrind warning. It turned out to be nothing much > just checking characters after the \0 in a string, but before the end > of the memory allocation and replacing them with random letters if > they were ?. It saw all characters after the \0 as uninitialized. See > my latest commit. > > I have, however, currently been unable to reproduce your reported > error since the c3fed1 commit. Even example 8 which you state errors > out every time for you, works fine for me. This is both on Windows and > Ubuntu. However if I checkout 1feef37 the I get the same warning > message as you and a segfault style crash of wxPLViewer. > > This might be a daft question but is there a chance your wxPLViewer is > out of date? Is it definitely being rebuilt (does clearing out your > build directory help?). Don't forget that the current dependencies > WILL NOT automatically rebuild it if the driver changes. Is there an > old version in your install directory or on your path? I am clutching > at straws here, but with no valgrind error even and my total inability > to reproduce the issue since that commit I am struggling.
These issues that cannot be verified on other platforms are a real pain to figure out. However, I think this is a real issue for at least the Debian stable platform for which I have discovered a tentative solution below. But first to respond to your question, all my previous test reports were for a fresh build starting from an empty build tree. There was an old version of wxPLViewer on my PATH from a previous PLplot install so I guess it is possible that was being used instead of the newly created one in the build tree. But when I removed that installed one and verified no wxPLViewer on my PATH, I continued to get the intermittent results, i.e., the examples sometimes worked indicating wxwidgets was finding/using the newly build wxPLViewer in my build tree (despite it not being on my PATH). I verified there are now no valgrind reports of uninitialized variables, but the intermittent warning messages continued for both example 1 and example 8 The source of the warning message Error creating memory map for wxWidget instruction ... is in drivers/wxwidgets_dev.cpp to check (I assume) that the two preceding nested loops worked correctly. So I concluded that nested loop logic is sometimes (i.e., intermittently) not working quite correctly on my Debian stable platform (although there are no valgrind issues with that logic). I did try to check that assumption with gdb, but I kept getting the gdb error Cannot find new threads: generic error which has to do (according to google searches) with some sort of thread inconsistency when firing up gdb, but I couldn't figure it out. With valgrind finding no issues, and gdb unable to operate because of the threading issue, and you unable to replicate the issue on Ubuntu, I decided to move to more old-fashioned debugging methods. Insertion of some pldebug statements into wxwidgets_dev.cpp (commit 0c9a612), immediately generated some interesting results with the -debug option. # Working result examples/c/x01c -debug -dev wxwidgets [...] wxPLDevice::SetupMemoryMap: nTries = 0, mapName = plplotMemoryMapAAAAAAAAAA wxPLDevice::SetupMemoryMap: nTries = 0, mutexName = plplotMemoryMapAAAAAAAAAAmut # Non-working result examples/c/x01c -debug -dev wxwidgets [...] wxPLDevice::SetupMemoryMap: nTries = 0, mapName = plplotMemoryMapQQQQQQQQQQ wxPLDevice::SetupMemoryMap: nTries = 0, mutexName = plplotMemoryMapQQQQQQQQQQmut wxPLDevice::SetupMemoryMap: nTries = 1, mapName = plplotMemoryMapQQQQQQQQQQ wxPLDevice::SetupMemoryMap: nTries = 1, mutexName = plplotMemoryMapQQQQQQQQQQmut wxPLDevice::SetupMemoryMap: nTries = 2, mapName = plplotMemoryMapQQQQQQQQQQ wxPLDevice::SetupMemoryMap: nTries = 2, mutexName = plplotMemoryMapQQQQQQQQQQmut wxPLDevice::SetupMemoryMap: nTries = 3, mapName = plplotMemoryMapQQQQQQQQQQ wxPLDevice::SetupMemoryMap: nTries = 3, mutexName = plplotMemoryMapQQQQQQQQQQmut wxPLDevice::SetupMemoryMap: nTries = 4, mapName = plplotMemoryMapQQQQQQQQQQ wxPLDevice::SetupMemoryMap: nTries = 4, mutexName = plplotMemoryMapQQQQQQQQQQmut wxPLDevice::SetupMemoryMap: nTries = 5, mapName = plplotMemoryMapQQQQQQQQQQ wxPLDevice::SetupMemoryMap: nTries = 5, mutexName = plplotMemoryMapQQQQQQQQQQmut wxPLDevice::SetupMemoryMap: nTries = 6, mapName = plplotMemoryMapQQQQQQQQQQ wxPLDevice::SetupMemoryMap: nTries = 6, mutexName = plplotMemoryMapQQQQQQQQQQmut wxPLDevice::SetupMemoryMap: nTries = 7, mapName = plplotMemoryMapQQQQQQQQQQ wxPLDevice::SetupMemoryMap: nTries = 7, mutexName = plplotMemoryMapQQQQQQQQQQmut wxPLDevice::SetupMemoryMap: nTries = 8, mapName = plplotMemoryMapQQQQQQQQQQ wxPLDevice::SetupMemoryMap: nTries = 8, mutexName = plplotMemoryMapQQQQQQQQQQmut wxPLDevice::SetupMemoryMap: nTries = 9, mapName = plplotMemoryMapQQQQQQQQQQ wxPLDevice::SetupMemoryMap: nTries = 9, mutexName = plplotMemoryMapQQQQQQQQQQmut *** PLPLOT WARNING *** Error creating memory map for wxWidget instruction transmission. The plots will not be displayed In fact, for that commit I never saw anything but the "plplotMemoryMapAAAAAAAAAA" result when -debug -dev wxwidgets worked and nothing but the "plplotMemoryMapQQQQQQQQQQ" result when it doesn't work. Those "A" and "Q" values are being determined by mapName[i] = 'A' + clock() % 26; so it appears the clock() resolution is so low (at least on Debian stable), that it always produces the same result for all values of nTries for a given run which I think is far from what you intended. So as of 8ec8573 I tried a different alternative which was to use mapName[i] = 'A' + (int) ( 26. * plrandd() ); to determine a random mapName. The result now is always (because the Mersenne twister is started in this case with the same seed) wxPLDevice::SetupMemoryMap: nTries = 0, mapName = plplotMemoryMapVDXVDZXFQI wxPLDevice::SetupMemoryMap: nTries = 0, mutexName = plplotMemoryMapVDXVDZXFQImut and that works for me (no more warning message), but this may not have been exactly what you intended for this randomization but at least I think the above experimental commit is a step in the right direction, and if for some reason nTries = 0 fails, the succeeding nTries will try quite different names. But if you want truly different mapNames, each time you run -dev wxwidgets then you have to find a way to set the Mersenne twister seed randomly using (say) a high-resolution clock function and a call to plseed. So my further questions for you are why exactly do you need a random mapName and why does plplotMemoryMapAAAAAAAAAA and plplotMemoryMapVDXVDZXFQI always appear to succeed and plplotMemoryMapQQQQQQQQQQ always appear to fail? 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 __________________________ ------------------------------------------------------------------------------ Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
