PDA

View Full Version : Killing ambient_generic doesn't stop the sound.



Nero
31-05-2016, 01:06 PM
As the title says ;o
g_EntityFuncs.Remove(); doesn't do the trick either.

Solokiller
31-05-2016, 01:36 PM
Should be easy enough to fix:



void CAmbientGeneric::UpdateOnRemove()
{
this->Use( pev, pev, USE_OFF, 0 );

CBaseEntity::UpdateOnRemove();
}


UpdateOnRemove because being removed on map change shouldn't send a message to stop the sound. The client will/should stop it anyway.

AdamR
01-06-2016, 12:48 PM
Not sure why this wouldn't be in OnDestroy().

void CAmbientGeneric :: OnDestroy( void )
{
this->Use( this, this, USE_OFF, 0 );
}

Solokiller
01-06-2016, 01:00 PM
Because



UpdateOnRemove because being removed on map change shouldn't send a message to stop the sound. The client will/should stop it anyway.

UpdateOnRemove is called for every killtarget/UTIL_Remove. OnDestroy is called for those, and also called when the engine destroys them on map change, when you're just wasting CPU time and bandwidth doing that. Additionally, OnDestroy doing stuff like this tends to cause crashes if it accesses invalidated data.

Also, if you are going to use OnDestroy, don't forget to call the baseclass version. You don't want any memory leaks or invalid state.

AdamR
18-07-2016, 02:05 PM
Turns out both methods appear to be responsible for causing some crashes anyway.

swampdog
19-07-2016, 01:00 PM
Additionally, OnDestroy doing stuff like this tends to cause crashes if it accesses invalidated data.

Also, if you are going to use OnDestroy, don't forget to call the baseclass version. You don't want any memory leaks or invalid state.

Could this be what is causing most of the 5.04 server crashes on map change? I have been figuring it is either a model or sound related issue dealing with map design, where the server cannot find the correct address in memory (or tries to find an address that has nothing in it??). At first I figured it was related to timing & map design with killing targets before map change with trigger_changelevel or game_end entities. afrikakorps3 crashes on map change 9 out of 10 times (maybe more like 14 out of 15) now, where it did not have any problems at all in 5.03 as far as I know. The afrikakorps series was one of the most stable map series we had in 5.03, and now I can't host those maps because of the crashing. The map "pizza_ya_san1" also has an identical crash? pizza_ya_san1 crashes every single time. I have tested these maps on Ubuntu 14.04.3 & 14.04.4 LTS x64 Dedicated Server, and Windows 7 Home x64 listen server. We tested a bit using a Windows Dedicated Server, and there was no crash with either afrikakorps3 or pizza_ya_san1. I tried doing everything I could to stop the crashing, including tearing nearly everything out of afrikakorps3 and pizza_ya_san1 with ripent (I stopped before removing ALL of the sounds). I believe you may be able to reproduce this crash fairly easily with afrikakorps3 or pizza_ya_san1. It seems to happen far more on certain maps than others. The debug.log file for me looks like this for every crash that happens on map change (the server causes the client to get disconnected after a timeout, and the server has a segfault):

CRASH: Mon Jul 18 04:59:07 CDT 2016
Start Line: ./svends_i686 -pidfile ogp_game_startup.pid +hostname ModRiot.com Sven Co-op 5.04 Test Server +map _server_start +ip 204.12.193.253 +port 27020 +maxplayers 32 -nohltv -debug -num_edicts 8192 -heapsize 512M
[New LWP 23302]
[New LWP 23305]
[New LWP 23307]
#0 0xd4b91134 in ?? ()
End of crash report

Am I doing something wrong generating the crash report, or is this really all the info there is about this crash when it dumps? I haven't been able to produce any more descriptive information using any other crash information programs. This crash also happens with or without Metamod, and with or without any custom Angelscript plugins.

Selekt0r
19-07-2016, 01:06 PM
Have you tried generating a backtrace using gdb? You can do this by attaching gdb when it has crashed, but that's only possible if it doesn't fully exit after crashing.
Otherwise, start svends using gdb and use the "bt" command when it triggers a crash.

