[bf1942] crashes on connect/mapchange...

Greg itooo at itooo.com
Tue Dec 10 16:16:29 EST 2002


Is it okay that the three processes use 72Mbytes of memory each before
any client is connected ? that seems huge for me. It also seems huge
for me a 40Mbytes executable, how many lines of code did you produce ?
50 millions ? (please dont tell me you store ressources in your linux
binary :p)
--------------
Tuesday, December 10, 2002, 8:38:38 PM:


>> glibc-2.2.4-31

RCG> I wonder if it's a glibc incompatibility...

>> I did a "ps -ef" and noticed that the first process spawns the second, which
>> in turn spawns the third:
>>
>> tom       1441  1060 10 14:13 pts/5    00:00:35 ./bf1942_lnxded
>> tom       1442  1441  0 14:13 pts/5    00:00:00 ./bf1942_lnxded
>> tom       1443  1442  0 14:13 pts/5    00:00:00 ./bf1942_lnxded

RCG> Under Linux, each thread is a process.

RCG> The first thread is the main program. The second one is the "monitor"
RCG> thread (which glibc spawns when you spin your first thread), and the third
RCG> is the socket i/o thread, which does all the talking to clients. The
RCG> firsst thread should use significantly more CPU time than the other three.

>> Perhaps that's due to the constant STUB messages that repeat.  When the
>> server tries to change maps on its own, the bf1942_lnxded processes die and
>> are replaced by new ones before the server crashes.

RCG> The server restarts itself (literally...with an execl() call) between each
RCG> map...the win32 version does this, too. (Actually, the client does, also,
RCG> now that I think about it).

RCG> --ryan.




More information about the Bf1942 mailing list