AssaultCube Reloaded Forums

Full Version: Regarding the Crashes
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2
I know that it is a segmentation fault that causes it, but I could not find it.

I am running the "official server" as an experiment. It runs on the latest version possible. If it does not get a segfault over time, then I will know that the problem is likely fixed and I should make a new release soon. Otherwise, I will continue to look for the issue.

2.3.4 is coming soon.

All bugs are fixed, and verified with the following command:
/alias lol [gamespeed 1000;sleep 1000 [lol]];lol;botbalance 20

The testing procedure is to use the above command, wait for next round, and repeat once.

No crash occurred from the testing the first time.

EDIT: Looks like a crash from some subsequent tests... time to compile a debug client.

EDIT 2: The debug server (and Visual Studio's debugger) has found a buffer overflow that occurred from a typo.

EDIT 3: enet got a stack overflow when it ran out of memory (probably due to the way I was testing it, server debug with 40x speed), but should be "stable" now as there is no need to run a server at 40x.

EDIT 4: enet bug only happens if suicide bomber is deployed (infinite loop makes infinite packets, then enet can't allocate memory on the heap!)

EDIT 6: description of edit 3/4's bug:
you are about to be killed -> suicide bomber is deployed -> you are about to be killed -> suicide bomber is deployed -> ...
and it runs out of memory making packets on the heap for this...

but fixed in SVN.

EDIT 5: merged 2.3.4 with crash thread
So basically there may be a 2.3.4 soon? lol
Yes, but hopefully not a 2.3.5 anytime soon.
New servers get segfaults very often. Try to collect debug information.

ACR server is down again.
I still can't find where the segfaults are in the code.
I'm sure that one of your commits produces segfaultSmile

First of all pay attention on memory allocation and memory cleaning, entity handling, and so on.

Debugger may give you more information about crash: backtrace or even line of code where crash happens.

I got crash caused by malloc/free memory corruption.

@RPG: are you 100% sure that it is "malloc/free memory corruption" and not new/delete? or new[]/delete[]?

I will look for malloc issues...

EDIT: only enet uses malloc, but no calls are made to malloc() in the ACR code. And only one call to free() from something created by backtrace_symbols().

It must be a mistake I made with new/delete or new[]/delete[].
ohh, of course, malloc/free in pure C is equal new/delete in C++Smile

enet is written on C, AC - C++
Do you see any mistakes in the code? I couldn't find any regarding this segmentation fault.
What code exactly you talking about? I can't read whole source of the gameSmile
Pages: 1 2