Server Crashes

[tChr]

muy server seems to be running fine btw.. vanilla debian 4 with nexuiz running from downloaded zip, not from reps.

[Ronan]

I'm using nexuizdebug20070531d_2.3.zip with enginesource20070531.zip (from nexuizsource20070531d_2.3.zip)
Should I use another build ?

[Sxen]

Just for the sake of completeness: the new DCC box is a dual-core CPU (Opteron 1212).

[divVerent]

I'm using nexuizdebug20070531d_2.3.zip with enginesource20070531.zip (from nexuizsource20070531d_2.3.zip)
Should I use another build ?

nexuizdebug is actually a release build with debug info, so stuff is still optimized out. It mainly is to be used to find crash locations from the release build, which is the debug build after stripping.

For real debugging, you should compile your own build. Inside the enginesource, type "make sv-debug && ln -snf darkplaces-dedicated nexuiz-dedicated" and use that one.

[tChr]

Just for the sake of completeness: the new DCC box is a dual-core CPU (Opteron 1212).

mine is an a64x2

[Ronan]

With the debug build :

Code: Select all

Core was generated by `./nexuiz-dedicated +exec spacectf.cfg'.
Program terminated with signal 11, Segmentation fault.
#0  0x0814d828 in PRVM_ExecuteProgram (fnum=520,
    errormessage=0x81dd9c0 "customizeentityforclient: NULL function") at prvm_exec.c:519
519             st = &prog->statements[PRVM_EnterFunction (f)];



Code: Select all

(gdb) bt full
#0  0x0814d828 in PRVM_ExecuteProgram (fnum=520,
    errormessage=0x81dd9c0 "customizeentityforclient: NULL function") at prvm_exec.c:519
        st = (dstatement_t *) 0x0
        startst = (dstatement_t *) 0x0
        f = (mfunction_t *) 0x12df856c
        newf = (mfunction_t *) 0x0
        ed = (prvm_edict_t *) 0x0
        ptr = (prvm_eval_t *) 0x0
        jumpcount = 0
        cachedpr_trace = 0
        exitdepth = 0
        restorevm_tempstringsbuf_cursize = 0


new crash :

Code: Select all

#0  0x08183842 in SV_BuildEntityState (cs=0x0, ent=0x12cdad84, enumber=164)
    at sv_main.c:825
825             customizeentityforclient = PRVM_EDICTFIELDVALUE(ent, prog->fieldoffsets.customizeentityforclient)->function;



Code: Select all

(gdb) bt full
#0  0x08183842 in SV_BuildEntityState (cs=0x0, ent=0x12cdad84, enumber=164)
    at sv_main.c:825
        i = 0
        tagentity = 0
        modelindex = 0
        effects = 0
        flags = 0
        glowsize = 0
        lightstyle = 0
        lightpflags = 0
        light = {0, 0, 0, 0}
        specialvisibilityradius = 0
        customizeentityforclient = 0
        f = 0
        cullmins = {0, 0, 0}
        cullmaxs = {0, 0, 0}
        netcenter = {0, 0, 0}
        model = (model_t *) 0x0
        val = (prvm_eval_t *) 0x0


With so many crashs I suppose it's a hardware problem...

[LordHavoc]

With the debug build :

Code: Select all

Core was generated by `./nexuiz-dedicated +exec spacectf.cfg'.
Program terminated with signal 11, Segmentation fault.
#0  0x0814d828 in PRVM_ExecuteProgram (fnum=520,
    errormessage=0x81dd9c0 "customizeentityforclient: NULL function") at prvm_exec.c:519
519             st = &prog->statements[PRVM_EnterFunction (f)];



I'm unsure how it is possible for this line to crash, prog is valid (considering it got past the fnum check above), &prog->statements[] can't crash in any way I can imagine, PRVM_EnterFunction is not inlined in a debug build so it can't be crashing on f in any way.

This takes more inspection of the variables at the time of the crash.

Please paste the results of these commands:
print prog
print prog->statements
print prog->statements[0]
print f
print *f

[Nil]

The DCC's servers are running a debug binary build with optimization turned off since five days now and there has not been a single crash.

Cheers.

[LordHavoc]

The DCC's servers are running a debug binary build with optimization turned off since five days now and there has not been a single crash.

Cheers.

So it is optimization related? That can't be good.

What architecture is the binary, and do you have any ideas on when the crash occurs?

[Nil]

So it is optimization related? That can't be good.

What architecture is the binary, and do you have any ideas on when the crash occurs?

Since my last message there have been 3 crashes at server start (the servers are getting killed and restarted each morning by a cron script). They are started within "screen" (screen manager with VT100/ANSI terminal emulation). Maybe this could be a problem?

The pattern is the same as before. But still no crash once the servers are up and running.

The binary has been built with "make sv-debug" from the Nexuiz 2.3 source with "CPUOPTIMIZATIONS=" in makefile.inc (rest not changed). So I guess the architecture its generic 386.

I have pasted the backtrace to http://paste.debian.net/33770.

Common.c is modified as suggested bei Divverent by adding the following lines at top of COM_ParseToken_VM_Tokenize in order to find out more about the data whose processing causes the segmentation fault:

Code: Select all

static const char *string_to_tokenize;
string_to_tokenize = *datapointer;

Printing "string_to_tokenize" in gdb just shows that the address is out of bound, so this did not help much.