Segmentation fault on 1024 listeners while ulimit is raised

[Ywa]

When I'm stress-testing my Linux (CentOS6) Shoutcast server with 3 active streams. The server gives a segmentation fault when hitting 1024 listeners, and crashes.

The ulimit is raised for all users. Tested on both root and non-root user (with sudo rights).

code:
./start.sh: line 19:  1445 Segmentation fault      ./sc_serv /home/shoutcast/server/sc_serv_custom.conf

(start.sh is my script that launches Shoutcast)

ulimit -a returns the following (with the changed open files directive).

code:


code:
[root@dedi11 server]# ulimit -a

core file size          (blocks, -c) 0

data seg size           (kbytes, -d) unlimited

scheduling priority             (-e) 0

file size               (blocks, -f) unlimited

pending signals                 (-i) 125147

max locked memory       (kbytes, -l) 64

max memory size         (kbytes, -m) unlimited

open files                      (-n) 16384

pipe size            (512 bytes, -p) 8

POSIX message queues     (bytes, -q) 819200

real-time priority              (-r) 0

stack size              (kbytes, -s) 10240

cpu time               (seconds, -t) unlimited

max user processes              (-u) 1024

virtual memory          (kbytes, -v) unlimited

file locks                      (-x) unlimited

Does anyone know why this happens and/or how to solve it?

Thanks in advance.

[DrO]

see http://forums.winamp.com/showthread.php?t=332841#known and point #5

-daz

[luis.alen]

DrO,

Why is that? I'm wondering here... Am I missing something?

I have all limits set properly and dnas version 1.9.8 runs smoothly with more than 1.5k listeners.

When I try to do the same with dnas 2 (sc_serv2_linux_x64_07_31_2011.tar.gz), it crashes after exactly 1038 listeners.

Is there a newer version with a correction for this bug?

I'm quite sure this is not a limit imposed by my operating system...

[DrO]

v1 and v2 are completely different code bases and just because v1 could go that high unfortunately doesn't mean v2 currently can go that high (which in all honesty is not the norm for listener numbers with listed stations).

there was work being done in the internal builds to try to try to resolve it (which was working ok up to 1000-1500 listeners depending on the platform build, other processes and system interations, sun-spots, etc), but going above 1500 was still an issue with the modifications to the v2 DNAS and so requires a re-write of part of the networking stack for linux versions.

so you are correct, it has nothing to do with the OS limits, it's purely down to how the v2 DNAS has been originally coded (which was for making it easier to do cross-platform but alas has caused a number of issues like this with scaling).

there is no publically available 'fixed' version as it has not been completely resolved in the internal builds and i cannot provide interim builds of the DNAS either (before that is asked).