Next: Extremely noisy measurements, Previous: ``cannot open shared object file'', Up: Problems running [Contents][Index]
In some implementations of the software stack for InfiniBand—and
possibly for some other networks as well—invocations of the
fork()
system call made while the network device is open can
corrupt process memory and hang or crash the corresponding process.
(On Unix and Unix-like operating systems this is typically via a
segmentation fault.)
The workaround is to build coNCePTuaL using the --without-fork option (see configure). Alternatively, you can set the NCPTL_NOFORK environment variable when running a coNCePTuaL program. Either option suppresses the coNCePTuaL run-time library’s use of all process-spawning functions. See Environment Variables, for a description of NCPTL_NOFORK’s side effects. The same description also applies to --without-fork.
The C library that comes bundled with a lightweight run-time
kernel or other custom operating system may provide broken versions
of some of the functions on which the coNCePTuaL run-time library
relies. If a debugger or crash-analysis tool indicates that a
particular function is problematic it may be possible to disable
that function at configuration time. For example, the current (at
the time of this writing) release of Red Storm’s software stack includes a
faulty
getrusage()
function that crashes
consistently. Observing that configure checks
for
getrusage()
we searched the generated
config.log file and encountered the
corresponding shell variable, ‘ac_cv_func_getrusage’,
which was set to ‘yes’. Rerunning
./configure with ‘ac_cv_func_getrusage=no’
on the command line disabled the coNCePTuaL run-time library’s use
of
getrusage()
and thereby resulted in
crash-free execution of coNCePTuaL programs.
Next: Extremely noisy measurements, Previous: ``cannot open shared object file'', Up: Problems running [Contents][Index]