[bf1942] v1.3 problem

[SHiNTAR]

Ryan C. Gordon wrote:

>Backtraces are generally useful...run this before the game:
>
>ulimit -c unlimited
>
>When it crashes, it'll leave a "core" file ("core.processnumber" or just
>plain "core" or something). Run that in gdb:
>
>gdb ./bf1942_lnxded core.xxxx
>
>When gdb gets to it's command prompt, type "bt".
>
>That should produce a couple lines of data. Send me those lines.
>
>Thanks,
>--ryan.
>  
>
Sorry for the weird mime message before

Ryan,

I played around with it a bit more. Added more COOP bots to reproduce 
the problem faster.
Also I noticed in my logs an automatic kill on the battlefield proccess 
because it was using too much memory.

I had 24 bots running around and shooting eachother on the Turbok map

Here is the gdb output you requested:

Core was generated by `./bf1942_lnxded'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/libm.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib/libm.so.6
Reading symbols from /lib/libdl.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/libdl.so.2
Reading symbols from /lib/libpthread.so.0...(no debugging symbols 
found)...done.
Loaded symbols for /lib/libpthread.so.0
Reading symbols from /lib/libc.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/ld-linux.so.2...(no debugging symbols 
found)...done.
Loaded symbols for /lib/ld-linux.so.2
Reading symbols from /lib/libnss_files.so.2...(no debugging symbols 
found)...done.
Loaded symbols for /lib/libnss_files.so.2
Reading symbols from 
/data/battlefield/MultiplayerServers/GameSpyHost.so...(no debugging 
symbols found)...done.
Loaded symbols for /data/battlefield/MultiplayerServers/GameSpyHost.so
Reading symbols from /lib/libnss_dns.so.2...(no debugging symbols 
found)...done.
Loaded symbols for /lib/libnss_dns.so.2
Reading symbols from /lib/libresolv.so.2...(no debugging symbols 
found)...done.
Loaded symbols for /lib/libresolv.so.2
#0  0x09614802 in _STL::__node_alloc<true, 0>::_S_refill ()
(gdb) bt
#0  0x09614802 in _STL::__node_alloc<true, 0>::_S_refill ()
#1  0x09614879 in _STL::__node_alloc<true, 0>::_M_allocate ()
#2  0x09454e7c in _STL::deque<dice::bf::ai::SearchNode *, 
_STL::allocator<dice::bf::ai::SearchNode *> >::_M_push_back_aux_v ()
#3  0x08e61cca in dice::bf::ai::AStar::makePath ()
#4  0x08bfd34c in dice::bf::ai::AIPathfinding::localSearch ()
#5  0x08ca97a6 in dice::bf::ai::BotMain::updateLocalPath ()
#6  0x08ca8828 in dice::bf::ai::BotMain::updatePathfinding ()
#7  0x08c1f17d in dice::bf::ai::BotManager::actionPathfinding ()
#8  0x08c1bb1d in dice::bf::ai::BotManager::action ()
#9  0x08beaab0 in dice::bf::ai::AIMain::action ()
#10 0x08b9429e in dice::bf::GameServer::updateAI ()
#11 0x08bb7d78 in dice::bf::GameServer::simulateFrame ()
#12 0x08b79cd1 in dice::bf::GameServer::update ()
#13 0x0867a99a in dice::bf::Setup::mainLoop ()
#14 0x0867a031 in dice::bf::Setup::start ()
#15 0x0862ba6a in main ()
#16 0x4006914f in __libc_start_main () from /lib/libc.so.6


The server starts and runs with around 100mb of memory in use. After 
running this for a while it starts growing into swap :( and eventually 
makes the machine unusable until it decides to segfault or being killed 
by the kernel if ran as non-root.

here are some paging statistics from my sar output:

(column definitions: time - pages paged in/sec - pages paged out/sec - 
active pages)

09:15:01        37.27      3.69      2460
09:20:01        37.87      5.42      9266
09:25:01         0.00      3.35      9521
09:30:05       456.98   4051.48     85071
09:35:03      1081.61   2142.74     68601
09:40:02       843.06   1668.30     67595
09:45:03       833.94   1667.54     67283
09:50:03       843.60   1661.65     67333
09:55:03       251.13   1438.99     38885
10:05:02        54.09     94.75      4786

The server started at 09:18 and crash point somewhere after 09:55 ...

CPU utilisation:
(time - CPU - %user - %nice - %stystem - %idle)

09:15:01          all     25.49      0.00      0.75     73.76
09:20:01          all     32.62      0.00      1.44     65.94
09:25:01          all     28.97      0.00      0.35     70.68
09:30:05          all     18.85      0.00     20.49     60.66
09:35:03          all      0.05      0.00     88.32     11.64
09:40:02          all      0.17      0.00     91.31      8.52
09:45:03          all      0.07      0.00     92.20      7.72
09:50:03          all      0.05      0.00     91.46      8.50
09:55:03          all      0.07      0.00     97.41      2.52
10:05:02          all      1.83      0.00      2.23     95.94

just after the pageing stats go up a lot, you can see the system time 
increasing too. Because it starts to swap away.

The machine has 512mb ram running on an AMD 900Mhz. Not too heavily 
spec'ed. At the time of testing, no other machine intensive proccesses 
were running.


>  
>