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; }