Run time error 4: index out of bounds is Pawn telling you a plugin read or wrote past the end of an array. In AMX Mod X that array is almost always indexed by a player id, and the value that blew the bounds is almost always 0 (world) or 33+ (past the last valid client). The error does not crash the server, but the plugin's execution is aborted at that point, so whatever it was doing — awarding a kill, saving stats, printing a message — silently does not happen. This guide gets you from the log line to the offending source line.
1. Turn on the debug trace
By default AMXX prints the error but not the line number. You need the trace. Add the debug flag to the plugin in addons/amxmodx/configs/plugins.ini:
mystats.amxx debug
Restart or amxx reload. Now the log carries a full call stack. Traces only exist if the plugin was compiled with debug info (it usually is); if you see Debug info not available, recompile the .sma without stripping symbols.
2. Read the trace
The message lands in addons/amxmodx/logs/L*.log (dated files), and looks like this:
L 07/14/2026 - 21:14:03: Run time error 4 (index out of bounds) L 07/14/2026 - 21:14:03: [0] mystats.amxx::save_frags (line 214) L 07/14/2026 - 21:14:03: [1] mystats.amxx::event_death (line 88)
Read it top-down: the crash is at save_frags, line 214, of mystats.sma, called from event_death. That is the exact location. You do not need to guess.
3. Fix the bounds
Open the source at that line. The overwhelmingly common cause is a per-player array declared one slot too small, or indexed by an id the code never validated. Player arrays must hold indices 0 through 32, so they need 33 slots:
new g_frags[33] // correct: indices 0..32 // new g_frags[32] // wrong: index 32 is out of bounds
The second common cause is using an attacker or victim id that can legitimately be 0 (the world, e.g. fall damage or a map trigger) without checking:
new attacker = read_data(1) if (attacker < 1 || attacker > get_maxplayers()) return PLUGIN_CONTINUE g_frags[attacker]++
Any event that reports a killer — DeathMsg, damage hooks — can hand you 0. Guard every id before you index with it.
4. If it is not your plugin
When the trace names a third-party plugin you did not write, you have three honest options: update it to a version that fixed the bug, report the line number upstream (you now have the exact one), or unload it. Do not "fix" it by widening an array blindly if you do not understand why the index went out of range — you will convert a clean abort into corrupted stats.
One more diagnostic habit worth keeping: note what the player was doing when the error fired. Error 4 is deterministic — the same action (a specific grenade, a knife kill, a fall death, a spectator switch) reproduces it. If your log shows the error only ever fires right after a round restart, or only when someone connects into slot 32, that pattern is a direct pointer at whether the bug is an off-by-one array size or an unvalidated id. The context around the trace is as useful as the line number.
Common errors
- Trace shows
<no debug>instead of line numbers — you forgot thedebugflag inplugins.ini, or the plugin was compiled with debug info stripped. Add the flag; recompile if needed. - Error 4 fires only with a full server — a strong sign of a
[32]-sized array: it never overflows until index 32 is actually used, which only happens when the 33rd slot fills. - You confused it with error 10 —
Run time error 10 (native error)is a different failure (a native was called with bad arguments). See that fix. Error 4 is purely an array-index problem in Pawn. - Index is a huge number like 2293 — you are indexing with an entity id (a weapon, a grenade) into a player-sized array. Those are not the same id space; index a
[2048]array or map entity ids separately.
Verification
After the fix, reload the plugin with the debug flag still on and reproduce the exact situation that triggered it — the same weapon, the same fall-damage death, the same full server. Watch the current log file:
tail -f addons/amxmodx/logs/L$(date +%m%d)*.log
No new error 4 across a full map, with the plugin actually doing its job (stats saved, message printed), means it is fixed. Once you are satisfied, you can drop the debug flag again for a small performance gain, though on most servers leaving it on is fine. For the wider picture of reading AMXX logs, see tracking down a bad plugin.
