client.signal fails in Debian i386 stretch chroot

On 32-bit hardware with a 32-bit kernel the failure looked like this:

```
144:` node[ks->depth - 1].var == pv && "stop not matching TOS"
144: (Error occurred @3631 frags)
144: version 6.2.17176, custom build
144: -no_dynamic_options -client_lib '/tmp/dynamorio-build-debug/suite/tests/bin/libclient.events.dll.so;0;' -code_api -stderr_mask 12 -stack_size 56K -trace_threshold 5 -max_elide_jmp 0 -max_elide_call 0 -early_inject -emulate_brk -no_inline_ignored_syscalls -native_exec_default_list '' -no_native_exec_managed_code -no_indca
144: 0x4f436a64 0x710e5d90
144: 0x4f436c94 0x71155147
144: 0x4f436ce0 0x7106c569
144: 0x4f436d04 0x7106c6ce
144: 0x4f436d20 0x7106a61c
144: 0x4f436d38 0x7106a9c6
144: 0x4f436d50 0x7106ab3f
144: 0x4f436d60 0x7123fea4
144: 0x4f436d70 0x4f405040
144: 0x712738e8 0x00005883>
```

On 64-bit hardware with a 64-bit kernel (but still in a 32-bit chroot) there was a different failure, some kind of infinite loop by the looks of it, but there were also other failures in this case: `tool.drcacheoff.burst_*`, `api.static_*`, which were timing out.

Start by reproducing client.signal in the Debian i386 stretch chroot and inspect the debug check at stats.c:369, where the reported stop-matching-TOS failure occurs. Compare 32-bit hardware and 32-bit-kernel behavior with a 32-bit chroot on a 64-bit kernel, including the tool.drcacheoff.burst_* and api.static_* timeouts. Done means these failures no longer occur.

Written by the indexing model from the issue text.