socket.c / accept() bug
This seems to be related to https://bitbucket.org/gfcstanford/rockstar/issues/5/more-complete-setup-starting-server for which the resolution is, let's say, not explained in much detail :). And a user "SH" also has the same bug as of "4 days ago".
I have run rockstar
in single snapshot mode and it created a reasonable output file halos_0.0.ascii
.
With an updated .cfg
file for multiple N-body snapshots, and some example printf
statements added to inet/socket.c
to illustrate this bug, I get an infinite wait on the accept(...)
command.
Someone who knows about sockets may have an idea on how to debug this.
git commit: commit 7b67490e9b056f65b84a4d10f8d57c49a26435ba
Jun 14 19:51:13 2018
kernel: Linux 3.2.0-126-generic #169-Ubuntu SMP Fri Mar 31 14:15:21 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
My quickstart.cfg
file:
#Rockstar Halo Finder
#Quickstart config file for single-cpu, single snapshot halo finding
#Note that non-periodic boundary conditions are assumed.
#See README for details.
#Once compiled ("make"), run Rockstar as
# ./rockstar -c quickstart.cfg <particle data file>
FILE_FORMAT = "ASCII" # "GADGET2" # or "ART" or "ASCII" or "TIPSY" or "AREPO"
PARTICLE_MASS = 1e12 # must specify (in Msun/h) for ART or ASCII
# You should specify cosmology parameters only for ASCII formats
# For GADGET2 and ART, these parameters will be replaced with values from the
# particle data file
SCALE_NOW = 1
h0 = 0.7
Ol = 0.0
Om = 1.0
# For GADGET2, you may need to specify conversion parameters.
# Rockstar's internal units are Mpc/h (lengths) and Msun/h (masses)
GADGET_LENGTH_CONVERSION = 1
GADGET_MASS_CONVERSION = 1e+10
# For AREPO / GADGET2 HDF5, you would use the following instead:
# Make sure to compile with "make with_hdf5"!
#AREPO_LENGTH_CONVERSION = 1
#AREPO_MASS_CONVERSION = 1e+10
# For TIPSY, you would use:
#TIPSY_LENGTH_CONVERSION = 10 #Typically, box size in Mpc/h
#TIPSY_VELOCITY_CONVERSION = 1e6 #Conversion from TIPSY units to km/s at z=0
FORCE_RES = 0.001 #Force resolution of simulation, in Mpc/h
# For ascii files, the file format is assumed to be:
# X Y Z VX VY VZ ID
## for multiple files
PARALLEL_IO = 1
NUM_BLOCKS = 1
INBASE = "./"
FILENAME = "examplesnap8.<snap>.0"
NUM_WRITERS = 1
OUTBASE = "./out/"
#AVG_PARTICLE_SPACING =
The patch toinet/socket.c
is this:
diff --git a/inet/socket.c b/inet/socket.c
index 5fd0c9e..08d178d 100644
--- a/inet/socket.c
+++ b/inet/socket.c
@@ -146,7 +146,9 @@ int _accept_connection(int s, char **address, int *port) {
} peer;
socklen_t length = sizeof(peer);
int a, size = (INET6_ADDRSTRLEN+1)*sizeof(char);
+ printf("inet/socket.c: line before calling accept(...)\n");
while ((a = accept(s, &(peer.sockaddr), &length)) < 0 && errno==EINTR);
+ printf("inet/socket.c: line after calling accept(...)\n");
if (a<0) {
perror("[Error] Connection accept failed");
assert(0);
The command and output were:
../rockstar -c quickstart.cfg
[Warning] Setting PERIODIC=0 since NUM_WRITERS=1.
[Warning] To enable periodic boundary conditions, increase NUM_WRITERS to at least 8.
[ 0s] Accepting connections...
inet/socket.c: line before calling accept(...)
As above, this seems to be the same as https://bitbucket.org/gfcstanford/rockstar/issues/5/more-complete-setup-starting-server, and colleague with kernel 4.4.0-138-generic #164-Ubuntu SMP ... x86_64
has the same problem.
Comments (1)
-
reporter - Log in to comment
Peter, thanks for the explanation :) - it's a server vs client thing. So I've proposed https://bitbucket.org/gfcstanford/rockstar/pull-requests/3 to clarify the READMEs.