qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Manuel Teira <mte...@tid.es>
Subject Re: qpid (cpp) on solaris + Sun Studio 12
Date Fri, 30 May 2008 10:11:05 GMT
Alan Conway escribió:
> Manuel Teira wrote:
>> Gordon Sim escribió:
>>> It looks like the declaration of those methods did not match the
>>> definitions w.r.t const declarations. I checked in a change to both as
>>> r661323 - does that fix it?
>>> .
>> Great, looking at the method declaration and implementation didn't ever
>> crossed my mind (too much time programming java, I'm afraid). It's
>> fixed! Now:
>> -bash-3.00$ LD_LIBRARY_PATH=/opt/dslap/contrib/lib:. ./qpidd -v
>> qpidd (qpidc) version 0.2
>> It all its 64 bits glory:
>> -bash-3.00$ file qpidd
>> qpidd:          ELF 64-bit MSB executable SPARCV9 Version 1, dynamically
>> linked, not stripped
>> I will like to send a patch to your consideration, including all the
>> changes I've made to achieve this. But before, I would like to implement
>> the Event Completion Framework based poller, as the version I have now
>> is a dummy one, just trying to reach this point: a valid linked executable.
>> Thanks a lot and best regards.
> Thanks dragging qpid through its first real port :) Don't hesitate to post if
> you need any more help. Looking forward to the patch, it's all good stuff.
You're welcome.
I prefer to wait until the Event Completion Framework Poller is done, to 
have something not only compiling on solaris, but running also (or kind of).

I've hit another problem, runtime  I should say ;-)

Just to summarize, I think the problem is in the initializers for 
mutexes classes. It can be reproduced in solaris doing something like this:

#include <stdio.h>
#include <Mutex.h>

int main(int argc, char **argv)
  qpid::sys::RWlock lock;

Running this little program, leads to:

-bash-3.00$ ./mutex      
Invalid argument
Assertion failed: 0, file 
ws/DSLAP/qpid/trunk/qpid/cpp/src/qpid/sys/posix/Mutex.h, line 175
Abort (core dumped)

The abort is raised in:

RWlock::RWlock() {

And the only way for that assert to fail, is that rwlock and/or the 
result of recursiveRWlockattr() are not valid.

I found the way the attributes for locks and mutexes are initialized, 
very elegant. But, how come they are sharing the same pthread_once_t? 
Never heard about this useful feature before, and reading the man page, 

     If any thread in a process  with  a  once_control  parameter
     makes  a  call to pthread_once(), the first call will summon
     the init_routine(),  but  subsequent  calls  will  not.  The
     once_control  parameter  determines  whether  the associated
     initialization routine has been called.  The  init_routine()
     is complete upon return of pthread_once().

So, my suspect was that as classes RecursiveMutexAttr and 
RecursiveRWLockAttr are sharing the same pthread_once_t known as 

        RecursiveMutexattr() {
            pthread_once(&onceControl, initMutexattr);

        RecursiveRWlockattr() {
            pthread_once(&onceControl, initRWlockattr);

only the first one of them called in one thread, should actually perform 
its task.

To check it, I just added a dirty printfs in:

    void initMutexattr()  {
          printf("initMutexattr called\n");
        pthread_mutexattr_settype(&mutexattr, PTHREAD_MUTEX_RECURSIVE);

    void initRWlockattr()  {
          printf("initRWlockattr called\n");

Recompiling and running again my program, led to:

-bash-3.00$ ./mutex    
initMutexattr called
Invalid argument
Assertion failed: 0, file 
ws/DSLAP/qpid/trunk/qpid/cpp/src/qpid/sys/posix/Mutex.h, line 175
Abort (core dumped)

So, initRWlockAttr is not called, and hence, the rwlockattr member is 
not initialized, feeding the bloody assert monster.

So, shouldn't we use different pthread_once_t variables for each of the 
Even more interesting, how can this work on linux, for example?

Recursive regards.

View raw message