List reversal produced incorrect list if USE_MUNMAP+GC_GCJ_SUPPORT (Mingw32)

[ivmai]

i686-w64-mingw32-gcc -I include -DUSE_MMAP -DUSE_MUNMAP -DGC_GCJ_SUPPORT -I libatomic_ops/src -O0 -g tests/test.c extra/gc.c

Simplified code to reproduce the crash:
sexpr h;
int i;
h = gcj_ints(1,200);
for (i = 0; i < 10; ++i) {
check_ints(h, 1,200);
h = gcj_reverse(h);
h = gcj_reverse(h);
}
check_ints(h, 1,200); // check fails here

[ivmai]

Also SIGSEGV in check_ints reproduced with: i686-w64-mingw32-gcc -I include -DGC_GCJ_SUPPORT -O0 -g tests/test.c extra/gc.c
Not happen if -DNO_INCREMENTAL.

[ivmai]

This issue could be fixed by 2 changes:

• revert of pull Large offset in negative GC_DS_PER_OBJECT descriptors can lead to arbitrary data being misinterpreted as type descriptors #92 (commit 57f36b9)
• the following temporal workaround:
  diff --git a/alloc.c b/alloc.c
  index 0db6458..0ca09c6 100644
  --- a/alloc.c
  +++ b/alloc.c
  @@ -1426,7 +1426,7 @@ GC_INNER ptr_t GC_allocobj(size_t gran, int kind)
  /* Do our share of marking work /
  if(TRUE_INCREMENTAL) GC_collect_a_little_inner(1);
  / Sweep blocks for objects of this size */
  - GC_continue_reclaim(gran, kind);
  + if (!GC_collection_in_progress()) GC_continue_reclaim(gran, kind);
  EXIT_GC();
  if (*flh == 0) {
  GC_new_hblk(gran, kind);

[ivmai]

The issue cannot be reproduced after the above revert (by ef5041d).
Also to check that reclaiming of reachable objects that are not marked yet during true incremental GC, an assertion is added - 2c5aebc