前几日，调试一BUG，过程先不说，最后调试到MM，即Debug dcu，然后进入到GetMem.inc中的Get/FreeMem函数处后，出现AV。

然后一通找。。。郁闷了N天，后来发现将MM切换到QMM后，一切正常，然后再切回原MM，BUG出现。。。

按经验，此类问题一般由于线程未有锁保护引起，但就是没找到原因所在。

好吧，也不怎么滴，突然想起IsMultiThread变量，想起MM的Get/Free/Realloc都需要这个玩意进行保护，而VCL中，只有一个地方对这变量进行操作: Classes.TThread.Create->System.BeginThread

然后才想起自己未使用TThread，使用API.CreateThread进行创建线程，而它未对IsMultiThread进行置true操作，问题找到，BUG解除。

遂，本文记录此问题。

BUG形成：

1：程序从未使用TThread或BeginThread进行创建线程，这样，它就不会对IsMultiThread进行操作。

　　注意：TThread和BeginThread对IsMultiThread置True后，没有其它VCL代码进行置false操作(不建议自己置false)

2：自行使用API.Windows.CreateThread创建线程，且未对IsMultiThread置true

3：在创建的线程中，进行Get/Free/ReallocMem，并与其它线程（如主线程）进行交互该内存块

BUG展现：

1：该BUG将会引起MM数据结构错误，问题就大了去。

出现AV时，watch查看的数据是错误的，且随机的给你不一样的数据

call stack也傻了，定位到无边际的代码。。。

总之，一切都傻掉了，不可信了。

BUG避免：

1：慎用API.Windows.CreateThread，如果要对它操作，请记得IsMultiThread := True;

如果不记得，请参照代码: System.BeginThread

或者直接使用System.BeginThread进行创建线程。

2：使用QMM，QMM是自动维护IsMultiThread，有线程数N(N>1)时, IsMultiThread=true, N=1时, IsMultiThread = false;

这点，其它MM，俺所查看的，都未做处理。（偶在打广告哩）

个人建议是：开发环境必备两套以上MM，以作备用，遇到一些莫名问题，切换一下，用以确认是否MM问题引起。

注：

　　MM=Memory Manager， D2005版本开始集成FastMM。

　　不过，从D7（D5没注意看，应该也是）的GetMem.Inc，一直到FastMM4.991都依赖于IsMultiThread标志进行线程保护，未进行自维护该标志。

所以，当出现此BUG条件形成时，就会出现：我知道因为多线程未保护引起数据错乱而引起的BUG，但就是找不着在哪里触发的，怎么去解决。这才是最坑爹的。 :)

完。

2014.10.15 by qsl