for example i have some software that opens a 32-bit file pointer to write data to scratch files as it's running, and then later open a 32-bit file pointer to read data. problem is when my program writes "big" data as in when it writes a single file greater than 2GB I believe whatever 2^32 or 2^31 bytes comes out to be i forget the technical part of it right now. so don't think just the stack size set to unlimited should fix it, you need to scrutinize your program and really know what's going on and see where some number limit is being exceeded.

in regards to my 32-bit file pointer in code, they should have used fopen64 or whatever uses a long integer as a file pointer rather than a signed or unsigned 4 byte integer which causes my 2GB file limit size. I found that cause of the crash then figured, ok i'll make sure i don't write a single scratch file greater than 2GB and i'll just split things up into separate scratch files. Then i still crashed, with no difference in how it crashed with error messages and such so i didn't know if my 32-bit file pointer was the cause or not... until i realized i then exceeded the "nofile" limit which i think defaults to 128 if not specified in limits.conf. i was opening maybe a couple hundred file pointers and exceeded the nofile (number of open file pointers) security limit on the system. so really consider all those items in limits.conf along with trying to understand what the limits are of all the variables you are using.... 16-bit short integer signed has max of 32767 and min of -32768 things like that.

@ron7000, as in #6, the program was just dealing with 19 sockets and descriptor 10 and 11 were for 2 files less than 1M bytes.

14:49:09 select(30, [4 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29], [], [], NULL) = 1 (in [16])
14:49:16 time(NULL) = 1423144156
14:49:16 read(16, "\252\273\314\335RSEDC\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0T\323s\204\0\2B\252"..., 512) = 512

09:04:54 write(11, "6\1\0\0\2601\0\0\10\0\0\0\316%\10\0\0\0*\0\n\0\0\0%\0\0\0\254\0\0\0"..., 12720) = 12720
09:04:54 lseek(11, 0, SEEK_SET) = 0
09:04:54 fcntl64(11, F_SETLK, {type=F_UNLCK, whence=SEEK_CUR, start=0, len=1}) = 0
09:04:54 lseek(10, 0, SEEK_SET) = 0
09:04:54 write(10, "6\1\0\0\370\4\0\0\1\0\0\0t\361\2\0\0\4*\0\1\0\0\0'\1\0\0\332\4\0\0"..., 1272) = 1272
09:04:54 lseek(10, 0, SEEK_SET) = 0
09:04:54 fcntl64(10, F_SETLK, {type=F_UNLCK, whence=SEEK_CUR, start=0, len=1}) = 0
09:04:54 --- SIGSEGV (Segmentation fault) @ 0 (0) ---

It should have gone to the above select again if not crashed.

latest crash:

15:00:10 read(24, "\252\273\314\335xxxx\0\0\0\0\0\0\0\0\0\0\0\0\0\231T\364kY\0\1\366:"..., 512) = 512
15:00:10 mmap2(NULL, 2105344, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x588a0000
15:00:10 time(NULL) = 1425304810
15:00:10 time(NULL) = 1425304810
15:00:10 ioctl(24, FIONBIO, [1]) = 0
15:00:10 write(24, "\252\273\314\335xxxx\0\0\0\0\0\0\0\0\0\0\0\0\0\221T\364j\327\0\1\365l"..., 512) = 512
15:00:10 ioctl(24, FIONBIO, [0]) = 0
15:00:10 --- SIGSEGV (Segmentation fault) @ 0 (0) ---

system didn't have enough memory? LINUX bug?
memory 0x588a0000 returned by mmap2 was not writable?