Hello Jonas, Wednesday, December 28, 2011, 2:43:16 PM, you wrote:
>> To me it looks like the code is trying to free some strings or >> interfaces but at a point where the manager of automated types has >> been "disabled" so the declaration of a new ansistring "reconnects" >> it. Maybe it is a crazy idea but is the only one that I have now. JM> The most likely problem is memory corruption by your program. JM> Compiling the program with range checking (-Cr) and dynamic class JM> type checking (-CR) can help with finding the cause. You can try JM> using heaptrc or Dr Memory (http://dynamorio.org/drmemory.html -- JM> in case you use this one, adding the cmem unit to your program may JM> give more accurate diagnostics). I had done all the tests and in fact many more, and start to manually bisect fpc to find the revision that breaks my code as 2.4.2, 2.4.4 and 2.6.0rc1 work fine. After 2 days and around 40 fpc and LCL clean compiles :) I had found that the revision 19668 breaks the code. I was unable to synthesize a test case that shows the problem, so only my code is raising the problem constantly after that revision. When exception is raised ebp is equal to zero and as r19668 is related to exceptions handling it makes me think again in wrongly handled automated types in some situations, in my case I suspect in interfaces. To compile 19667 and 19668 I had to manually apply revisions 19699 and 19670 which only affects fpdoc compilation. How can I help more to catch the problem ? -- Best regards, José _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel