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:27:05 GMT
Manuel Teira escribió:
> 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() {
>     QPID_POSIX_ASSERT_THROW_IF(pthread_rwlock_init(&rwlock,
> recursiveRWlockattr));
> }
>
> 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,
> found:
>
>
> DESCRIPTION
>      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
> onceControl:
>
>         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_init(&mutexattr);
>         pthread_mutexattr_settype(&mutexattr, PTHREAD_MUTEX_RECURSIVE);
>     }
>
>     void initRWlockattr()  {
>           printf("initRWlockattr called\n");
>         pthread_rwlockattr_init(&rwlockattr);
>     }
>
>
> 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
> initializers?
> Even more interesting, how can this work on linux, for example?
>   
I'm attaching a proposed patch. The abort is gone with this little change:

Regards.

--
Manuel.




Mime
View raw message