[azul]

I've recently encountered an issue on the latest build of TFC (version : 48/1.1.2.2/Stdio 8308 secure (20)) whereby infecting an enemy guarantees a segfault within a few seconds. Here is a dump from the debug.log showing where the problem is:

---------------------------------------------- CRASH: Tue Mar 3 20:07:32 CST 2020 Start Line: ./hlds_linux -game tfc +ip <removed> +maxplayers 17 +hpk_maxsize 1 -debug -console -noaff -pingboost 2 -norestart -pidfile hlds.27777.pid [New LWP 27785] [New LWP 27795] [New LWP 27791] [New LWP 27796] [New LWP 27797] [New LWP 27788] [New LWP 27798] [New LWP 27789] [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". Core was generated by `./hlds_linux -game tfc +ip <removed> +maxplayers 17 +hpk_maxsize 1 -debug -'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0xf2da0483 in Client_Damage(void*) () from tfc/addons/amxmodx/modules/tfcx_amxx_i386.so [Current thread is 1 (Thread 0xf7bcf700 (LWP 27785))] #0 0xf2da0483 in Client_Damage(void*) () from tfc/addons/amxmodx/modules/tfcx_amxx_i386.so #1 0xf7a7e740 in userfilters () from /servers/akw/engine_i486.so #2 0xf32e9010 in ?? () Backtrace stopped: previous frame inner to this frame (corrupt stack?) No symbol table info available. From To Syms Read Shared Object Library 0xf7f0e914 0xf7f54c78 Yes ./libstdc++.so.6 0xf7eb4ab0 0xf7eb5c64 Yes (*) /lib32/libdl.so.2 0xf7e989b0 0xf7ea9d1f Yes (*) /lib32/libpthread.so.0 0xf7cc95a0 0xf7e21e06 Yes (*) /lib32/libc.so.6 0xf7bef570 0xf7c78e95 Yes (*) /lib32/libm.so.6 0xf7f9da40 0xf7fb852b Yes (*) /lib/ld-linux.so.2 0xf7bd2e04 0xf7be2490 Yes ./libgcc_s.so.1 0xf76b35e0 0xf773970c Yes /servers/akw/engine_i486.so 0xf76585c0 0xf7662d74 Yes (*) ./libsteam_api.so 0xf764d8e0 0xf76517d4 Yes (*) /lib32/librt.so.1 0xf7634aa0 0xf7641428 Yes /servers/akw/filesystem_stdio.so 0xf5dcb0c0 0xf6f76d64 Yes (*) ./steamclient.so 0xf5c44670 0xf5cba020 Yes (*) ./crashhandler.so 0xf337e560 0xf3417128 Yes (*) /servers/akw/./tfc/addons/metamod/dlls/metamodn.so 0xf31baa10 0xf3285a8c Yes /servers/akw/tfc/dlls/tfc.so 0xf2f4bbc0 0xf2faddc7 Yes (*) /servers/akw/tfc/addons/amxmodx/dlls/amxmodx_mm_i386.so 0xf2d9b650 0xf2da1f38 Yes (*) tfc/addons/amxmodx/modules/tfcx_amxx_i386.so 0xf2471b60 0xf2478af4 Yes (*) /lib32/libnss_files.so.2 0xf2469b50 0xf246caf4 Yes (*) /lib32/libnss_dns.so.2 0xf2453640 0xf2460054 Yes (*) /lib32/libresolv.so.2 (*): Shared library is missing debugging information. Stack level 0, frame at 0xff8cfca0: eip = 0xf2da0483 in Client_Damage(void*); saved eip = 0xf7a7e740 called by frame at 0xff8cfca4 Arglist at 0xff8cfc98, args: Locals at 0xff8cfc98, Previous frame's sp is 0xff8cfca0 Saved registers: ebx at 0xff8cfc94, esi at 0xff8cfc8c, edi at 0xff8cfc90, eip at 0xff8cfc9c End of crash report ----------------------------------------------

We've tested on AMX-1.9.0-5263, as well as a few 1.8.3 versions that we've used in the past: 5116, 5134, 5154. There were no issues on older builds of TFC as recent as (version : 48/1.1.2.2/Stdio 8196 secure (20)). As a temporary solution I would roll back the library myself but currently our server provider is standing in the way of that process.

We've also tried switching from Metamod 1.21-am to Metamod-P 1.21p37 to no avail.

I should note that this has been tested on a completely fresh server installation of TFC, metamod, and AMXX without any custom plugins present.

I would report this on the Alliedmodders bugzilla but I can't seem to find a way to select AMX Mod X as the product in question so I will try here.

[Recon224]

Not sure if you ever found a fix for this but maybe you should try removing the tfcx module in the amxx/modules folder. I know it isn't ideal especially if you use tfc-specific plugins but this seems to be the only way I was able to avoid any crashes.

Hope this helps you and others that may be looking for an answer.

[pizzahut]

This bug has been fixed in the latest AMXX 1.9 and 1.10.

Thanks to Shooting King !