Re: NPTL Shared mutex failure in 32- + 64-bit applications

David Schwartz <davids@xxxxxxxxxxxxx> wrote:
On May 27, 3:14 pm, "Guido Ostkamp" <gueltig-
bis-30-09-2...@xxxxxxxxxxxxxx> wrote:
I am using 32-bit and 64-bit applications in parallel which I need to
coordinate using POSIX shared mutexes.

Impossible. There is no way applications can use shared memory if
they're using different libraries (or even different versions of the
same library) to access the shared memory structures. There is no
way to ensure the memory layout is the same.

I have to disagree with that. I have been working on a multi OS
Telecommunication platform for more than a decade now, and we never
had any problems to access structures located in shared memory by
32-bit and 64-bit applications or libraries at the same time.

You just have take care to implement the necessary fillers, padding
etc. so that every structure element is located at the same binary
offset and overall size is the same, as well as that alignment fits.

Furthermore, we are not using "different" libraries here. They are
just the 32-bit and the 64-bit versions of the same GLIBC version.

With respect to this, Sun has obviously done a good job in Solaris
libpthread - I don't think at all that this happens to work just "by
chance".

The POSIX API definition of e.g. pthread_mutexattr_setpshared()
w.r.t. to PTHREAD_PROCESS_SHARED just defines:

"The process-shared attribute is set to PTHREAD_PROCESS_SHARED to
permit a mutex to be operated upon by any thread that has access to
the memory where the mutex is allocated, even if the mutex is
allocated in memory that is shared by multiple processes."

So shared mutex functionality has to work from ANY thread in ANY
process. I am not aware of any exception defined with respect to
32-bit vs. 64-bit applications.

Considering this the current NPTL implementation appears to be not
100% POSIX compliant to me.

I'm not sure why you think of this as an ABI compatibility issue.
The memory layouts of internal library structures are not ABI
issues. They're purely internal to the library.

Maybe you think of ABI only in terms of backward compatibility to
former OS versions, i.e. running an application on a newer system that
has been compiled on an earlier system.

I consider structures to be part of the interfaces (as parameters of
functions or in shared memory). And those should be binary compatible
if used in the same 32-bit and 64-bit API.

I don't know what has led to the decision to mix up struct components
of pthread_mutex_t and add additional elements in 64-bit
implementation of NPTL libpthread.so. I would have expected that in
this case the same changes are also applied to the 32-bit version.

Maybe the NPTL author considered some backward compatibility to old
structs used in 32-bit on earlier NPTL or even linuxthreads
implementations to be more important than implementing full POSIX
compliance.

If you need this very unusual feature, you'll need to code it
yourself.

I am investigating whether it would be possible to implement a fixed
private version of NPTL (possibly with changed API and struct names)
so that this could work.

For this, I have started building the original unchanged source RPM of
GLIBC 2.5 for the RHEL 5.5. I am using. Unfortunately, although the
build went fine, I am unable to just use the produced libpthread.so
(which should have same version compared to the one located in /lib64)
as the simple test program already crashes on loading the library.

So after 'rpmbuild -bb' I grabbed only the libpthread lib, copied it
into an empty dir, setup LD_LIBRARY_PATH to the dir, verified with ldd
that test program takes the new lib, and called the test program.

According to gdb invoked on the core, it bombs out with SIGSEGV at

/* Transfer the old value from the dynamic linker's internal location. */
*__libc_dl_error_tsd () = *(*GL(dl_error_catch_tsd)) ();

This is called by __init() of the lib (so my test programs code is not
yet involved at this point).

Don't know whether you are the right one to ask, but if you (or anyone
else here) happens to know why, please drop me a note.

Regards

Guido
.

Relevant Pages

  • Re: protecting app from crash due to plugin bugs
    ... run the unsafe code in a different process under a different ... is to allocate some shared memory before forking. ... probably means those belonging to other libraries. ...
    (comp.os.linux.development.apps)
  • Re: Safe limits for shared memory allocation?
    ... > shared memory as it can. ... question had all their dynamic libraries loaded up.... ... within your window before you use any from the Globally shared Q4 ... if you can start your app, set up your segmentas 1.5Gb or whatnot ...
    (comp.sys.hp.hpux)
  • Re: [patch] SMP alternatives
    ... A software solution will ... locks on the shared memory, and you really don't on the heap. ... written libraries already have wrapper functions that can be used to ... thread-using library function, because by assumption, the majority of ...
    (Linux-Kernel)
  • Re: Inter-Process Messaging
    ... libraries: ... There are basically two ways to do concurrency/parallelism: shared memory and message passing. ... I'm not sure what the *real* tradeoffs are -- I've pretty much had my brain hammered with "shared memory bad -- message passing good", but there obviously must be *some* counter-arguments, or shared memory wouldn't exist. ... System V IPC has three components -- message queues, semaphores, and shared memory segments. ...
    (comp.lang.ruby)
  • Re: strange error when accessing TLS data
    ... POSIX interface to handle TLS. ... not an API. ... static linking against shared libraries, ... block allocation for static TLS. ...
    (comp.programming.threads)