主题：3月18日早盘出现两次错误数据

对应代码为：

DEBUGFILE(FILEPATH,'DY28:'&numtostr(dynainfo(28),1)&' DY34:'&numtostr(dynainfo(34),1)&' minL28:'&numtostr(min(Low,dynainfo(28)),1)&' maxH34:'&numtostr(max(High,dynainfo(34)),1),0);
DEBUGFILE(FILEPATH,'HV12:'&numtostr(HV12,2)&' LV12:'&numtostr(LV12,2)&' THV2:'&numtostr(THV2,2)&' TLV2:'&numtostr(TLV2,2),0);
DEBUGFILE(FILEPATH,'lTLV21:'&numtostr(lTLV21,0)&' hTHV21:'&numtostr(hTHV21,0)&' ClTLV21:'&numtostr(ClTLV21,0)&' ChTHV21:'&numtostr(ChTHV21,0),0);

我来分析一下，可能有两个原因

 一，金字塔软件在多线程并发的情况下存在漏洞，也就是说有一些地方没有做到“线程安全性”.

二、楼主的公式容易诱发上述漏洞

 

 

 

不一定准确，仅供参考.希望金字塔越来越好

 

 

DEBUGFILE(FILEPATH,'O:'& numtostr(o,1)&' H:'&numtostr(h,1)&' L:'&numtostr(L,1)&' C:'&numtostr(C,1),0);

这样在序列模式下使用是有些问题的，因为涉及到了序列变化的字符串转换操作，计算机在处理字符串时是效率很低的，你这样搞会把大量的CPU时间用在了一些无用的操作上。

VARIABLE:OO=0,HH=0,LL=0,CC=0;

OO:=O;

HH:=H;

LL:=L;

CC:=C;

DEBUGFILE(FILEPATH,'O:'& numtostr(oo,1)&' H:'&numtostr(hh,1)&' L:'&numtostr(LL,1)&' C:'&numtostr(CC,1),0);

这样在序列模式下强制序列变量为单值全局变量就可以了

 

如果在逐K线模式下运行，请注意前面加 ISLASTBAR 条件判断

嗯，这方面我会改进的。如果用标准的debugfile格式，即，DEBUGFILE(FILEPATH,'O:%.1F',O); 还会有上述问题吗？

 

DEBUGFILE是最后一个周期才执行的函数，周期模式下需要加islastbar判断吗？

这周恢复到2.43做交易了，以后再也不敢轻易升级了。

 

对于这个问题的检查，有什么进展吗？

降低软件的版本并不能解决问题，因为升级版根本就没对后台做任何变动。

你的问题，不排除是因为你盘中使用高频刷新和公式的运行效率不高导致操作系统长时间高负荷工作最后导致的瞬时内存数据紊乱。

建议楼主使用走完K线模式或者放弃高频刷新改为5秒以上的固定轮询模式后再看。

首先，出现问题时，操作系统并没有长时间超负荷工作，问题出在早盘的9:26分，当时CPU占用没有持续超过20%，金字塔也没有发出这方面的警告。

其次，即使CPU长时间高负荷工作，也不应该出现什么瞬间内存紊乱，如果出现一定是程序的BUG。

 

希望你们能严肃地查一下问题的原因。

还有类似的错误数据，以前没有用高频的时候，也出现过很多次，对此我以前就发过至少两个帖子，所以也不太可能是高频的问题。

金子塔要是能把这类问题解决了（参看我过去发的关于异常数据的帖子，有无穷大的，也有0的），金子塔就很完善了。真心希望金字塔越过这道门槛。

 

试想一下，将来客户真的多起来了，这种问题会给用户造成多大损失啊！现在投入多少精力，解决这个问题都不为过。这类问题，虽然不长出现，但一旦出现，后果就可能很严重，尤其可能引发很多诉讼。

 

比起你们现在所做的修修补补，加点不疼不痒的新功能，孰轻孰重，应该有个清楚的判断吧。