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

后台序列模式。

还有一点，也许有用。我这个系统运行好几个礼拜了，都没有出问题，18日开盘前做了一次自动升级，开盘后就出了上述问题，有点怀疑这个问题可能是由这次升级引起的。

再加一点，前台的行情数据没有观察到任何异常，所以这个错误数据有可能来自于订阅的数据。下面是在错误数据之后记录的数据，可以看出，那个异常的L值（3220.4）并没有反映在后续的数据里，即L值仍然是正常的3252.8。这点或许对查找问题有帮助。

 

2011-03-18 09:26:42.208    =======
2011-03-18 09:26:42.208    Time:92700.000 cTime:92642.000
2011-03-18 09:26:42.224    O:3255.6 H:3258.0 L:3252.8 C:3252.8
2011-03-18 09:26:42.224    DY28:3252.4 DY34:3252.8 minL28:3252.4 maxH34:3258.0
2011-03-18 09:26:42.239    HV12:3258.40 LV12:3196.80 THV2:3223.08 TLV2:3232.12
2011-03-18 09:26:42.239    lTLV21:0 hTHV21:1 ClTLV21:0 ChTHV21:9
2011-03-18 09:26:42.255    lTLVD:0 hTHVD:1
2011-03-18 09:26:42.255    nSE1:13 nBE1:2
2011-03-18 09:26:42.271    SO:0 BO:0
2011-03-18 09:26:42.271    SLH:3241.1 SLL:3203.2 HR:47.2 LR:-19.5 B_SL:1 S_SL:0 AVGB:3212.2 AVGS:3232.1
2011-03-18 09:26:42.271    TBHEX:0 TSHEX:2 TV4B:0
2011-03-18 09:26:42.271    MATR:9.9
2011-03-18 09:26:42.271    N1:62 N2:5 SL:9 OA:2 AP:3 HT:68
2011-03-18 09:26:42.271    X:2.66 EPH:3259.4 EPL:3251.6
2011-03-18 09:26:42.271    GSL:0 GBP:101 BP:104
2011-03-18 09:26:42.583    =======

对应代码为：

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格式，即，DEBUGFILE(FILEPATH,'O:%.1F',O); 还会有上述问题吗？

 

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

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

 

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

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

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

 

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

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

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

 

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

 

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