qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alan Conway <acon...@redhat.com>
Subject Re: qpid (cpp) on solaris + Sun Studio 12
Date Fri, 30 May 2008 13:38:28 GMT
Manuel Teira wrote:
> 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.
> 

Great! To make this an Apache-legal contribution you need to open a JIRA at 
https://issues.apache.org/jira/secure/Dashboard.jspa and attach your patch. I'll 
keep an eye out for it.

Cheers,
Alan.



Mime
View raw message