The freeze dump, is currently inside "modParams" script command. It is looking if a mod's picture exists, and trying to find what PBO it is in.
A freeze dump is only a snapshot of a instant in time. That's why we always write two freeze dumps, so we can see atleast two points and judge where the freeze might be at.

I can't see how it could be freezing inside of modParams, so it must be a infinite/near-infinite loop in the script that called it.

The script was called from a UI button "OnClick" eventhandler.
I cannot see which script file it was, but the "modParams" command was at line number 374.

Also note that modParams command is quite slow. Caching it with a hashmap would be good.

I cannot see which script file it was, but the "modParams" command was at line number 374.

That would be ace_arsenal_fnc_addListBoxItem (https://github.com/acemod/ACE3/blob/master/addons/arsenal/functions/fnc_addListBoxItem.sqf).
Interestingly, it's one of the places where we do cache the result of modParams.

so it must be a infinite/near-infinite loop in the script that called it

ace_arsenal_fnc_addListBoxItem is used to add items in the left panel (i.e. where e.g. weapons and uniforms are shown), so no loops involved, although that function will be called for every item displayed (so I assume several thousand times in this case).

i was able to crash the game with the modparams command by inserting a really log string as the modclass parameter...i wonder if the modlist i was using had an obfuscated modclass that could have caused a buffer overflow or something in an unusual way?