From 4c1c10ef294459bef75c17ebfaff7f6f62825224 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Przemys=C5=82aw=20Czerpak?= <druzus@poczta.onet.pl>
Date: Wed, 26 Mar 2014 14:10:01 +0100
Subject: [PATCH] 2014-03-26 14:10 UTC+0100 Przemyslaw Czerpak
 (druzus/at/poczta.onet.pl)   * src/vm/garbage.c     ! added protection for
 activating GC from thread with unlocked HVM stack       when other thread is
 already executing GC passes. Such situation does       not happen in core
 code and the protections is only just in case.

  * src/vm/hvm.c
    ! do not release HVM thread STOP signal when GC mark pass is activated.
      It was very serious bug which could cause memory corruption when
      thread unlocked HVM stack what allow to start GC mark pass by other
      thread and then locked HVM and begin to change complex variables
      still scanned by the GC thread. This problem have existed from the
      beginning when I committed initial version of Harbour MT support.
      I do not remember why I added code to remove the STOP signal - probably
      I was experimenting with some new things working on Harbour MT code
      and I forgot to deactivate it.
      NOTE: 3-rd party developers who use GC collectible pointer items
            must not activate any PRG code execution inside their mark
            functions.
---
 ChangeLog.txt    | 20 ++++++++++++++++++++
 src/vm/garbage.c |  2 +-
 src/vm/hvm.c     |  1 -
 3 files changed, 21 insertions(+), 2 deletions(-)

diff --git a/ChangeLog.txt b/ChangeLog.txt
index b5cf92f736..1e909491c7 100644
--- a/ChangeLog.txt
+++ b/ChangeLog.txt
@@ -10,6 +10,26 @@
      * Change, ! Fix, % Optimization, + Addition, - Removal, ; Comment
  */
 
+2014-03-26 14:10 UTC+0100 Przemyslaw Czerpak (druzus/at/poczta.onet.pl)
+  * src/vm/garbage.c
+    ! added protection for activating GC from thread with unlocked HVM stack
+      when other thread is already executing GC passes. Such situation does
+      not happen in core code and the protections is only just in case.
+
+  * src/vm/hvm.c
+    ! do not release HVM thread STOP signal when GC mark pass is activated.
+      It was very serious bug which could cause memory corruption when
+      thread unlocked HVM stack what allow to start GC mark pass by other
+      thread and then locked HVM and begin to change complex variables
+      still scanned by the GC thread. This problem have existed from the
+      beginning when I committed initial version of Harbour MT support.
+      I do not remember why I added code to remove the STOP signal - probably
+      I was experimenting with some new things working on Harbour MT code
+      and I forgot to deactivate it.
+      NOTE: 3-rd party developers who use GC collectible pointer items
+            must not activate any PRG code execution inside their mark
+            functions.
+
 2014-03-25 00:38 UTC+0100 Przemyslaw Czerpak (druzus/at/poczta.onet.pl)
   * tests/iotcp.prg
     ! fixed typo in macro name - thanks to Itamar for the info
diff --git a/src/vm/garbage.c b/src/vm/garbage.c
index a53985e5be..132b58ffef 100644
--- a/src/vm/garbage.c
+++ b/src/vm/garbage.c
@@ -598,7 +598,7 @@ void hb_gcCollectAll( HB_BOOL fForce )
    {
       PHB_GARBAGE pAlloc, pDelete;
 
-      if( ! s_pCurrBlock )
+      if( ! s_pCurrBlock || s_bCollecting )
       {
          hb_vmResumeThreads();
          return;
diff --git a/src/vm/hvm.c b/src/vm/hvm.c
index 78246bdeaf..217bb8f269 100644
--- a/src/vm/hvm.c
+++ b/src/vm/hvm.c
@@ -533,7 +533,6 @@ HB_BOOL hb_vmSuspendThreads( HB_BOOL fWait )
       {
          if( s_iRunningCount <= 0 )
          {
-            hb_vmThreadRequest &= ~HB_THREQUEST_STOP;
             ++s_iRunningCount;
             return HB_TRUE;
          }