On 2017-02-05 21:16-0000 Phil Rosenberg wrote:
[...]
> As it stands I don't see in your source code where you have called
> m_unamed_semaphore_MemoryMap.create( <add params here> );
>
> I think what is happening is that you construct your PLnamedMutex
> which constructs all the member variables using their default
> constructors (the ones which take no variables). The default
> constructor for PLMemoryMap just sets m_buffer to NULL. Your call to
> getwsem then takes m_buffer, which is NULL and tries to access some of
> it's data and I imagine that is the point that everything goes wrong.
>
OK. That completely explains my gdb results. All the members of the
shmbuf struct appear to well aligned so there is no padding. So the
address of wsem (the first member) is exactly the same as the value of
m_buffer (the address of the struct) which is NULL according to your
above reasoning. And on Linux, sem_t consumes 32 bytes for 64-bit
systems and size_t consumes 8 bytes. So buf is offset from the start
of the struct by 2*32 + 8 = 72 bytes = 0x48 which is the (bad) gdb
result I got for the address of buf. So it appears I am getting
consistently wrong results in the PLNamedMutex case for anything to do
with PLMemoryMap because of the default constructor used for
PLMemoryMap.
> Anyway, the fix is to either call m_unamed_semaphore_MemoryMap.create
> just before getwsem, or call this in the constructor of PLNamedMutex,
> or tell PLNamedMutext to use the non-default constructor for
> m_unamed_semaphore_MemoryMap. To do the last of these the syntax would
> be as follows in wxWidgets_comms.cpp
>
> PLMemoryMap::PLMemoryMap( const char *name, PLINT size, bool
> mustExist, bool mustNotExist )
> : m_unamed_semaphore_MemoryMap(<arguments for the constructor you want to
> use>)
> {
>
The issue with all these potential solutions is PLNamedMutex::create
needs access to name, size, etc. for the non-default PLMemoryMap
constructor. So it appears that in all cases these solutions of this
inter-class communication issue involves passing additional arguments
to the PLNamedMutex so the non-default PLMemoryMap constructor can be
invoked with the right name, etc. In which case I think the better
approach is not to invoke the PLMemoryMap constructor at all from
PLNamedMutex and instead pass the wsem address that is determined
(correctly according to gdb) from a call to m_outputMemoryMap.getswm()
in wxPLDevice::SetupMemoryMap.
Anyhow, thanks for your help pointing out the default constructor
issue for PLMemoryMap for my present code, and more later about
whether the alternative idea of passing the wsem address works out or
not.
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
