socket.c / accept() bug

Issue #6 new
Boud Roukema created an issue

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)

  1. Log in to comment