[Jillchang]

Any idea what this crash means? Always happens after map change as shown in log snippet below.
Keeps coming and can't seem to figure it out.

---- Host_Changelevel ----
*** buffer overflow detected ***: ./srcds_linux terminated
SoundEmitter:  removing map sound overrides [17 to remove, 17 to restore]
L 06/21/2017 - 12:51:59: [META] Loaded 0 plugins (1 already loaded)
======= Backtrace: =========
/lib/i386-linux-gnu/i686/cmov/libc.so.6(+0x6c773)[0xf75f1773]
/lib/i386-linux-gnu/i686/cmov/libc.so.6(__fortify_fail+0x45)[0xf76819b5]
/lib/i386-linux-gnu/i686/cmov/libc.so.6(+0xfaa6a)[0xf767fa6a]
/lib/i386-linux-gnu/i686/cmov/libc.so.6(+0xfc8ca)[0xf76818ca]
/home/tf2server2/serverfiles/bin/engine_srv.so(+0x93416)[0xf5ee4416]
/home/tf2server2/serverfiles/bin/engine_srv.so(+0x1d3341)[0xf6024341]
/home/tf2server2/serverfiles/bin/engine_srv.so(+0x1d3ed7)[0xf6024ed7]
/home/tf2server2/serverfiles/bin/engine_srv.so(+0x1d4581)[0xf6025581]
/lib/i386-linux-gnu/i686/cmov/libpthread.so.0(+0x6ecb)[0xf7739ecb]
/lib/i386-linux-gnu/i686/cmov/libc.so.6(clone+0x5e)[0xf7670d0e]
======= Memory map: ========
08048000-08049000 r-xp 00000000 fe:00 54796440                           /home/tf2server2/serverfiles/srcds_linux
08049000-0804a000 r--p 00001000 fe:00 54796440                           /home/tf2server2/serverfiles/srcds_linux
0804a000-0804b000 rw-p 00002000 fe:00 54796440                           /home/tf2server2/serverfiles/srcds_linux
08c54000-207e2000 rw-p 00000000 00:00 0                                  [heap]
d67ad000-d6fae000 rw-p 00000000 00:00 0 
d7d00000-d7dfd000 rw-p 00000000 00:00 0 
d7dfd000-d7e00000 ---p 00000000 00:00 0 
d7e00000-d7efd000 rw-p 00000000 00:00 0 
d7efd000-d7f00000 ---p 00000000 00:00 0 
d7f00000-d7ffd000 rw-p 00000000 00:00 0 
d7ffd000-d8000000 ---p 00000000 00:00 0 
d8000000-d80fe000 rw-p 00000000 00:00 0 
d80fe000-d8100000 ---p 00000000 00:00 0 
d8100000-d81fd000 rw-p 00000000 00:00 0 
d81fd000-d8200000 ---p 00000000 00:00 0 
d8200000-d82fd000 rw-p 00000000 00:00 0 
d82fd000-d8300000 ---p 00000000 00:00 0 
d8300000-d83fd000 rw-p 00000000 00:00 0 
d83fd000-d8400000 ---p 00000000 00:00 0 
d8400000-d8425000 rw-p 00000000 00:00 0 
d8425000-d8500000 ---p 00000000 00:00 0 
d8600000-d86fd000 rw-p 00000000 00:00 0 
d86fd000-d8700000 ---p 00000000 00:00 0 
d8700000-d87fd000 rw-p 00000000 00:00 0 
d87fd000-d8800000 ---p 00000000 00:00 0 
d8800000-d88fd000 rw-p 00000000 00:00 0 
d88fd000-d8900000 ---p 00000000 00:00 0 
d8900000-d89fd000 rw-p 00000000 00:00 0 
d89fd000-d8a00000 ---p 00000000 00:00 0 
d8a00000-d8afd000 rw-p 00000000 00:00 0 
d8afd000-d8b00000 ---p 00000000 00:00 0 
d8c00000-d8cfd000 rw-p 00000000 00:00 0 
d8cfd000-d8d00000 ---p 00000000 00:00 0 
d8d00000-d8dfe000 rw-p 00000000 00:00 0 
d8dfe000-d8e00000 ---p 00000000 00:00 0 
d8e00000-d8efd000 rw-p 00000000 00:00 0 
d8efd000-d8f00000 ---p 00000000 00:00 0 
d8fff000-d9000000 ---p 00000000 00:00 0 
d9000000-d9900000 rwxp 00000000 00:00 0                                  [stack:32566]

[Jillchang]

Here is also logs I just got from accelerator:
Seems like it's outside of sourcemod and more into srcds issues? Any idea?

1	libc-2.19.so + 0xfc9b5
2	libc-2.19.so + 0x1621fd
3	libc-2.19.so + 0x16217e
4	libc-2.19.so + 0xfc97b
5	libc-2.19.so + 0xfaa6a
6	engine_srv.so!Win32UploadGameStatsBlocking(TGameStatsParameters const&) + 0x2e1
7	engine_srv.so!CAsyncUploaderThread::ThreadProc() + 0x507
8	engine_srv.so!CAsyncUploaderThread::CallbackThreadProc(void*) + 0x11
9	libpthread-2.19.so + 0x6ecb
10	libc-2.19.so + 0xebd0e

[Jillchang]

Just one more update, it seems like my new OS install (Debian 8 ) is having issues with scripts creating directories. I wonder if this has to do with certain permission configuration other than the usuallay CHMOD. The CHMOD permissions are all set as usual, so it must be something else. Debian doesn't have a sudo system by default so I don't know what else to look at. Still investigating, this bug is hurting though

[DarkDeviL]

Originally Posted by Jillchang Still investigating, this bug is hurting though

It has been up in other threads that you should link to the Accelerator crash (and/or give crash ID) rather than copy-pasting stuff from it.

I haven't seen anything indicating otherwise, so if you're looking to have anyone look at the crash, you might want to go that way as well.

[Jillchang]

Thank you for the heads up arne.
I boiled it down to OS version since I am using Debian 8 and perhaps it is because my previous installs were on Debian 7. Gonna try fresh install on Debian 7, despite it may bite me in the butt if steam requires higher glibc versions in the future.

Will look into how to give the proper link for Accelerator without exposing gameservertoken.

[DarkDeviL]

Originally Posted by Jillchang Thank you for the heads up arne. I boiled it down to OS version since I am using Debian 8 and perhaps it is because my previous installs were on Debian 7. Gonna try fresh install on Debian 7, despite it may bite me in the butt if steam requires higher glibc versions in the future.

Downgrading is usually a bad idea, Debian 9 has just been released, so I wouldn't suggest gonig below Debian 8.

Debian 6 won't work with Steam any more. Debian 6 has libc 2.11, where Steam now requires 2.12, but maybe you might be lucky with Debian 7.

Originally Posted by Jillchang Will look into how to give the proper link for Accelerator without exposing gameservertoken.

I was under the impression that those links would only present sensitive information to the server's owner (based on the plugin settings), assuming the owner was logged in on the Accelerator site.

You're of course more than welcome to try logging out, to start a private session in your browser, or similar things, and then see if you can see all those sensitive details before posting a such link, etc.

Due to the nature of GSLT tokens, I do fully understand your skepticism about this.