swampdog
19-07-2016, 01:21 PM
I could use some help figuring out how to use GDB more effectively. I have tried using the backtrace command with gdb on the dump file, and it generates the same information. (Edit: I didn't get so far yet as to be able to do a backtrace, I just thought I had.) I am assuming I am doing something incorrect. If possible, it would be very helpful to have a manual or guide designed to help with this crash reporting process. I am somewhat of a noob and am only guessing based on my knowledge of computer science and goldsource. I may not know how to attach gdb to the process correctly. I have tried using the -gdb parameter which does not appear to generate any extra information. Any help here would be appreciated. Thank you...

Selekt0r
19-07-2016, 01:29 PM
This website should explain everything you need: https://www.chemie.fu-berlin.de/chemnet/use/info/gdb/gdb_5.html

If i understand it correctly, this should do it for you:


cd <your svends dir>
gdb
set args -pidfile ogp_game_startup.pid +hostname ModRiot.com Sven Co-op 5.04 Test Server +map _server_start +ip 204.12.193.253 +port 27020 +maxplayers 32 -nohltv -debug -num_edicts 8192 -heapsize 512M
run ./svends_i686


If it stops after starting, use the continue command to make it resume execution.

swampdog
19-07-2016, 01:33 PM
Thank you. I will try this and see if it produces any more information.

Edit: It will probably be a while before I figure out how to do this properly. I am hoping someone else can reproduce the crash and gain the backtrace information before I can figure out how to use gdb or a windows debugger well enough to do this myself. I will try to provide what information I can when I manage to figure out how to do this correctly.

swampdog
20-07-2016, 01:23 AM
I thought I did this earlier. I am still confused about whether or not I am doing this right. These are the same results I got before:

BFD: Warning: /path/to/svends_install/core is truncated: expected core file size >= 603443200, found: 1024000.
[New LWP 23302]
[New LWP 23305]
[New LWP 23307]
Cannot access memory at address 0xf77a5928
Cannot access memory at address 0xf77a5924
(gdb) bt
Python Exception <class 'gdb.MemoryError'> Cannot access memory at address 0xffb2ae00:
#0 0xd4b91134 in ?? ()
Cannot access memory at address 0xffb2ae00

So I guess doing a backtrace doesn't reveal much more information? I am assuming there is a way to find out more information still, but I don't know enough yet to say that I know what I am doing. I hope it helps, and if not I hope someone finds a solution to this map change crash. I am willing to share some access to a server if it could be helpful to anyone on the development team.

Selekt0r
20-07-2016, 03:56 AM
The crash might be caused by stack corruption. In that case, backtrace information won't be valid.

Do you have logging enabled? Could you post the logs leading up to some of these crashes?

Duggles
20-07-2016, 05:35 AM
Before you run gdb run the command

'ulimit -c unlimited'

This will allow core dumps to actually be of the correct size (they're usually truncated by default in linux distros). If will also get rid of the warning 'BFD: Warning...'.

I don't typically have the hostname directive in the arguments, but since it isn't in quotes I'm a little worried.

Also, you have to change your loader library path. If you look at the standard svends_run shell script (near the top) you can see that the LD_LIBRARY_PATH environment variable is modified so the loader will search for libraries in the current directory.

So, before you run gdb you should do:

'export LD_LIBRARY_PATH:./:$LD_LIBRARY_PATH'

Try those things and hopefully that will make it clearer.

nico
20-07-2016, 05:56 AM
'ulimit -c unlimited'

The svends start script btw does not recognize "unlimited", only numbers. It's throwing a warning every server start. Might want to adjust that.

Duggles
20-07-2016, 06:23 AM
The svends start script btw does not recognize "unlimited", only numbers. It's throwing a warning every server start. Might want to adjust that.

I see the problem, it's using integer comparison operators. I'll tweak the script to check for strings instead (and throw in a clause for 'unlimited' too).

swampdog
21-07-2016, 12:47 AM
Thank you for all the help and information. I was able to figure out how to get the dump to work. I will possibly upload it somewhere and post a link, but would rather privately do so as I don't know about all the information contained in the dump file (and it is almost 7GB). Here is the information regarding the dump on pastebin, as well as server log and console log WITH Metamod+AMXX and WITHOUT Metamod (I tried to be as thorough as possible, even including step-by-step instructions on how I made the dumping process work): http://pastebin.com/4jTnmr0X

It appears
#0 0xd4a66134 in CBaseMonster::OnDestroy() () from /path/to/svends_install/svencoop/dlls/server.so

This would be responsible for the crash ? I am very new to using gdb, and I am just assuming this is where the segfault occurs or begins.

Duggles
21-07-2016, 02:19 AM
Brilliant, I'm glad that worked. I forgot to mention that coredumps are able to be compressed, and usually shrink to a very small size. The backtrace is a great start. If you get the crash again (or load the coredump into gdb) can you also do 'info registers'? That can help find exactly where the fault is happening in the code.


To load a core dump into gdb (which essentially gives you the snapshot where the game crashed so you can look at the backtrace/etc. again) all you need to do is:
(go to the Sven Co-op directory)
gdb svends_i686 name_of_core_file

Then you should be able to get the information for the registers.

swampdog
21-07-2016, 02:32 AM
http://pastebin.com/zPcqNJvC Here is the information that I get when using "info registers" command in gdb with the latest core file (which is when not using Metamod). I hope this contains the info needed.

Duggles
21-07-2016, 04:23 AM
That seemed to work correctly. I'll have a look at the code after work today to see what piece of code is failing. Having the backtrace is great because it can tell programmers which function is failing. Showing the registers means we can see what part of the assembly is failing (shown by the 'eip' register) and we can diagnose more precisely what is messing up.