Hi Alan Great detective work!!! In response to your question, why do we need a random name? If there is already an instance of wxPLViewer running or if there is another example running and we try to create another instance we will try to generate another region of shared memory with the same name, which will fail.
So we need some way to make the name unique. I started using rand() however I didn't want to reseed this global function in case a user was using it and was relying on a particular seed for reproducibility. I then moved to using C++ 11 random number generators, because each generator has it's own seed. However the intel compiler on my Centos machine didn't support this C++ 11 feature. I thought that something like a timer might be able to achieve enough randomness that it would work, obviously not. I don't know if you have any suggestions where to go from here. As you say that fix will always give the same sequence, so it won't quite give the desired effect. A quick google indicates maybe creating my own (not very good) random number generator might be the way forward, but other suggestions welcome. Phil On 22 February 2015 at 00:46, Alan W. Irwin <ir...@beluga.phys.uvic.ca> wrote: > 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
