Corrupt variable or something lazarus / 12-Debugger ---------------------------------------------------------------------- Ruptor · 2013-06-04 12:10 I have a weird problem with an integer variable that is not being set by my code and yet it keeps being loaded with a large number in between where my code set it to zero and where I test it. I tried breaking on the write condition and the assembler window opens with ...... on each line then about 30 seconds later the code appears but it is all meaningless to me I don't have a clue where the code is or how to find out. Any pointers would be appreciated. I have all the debug switches on for overflowing arrays etc but nothing is being triggered and yet the debugger can break on the write to the location. ---------------------------------------------------------------------- howardpc · 2013-06-04 12:36 Can you give us a cut down project that nevertheless shows the problem? Any third party libraries used? ---------------------------------------------------------------------- Ruptor · 2013-06-04 12:53 I am trying to catch the corruption manually at the moment to try and find the block that does the corruption. This might yield the answer too but a small project might then be possible. ---------------------------------------------------------------------- Ruptor · 2013-06-04 22:03 I have fixed the problem but I can't understand what was going on. I lost a line of code that initialised the problem variable but the compiler didn't pick up that the variable was not being set before use. The consequences of not setting the variable seemed to be that when my code set it to zero as the result of a function it was not permanently set because the uninitialised value came back a bit further down the code. Don't ask me I don't have a clue what was going on but it was a result of using an uninitialised variable that the compiler couldn't recognise as being uninitialised. Should it be possible to have a variable that is initialised that the compiler can't see? ---------------------------------------------------------------------- Ruptor · 2013-06-05 11:37 After thinking about it I conclude this is a compiler bug possibly related to stacking because even if I haven't initialised the variable my code would set it to zero as I witnessed and yet further down the code the variable was back to the uninitialised value. The results can be seen graphically in the picture where the red line is stepped up for no reason. The line should only step when the green line goes above the blue one but it hasn't. The debug values showed me that the uninitialised value was causing a trade that made the red line get set to the take value then when the code closed the trade another trade was opened because the variable was set again even though my trade decision code was making the variable zero. The bottom line is that the decision function set the variable to zero but it was changed before getting to the code that executed the trade when nothing else used the variable in between. All this switching was eradicated by initialising the variable once at the start. ---------------------------------------------------------------------- BigChimp · 2013-06-05 11:41 If it's a bug in FPC 2.6.2 or FPC trunk the sensible thing would be to report it on the bug tracker, preferably together with a compilable sample FPC program that demonstrates the problem... ---------------------------------------------------------------------- User137 · 2013-06-05 11:55 You haven't shown any code yet, so we can't make any confirmations if it's bug in your program (the most likely option), debugger or in compiler. ---------------------------------------------------------------------- Ruptor · 2013-06-05 13:04 Common sense says the bug is not in my code because as you can see from the picture below the red line follows the price and no trades are opened by just initialising the variable before executing the price data loop that plots the graph. My code is still setting the trade required variable to zero just like before but the corruption outside of my code is not happening. I shall try and make a chopped down code to demonstrate it and prove it isn't my fault but the module is 1600 lines long. All previous attempts to show other bugs I have found have usually disappeared when significant changes were made to reduce the code size. I would hope to pin it down better before reporting it as a bug but at this stage it looks like a bug to me. I downloaded the latest snapshot of Lazarus yesterday but it has FPC 2.6.1 so do I have to go and get FPC 2.6.2 myself? It might be worth trying it before proceeding. ---------------------------------------------------------------------- marcov · 2013-06-05 16:50 And or compile with -CRriot -gttt in the IDE to see if that breaks before the problem. From experience, this sort of corruption is programmer error in >95% of the cases. ---------------------------------------------------------------------- Ruptor · 2013-06-06 13:00 If you mean project options> compiler options> code generation>    I have them all ticked. Since most of you are saying it is my code and setting one variable to zero makes the problem go away I am not going to waste any more time on it. However sniffing out bugs as an embedded software engineer for over 30 years is my forte'. If it is my code it will show itself in other ways eventually so I will have to wait and see.