Oh, and since on re-reading you also wanted more of a "Why is this happening now?" -- I should be more specific in that you can't really know just from this output. We can tell in this dump that the arena is corrupted. Usually that's because of a buffer overrun of the memory client or stale pointer usage... but as to exactly why it is happening now, what sequence in your workload causes it... I really couldn't say from just that information. This is the kernel equivalent of a SIGSEGV in libc on a free() call -- the kernel allocator metadata used to put the object back where it belongs got trashed.. so the free path blew up. Just the DPF doesn't tell you enough.
[For a little perspective -- this type of thing happens much more often in development, naturally -- and quite often the only way to track it down is to use an internal tool to force the equivalent of buffer under/overrun protection, etc. on a particular arena. By the time the dump happens, things are so mangled usually that you can't really say who did it].
(No points on this if any at all... I should have added this to the prior message).
