Project

General

Profile

Bug #298

Avoid warning in sockRoutines

Added by Nikhil Jain almost 6 years ago. Updated over 1 year ago.

Status:
New
Priority:
Normal
Assignee:
PPL
Category:
-
Target version:
-
Start date:
10/04/2013
Due date:
% Done:

0%


Description

On most machine, I see the following warning (that we should get rid of):

/usr/lib/../lib64/libpthread.a(sem_open.o): In function `sem_open':
/usr/src/packages/BUILD/glibc-2.11.3/nptl/sem_open.c:333: warning: the
use of `mktemp' is dangerous, better use `mkstemp'
/users/fminiati/Charm++/gni-crayxc/bin/../lib/libconv-util.a(sockRoutines.o):
In function `skt_lookup_ip':
sockRoutines.c:(.text+0x344): warning: Using 'gethostbyname' in
statically linked applications requires at runtime the shared libraries
from the glibc version used for linking

History

#1 Updated by Phil Miller over 5 years ago

The first isn't in our code, so there's nothing we can do to get rid of it short of avoiding that bit of the common pthreads library.

The second is annoying, and we may be able to fix it. It seems like defining CMK_NO_SOCKETS would exclude the code in question. I don't know how that would play with our CCS support, though. For note, that is the setting on all of the Bluegene targets and some older Cray targets as well.

#2 Updated by Nikhil Jain over 5 years ago

  • Status changed from New to Resolved

#3 Updated by Nikhil Jain over 5 years ago

  • Status changed from Resolved to Upstream

#4 Updated by Nikhil Jain over 5 years ago

  • Target version changed from 6.6.0 to 6.7.0

#5 Updated by Eric Bohm over 4 years ago

  • Assignee set to PPL

#6 Updated by Nikhil Jain over 4 years ago

  • Status changed from Upstream to Closed

Seems this issue was resolved by sock routine implementation.

#7 Updated by Sam White over 2 years ago

  • Status changed from Closed to New
  • Target version changed from 6.7.0 to 6.8.0

These warnings still appear on Cray builds and possibly elsewhere.

The warning about mktemp comes from our use of pthread's sem_open(). We currently only call that routine from pxshm/xpmem machine layers:

src/arch/net/machine-pxshm.c:    (*bufs)[i].mutex = sem_open(bufNames[i], O_CREAT, S_IRUSR | S_IWUSR, 1);
src/arch/util/machine-pxshm.c:   (*bufs)[i].mutex = sem_open(bufNames[i], O_CREAT, S_IRUSR | S_IWUSR, 1);
src/arch/util/machine-xpmem.c    (*bufs)[i].mutex = sem_open(bufNames[i],O_CREAT, S_IRUSR | S_IWUSR,1);
src/arch/util/machine-xpmem.c:   (*bufs)[i].mutex = sem_open(bufNames[i],O_CREAT, S_IRUSR | S_IWUSR,1);

The following commit turns off that support by default for Cray MPI SMP builds, but it appears to be the default for GNI builds: https://charm.cs.illinois.edu/gerrit/#/c/2054/
We would like for the pxshm queues to use atomics/fences (PXSHM_FENCE) rather than locks (PXSHM_LOCK), but the current fence implementation appears to be buggy: https://charm.cs.illinois.edu/redmine/issues/571

The latter issue, about gethostbyname, is not seen on any BGQ builds because we have set CMK_NO_SOCKETS on {pami,pamilrts,mpi}-bluegeneq.
Investigate if we can define that flag without losing CCS support on crayx{c,e} builds.

#8 Updated by Sam White over 2 years ago

The mktemp warnings from sem_open can indeed be easily avoided on non-pxshm builds as long as we set CMK_USE_PXSHM to 0 when not using it.

I tried adding CMK_NO_SOCKETS, but then we get many undefined references to routines from sockRoutines. The BGQ builds also set CMK_CCS_AVAILABLE to 0, so they don't see this issue. It's not clear to me what functionality we would lose by defining the NO_SOCKETS option but still making CCS available, so I'm not sure how much effort this is worth...

#9 Updated by Sam White over 2 years ago

Don't build pxhsm if not explicitly requested for GNI SMP: https://charm.cs.illinois.edu/gerrit/#/c/2065/

#10 Updated by Sam White over 2 years ago

  • Target version changed from 6.8.0 to 6.8.1

#11 Updated by Sam White almost 2 years ago

  • Target version changed from 6.8.1 to 6.9.0

#12 Updated by Sam White over 1 year ago

  • Target version deleted (6.9.0)

Also available in: Atom PDF