cBot crashed: Error #62082701

Created at 14 Mar 2021, 17:53
How’s your experience with the cTrader Platform?
Your feedback is crucial to cTrader's development. Please take a few seconds to share your opinion and help us improve your trading experience. Thanks!
PR

prosteel1

Joined 04.07.2018

cBot crashed: Error #62082701
14 Mar 2021, 17:53


cBot crashed: Error #62082701

Any idea what this means please? Using Spotware Public Beta.

I'm not convinced its not an error is my code tbh. But all I did was change timeframes and my cbot runs on 8 timeframes. 

 


@prosteel1
Replies

prosteel1
15 Mar 2021, 18:00 ( Updated at: 15 Mar 2021, 18:35 )

This is a strange error. I am narrowing it down. I can run backtests on normal timeframes like from Monthly to Minute. Once I get into Tick frames I get errors like "Failed to load conversion rates" and a similar error to above #62080512 and system out of memory. However I'm not convinced these other errors are memory errors as I have installed the clickalgo memory manager and it didn't prevent the errors which isn't consistant with my previous results of it successfully preventing out of memory errors and task manager shows there was free ram (even though I am running on 4GB on 32bit).

I'll update when I have more info. What does "Failed to load conversion rates" mean?  I found this thread using a search which suggests it couldn't get the exchange rate when the bot started -

, and this crash occured at the start on the bot. The other crash errors occured during the bot running after about 2.5 years. Tick data goes back to 11/11/2012 and these #62082701 & #62080512 crashes occur around 03/02/2015 but seem to change.


@prosteel1

prosteel1
15 Mar 2021, 19:30 ( Updated at: 21 Dec 2023, 09:22 )

I note that the name of the Tick1 frame was recently changed from Tick1 to Tick. When I set my chart frame to Tick1 and try to set the backtesting setting > Data to t1 bars it shows as red meaning an error, but when I set it to "Tick data from Server (accurate)", it does not show as red but is technically the same data (I assume). The same red error occurs in 3.8 currently but I never tested this before the name of Tick1 was changed to Tick. In the past few weeks I have needed to change the name of Tick1 to Tick - so perhaps this change in the naming convention could be resulting in these multiple errors, and a similar issue within the backtesting dialog? 

Since I needed to change my code to reflect the new naming convention, it would seem plausible that an obsolete reference may still exist in the ctrader code resulting in these multitude of errors.

The main thing I have changed in my code recently is I am writing lots of data to a .csv but I have a quite low buffer before writing it (5000) lines and doesn't seem to effect the memory usage.


@prosteel1

PanagiotisCharalampous
16 Mar 2021, 09:44

Hi prosteel1,

Can you provide us with the source code to reproduce this behavior?

Best Regards,

Panagiotis 

Join us on Telegram


@PanagiotisCharalampous

prosteel1
16 Mar 2021, 09:53

RE:

PanagiotisCharalampous said:

Hi prosteel1,

Can you provide us with the source code to reproduce this behavior?

Best Regards,

Panagiotis 

Join us on Telegram

Yes, I think a few more days and I will be able to replicate the behavior in a simple cbot. I'll send it to you in Telegram.


@prosteel1

prosteel1
16 Mar 2021, 10:06

RE:

PanagiotisCharalampous said:

Hi prosteel1,

Can you provide us with the source code to reproduce this behavior?

Best Regards,

Panagiotis 

Join us on Telegram

Do you have any information on the potential cause of the error codes #62082701 & #62080512 ?


@prosteel1

PanagiotisCharalampous
16 Mar 2021, 10:09

Hi prosteel1,

Unfortunately no, we will need some source code to reproduce this.

Best Regards,

Panagiotis 

Join us on Telegram


@PanagiotisCharalampous

prosteel1
17 Mar 2021, 16:04 ( Updated at: 18 Mar 2021, 10:20 )

RE:

This produces the error #62082701 when backtesting from 11/11/2012 to present. using tick data from server (accurate) with visual mode turned off.

