I did test the patch 2 version and that does seem to be working for me. However, that obviously doesn't mean that it's safe.

Should we put some atomics in there, to be absolutely sure?  Or put a lock around the dlsym code to ensure that only 1 thread calls dlsym?

Sent from my PDA.  No type good.

----- Original Message -----
From: bugs-bounces@open-mpi.org <bugs-bounces@open-mpi.org>
Cc: bugs@osl.iu.edu <bugs@osl.iu.edu>
Sent: Wed Mar 03 01:45:38 2010
Subject: Re: [OMPI bugs] [Open MPI] #2322: Something is wrong with rdmacm cpc

#2322: Something is wrong with rdmacm cpc
Reporter:  jsquyres  |       Owner:               
    Type:  defect    |      Status:  new          
Priority:  blocker   |   Milestone:  Open MPI 1.4.2
 Version:  trunk     |    Keywords:               

Comment(by cyeoh):

 I might be misunderstanding whats going on here, but I don't think the
 volatile will help with respect to the second two of the three causes of
 the segv as AFAIK volatile doesn't make any guarantees when it comes
 atomicity. It will force a reload each time but if the read is not atomic
 anyway then there still could be problems

 However I do suspect the latter two are not causing the problems. The
 static pointer should be aligned and I think in that case the assignments
 should be atomic (will be for powerpc, I think so for other

 I think its much more likely that dlsym was getting called when its not
 safe to (the first theory).

 The consolidation of the code looks good - sorry I should have done that
 in the first place.

 If its working now is it possible that its because its now consolidated
 into opal_mem_free_ptmalloc2_munmap that the munmap_real is getting called
 consistently early at a time when its safe to call dlsym (ie not through
 the munmap_real path which appears to be sometimes unsafe) ?

Ticket URL: <https://svn.open-mpi.org/trac/ompi/ticket/2322#comment:6>
Open MPI <http://www.open-mpi.org/>

bugs mailing list