The chart timeframe is separate to the timeframe set in the parameters.

Errors occur using the following combinations of chart and parameter timeframes:

Chart, Parameter

Hour, Tick10

Daily, Tick10

Daily, T6

Minute, Tick100

No errors using the following combinations of chart and parameter timeframes:

Chart, Parameter

Hour, Tick100

Daily, Tick50

Daily, Tick60

Daily, Tick100

Tick1000, Tick100

Tick750, Tick100

 

using System;
using System.Linq;
using cAlgo.API;
using cAlgo.API.Indicators;
using cAlgo.API.Internals;
using cAlgo.Indicators;

namespace cAlgo
{
    [Robot(TimeZone = TimeZones.UTC, AccessRights = AccessRights.None)]
    public class error62082701 : Robot
    {

        [Parameter("Timeframe", DefaultValue = "Tick10")]
        public TimeFrame tf { get; set; }

        Bars series;
        int BarLast;

        protected override void OnStart()
        {
            series = MarketData.GetBars(tf);
            BarLast = series.Count - 3;
        }
        protected override void OnStop()
        {
        }

        protected override void OnTick()
        {
            if (series.Count - 3 > BarLast)
            {
                BarLast = series.Count - 3;
            }
        }
    }
}

 


@prosteel1

prosteel1
18 Mar 2021, 02:40 ( Updated at: 18 Mar 2021, 10:19 )

RE:

The #62082701 error occurs when chart time frame is time based and the number of bars on a tick timeframe is just under 1,024,000

With the chart time frame set to daily, Visual mode enabled and changing the parameter timeframe, the last printed value of BarLast before the error was as below:

Parameter, BarLast

Tick1, 1021973

Tick6, 1023755

Tick10, 1023983

Tick20, 1023990

Tick50, 1023996

So looks like there is a limit on the number of Tick bars when the chart time frame is set to a time based timeframe and the cbot references a tick based timeframe. Resulting in an internal overflow of some sort. I haven't yet been able to reproduce the other error: #62080512

 

The #62086147 error occurs when chart time frame is tick based and the number of bars on a tick timeframe is just under 1,024,000

Changing the chart time frame, Visual mode enabled with the parameter timeframe set to Tick1, the last printed value of BarLast before the error was as below:

Chart, Parameter, BarLast

Tick1000, Tick1, 1023407

Tick100, Tick1, 1021973

Tick10, Tick1, 1023873

Tick1, Tick1, 1021973

So looks like there is also a limit on the number of Tick bars when the chart time frame is set to a Tick based timeframe and the cbot references a tick based timeframe. Resulting in an internal overflow of some sort.

using System;
using System.Linq;
using cAlgo.API;
using cAlgo.API.Indicators;
using cAlgo.API.Internals;
using cAlgo.Indicators;

namespace cAlgo
{
    [Robot(TimeZone = TimeZones.UTC, AccessRights = AccessRights.None)]
    public class error62082701 : Robot
    {

        [Parameter("Timeframe", DefaultValue = "Tick10")]
        public TimeFrame tf { get; set; }

        Bars series;
        long BarLast;

        protected override void OnStart()
        {
            series = MarketData.GetBars(tf);
            BarLast = series.Count - 2;
        }
        protected override void OnStop()
        {
        }

        protected override void OnTick()
        {
            if (series.Count - 2 > BarLast)
            {
                BarLast = series.Count - 2;
                if (BarLast > 900000)
                    Print(BarLast);
            }
        }
    }
}

 

Simplifing to a new cbot with no extra code and setting the chart timeframe to Tick 6 or similar and backtesting from 11/11/2012 also produces the error #62082701.

using System;
using System.Linq;
using cAlgo.API;
using cAlgo.API.Indicators;
using cAlgo.API.Internals;
using cAlgo.Indicators;

namespace cAlgo.Robots
{
    [Robot(TimeZone = TimeZones.UTC, AccessRights = AccessRights.None)]
    public class NewcBot : Robot
    {
        [Parameter(DefaultValue = 0.0)]
        public double Parameter { get; set; }

        protected override void OnStart()
        {
            // Put your initialization logic here
        }

        protected override void OnTick()
        {
            // Put your core logic here
        }

        protected override void OnStop()
        {
            // Put your deinitialization logic here
        }
    }
}

 


@prosteel1

PanagiotisCharalampous
18 Mar 2021, 08:44

Hi prosteel1,

Unfortunately source code did not help reproducing this issue. Can you please send us some troubleshooting information the next time this happens? To do so, press Ctrl+Alt+Shift+T, paste a link to this discussion in the text box that will appear and press submit.

Best Regards,

Panagiotis 

Join us on Telegram


@PanagiotisCharalampous

prosteel1
18 Mar 2021, 09:37 ( Updated at: 21 Dec 2023, 09:22 )

RE:

PanagiotisCharalampous said:

Hi prosteel1,

Unfortunately source code did not help reproducing this issue. Can you please send us some troubleshooting information the next time this happens? To do so, press Ctrl+Alt+Shift+T, paste a link to this discussion in the text box that will appear and press submit.

Best Regards,

Panagiotis 

Join us on Telegram

It's submitting at the moment. I used the error62032701 cbot above. The default cbot didn't trigger it, so I might have been wrong on the default cbot.

Here is a screenshot to show the settings I used.


@prosteel1

prosteel1
18 Mar 2021, 12:15 ( Updated at: 18 Mar 2021, 14:23 )

RE:

PanagiotisCharalampous said:

Hi prosteel1,

Unfortunately source code did not help reproducing this issue. Can you please send us some troubleshooting information the next time this happens? To do so, press Ctrl+Alt+Shift+T, paste a link to this discussion in the text box that will appear and press submit.

Best Regards,

Panagiotis 

Join us on Telegram

I'm not sure how the troubleshooting works. I ran it after the first error, then ran the bot again and just closed it, thinking it might record what happens while it runs?

I have had 100% success triggering this error with the below code and the mentioned settings earlier and shown in the screenshot for clarity. There is definetely a limit in backtesting to not be able to reference more than 1,024,000 bars on any timeframe. I have not seen this in realtime.Mode where I used Load more history to load over 15,000,000 Tick6 bars.

Please try this code with the settings I showed in the screenshot as it has never failed over about 50 tests. It does take a long tome to load the tick data for the whole period. If you didn't want to wait so long 1 or 2 years should load over the 1,024,000 bars required to throw the error.

The main issue is that I can't backtest below Tick60 over this long time period without this error being thrown, because anything below Tick60 (on AUD/USD) has more than 1,024,000 bars (EUR/USD will likely error at higher tick time frames). It's only after spending such a large amount of time testing this error that I now know the current limitations. 

 

using System;
using System.Linq;
using cAlgo.API;
using cAlgo.API.Indicators;
using cAlgo.API.Internals;
using cAlgo.Indicators;

namespace cAlgo
{
    [Robot(TimeZone = TimeZones.UTC, AccessRights = AccessRights.None)]
    public class error62082701 : Robot
    {

        [Parameter("Timeframe", DefaultValue = "Tick6")]
        public TimeFrame tf { get; set; }

        Bars series;
        long BarLast;

        protected override void OnStart()
        {
            series = MarketData.GetBars(tf);
            BarLast = series.Count - 2;
        }
        protected override void OnStop()
        {
        }

        protected override void OnTick()
        {
            if (series.Count - 2 > BarLast)
            {
                BarLast = series.Count - 2;
                if (BarLast > 900000)
                    Print(BarLast);
            }
        }
    }
}

 


@prosteel1

prosteel1
19 Mar 2021, 09:20

Further testing suggests this error occurs on 32bit Windows 10 but perhaps not on 64bit Windows server 2019. Strange...


@prosteel1

prosteel1
22 Mar 2021, 10:08 ( Updated at: 21 Dec 2023, 09:22 )

RE:

prosteel1 said:

Further testing suggests this error occurs on 32bit Windows 10 but perhaps not on 64bit Windows server 2019. Strange...

While I prepare to upgrade my 32bit system to 64bit, I've been able to replicate the error on a vps running Server 2019 64bit by running the bot on Tick1.

USDJPY crashes on bar 65,532,919 and AUDUSD crashes on 65,534,350 so the same behavior exists where there is a limit to the number of bars able to be accessed.

 

using System;
using System.Linq;
using cAlgo.API;
using cAlgo.API.Indicators;
using cAlgo.API.Internals;
using cAlgo.Indicators;

namespace cAlgo
{
    [Robot(TimeZone = TimeZones.UTC, AccessRights = AccessRights.None)]
    public class error : Robot
    {

        [Parameter("Timeframe", DefaultValue = "Tick10")]
        public TimeFrame tf { get; set; }

        Bars series;
        long BarLast;

        protected override void OnStart()
        {
            series = MarketData.GetBars(tf);
            BarLast = series.Count - 2;
        }
        protected override void OnStop()
        {
        }

        protected override void OnTick()
        {
            if (series.Count - 2 > BarLast)
            {
                BarLast = series.Count - 2;
                if (BarLast > 65500000)
                    Print(BarLast);
            }
        }
    }
}

 


@prosteel1

prosteel1
22 Mar 2021, 16:09 ( Updated at: 22 Mar 2021, 16:13 )

I am currently testing a second identical windows 10 32bit desktop computer hardware wise. This will eliminate software effects. After that I will reinstall windows as 64bit and test again. This should prove a great test as to whether a 64bit OS has the proposed effect on the max number of bars accessible by a bot during backtesting. I should have results in about 30 hours.


@prosteel1

prosteel1
23 Mar 2021, 11:25

RE:

Upgrading to Windows 10 64bit seems to have resolved the errors. The above code runs fine down to Tick2, and gets most of the way on Tick1 before cTrader becomes very slow and unresponsive, however on the last test after all windows updates were installed it did complete! Yay!

I never expected cTrader to run differently on Windows 10 32bit, but Windows 64bit uses the same license so just needed a clean install. 

 


@prosteel1

prosteel1
25 Mar 2021, 12:19 ( Updated at: 25 Mar 2021, 12:57 )

RE: RE:

prosteel1 said:

Upgrading to Windows 10 64bit seems to have resolved the errors. The above code runs fine down to Tick2, and gets most of the way on Tick1 before cTrader becomes very slow and unresponsive, however on the last test after all windows updates were installed it did complete! Yay!

I never expected cTrader to run differently on Windows 10 32bit, but Windows 64bit uses the same license so just needed a clean install. 

 

The slow and unresponsive part may have been due to a lack of ram. I doubled the ram due to excessive disk usage from page file writes and almost halved the time it took to do a full backtest. While this was completed on my full cbot running on 8 timeframes in the one cbot down to Tick6, this same excessive page file usage may have been the cause of slowness during the above test. While I still did see lots of pagefile writes, I did see an improvement which when added to the improvement from moving to 64bit windows 10 makes a good case for using 64bit windows 10 with lots of ram.

The difference I have seen running cTrader on 64bit Windows 10 compared to 32bit Windows 10 when doing long term backtesting is like night and day.

 

Conclusion: The errors I encountered were due to the limitations of 32bit Windows: Don't use 32bit Windows 10 for cTrader if your doing long term Backtesting and perhaps Optimization where the number of bars could exceed 1 million. Use 64bit Windows 10.  I note that https://www.cygwin.com/ does not recommend 32bit Windows and after spending the last 2 weeks figuring out the cause of #62080512 #62082701 & #62086147, this is probably something that should be considered - "Address space is a very limiting factor for Cygwin. These days, a full 32 bit Cygwin distro is not feasible anymore, and will in all likelihood fail in random places due to an issue with the fork(2) system call. Therefore we recommend using 32 bit Cygwin only in limited scenarios, with only a minimum of necessary packages installed, and only if there's no way to run 64 bit Cygwin instead."


@prosteel1