MT5 build 6182: chart API error 4102 after notification activity stops

New comment
Please investigate an intermittent chart-query failure in an isolated diagnostic terminal on Windows 11 x64 (build 26200, Intel Core Ultra 5 225U).

Concurrent EA/indicator read tests on an H4 chart sometimes return error 4102 after approximately 3 seconds. In four recorded failing executions, the last successful read was followed by a sampled state with no outstanding captured target notification and an internal counter remaining 2. The next paired reads both returned 4102. Target notification captures reported zero lost events; sent/received notifications were matched across reused message addresses. An additional error-free case did not exhibit this condition. These are retrospective observations, not a universal failure rule.

Observed failing call durations: 3015 ms, 3032 ms, 3156 ms, and 3078/3062 ms. We have preserved timestamped API results, notification ledgers and hashes locally. Some separate instruction-trace captures were incomplete; we do not treat them as complete proof.

Expected behavior: valid chart queries complete, or failures leave the terminal able to process subsequent requests. We would appreciate clarification of the supported concurrency contract and a supported diagnostic method to identify why notification processing ceases in these cases.

We have a candidate ordering hypothesis involving notification completion and a later counter increment, but have not proven the executing writer or its runtime target identity. Please advise whether this is a known issue and whether a diagnostic build can record queue identity, notification send, counter update, receiver reset and timeout using a common monotonic clock.

A debugger-based attempt could not reach instruction measurement: an attachment-only control exited with 0xDEADC0DE about 7.7 ms after attachment, before its initial breakpoint event. No hardware breakpoints or register changes had been installed. A matching no-attachment control remained running for 8 seconds. We are not requesting a bypass; please advise on supported diagnostics.

Separately, a historical indicator comparison had 415 missing objects, but its immediate per-call error codes were not recorded. We cannot attribute those 415 to this issue and do not claim they are resolved.

No trading is enabled. This initial report omits account details, local paths and proprietary indicator source. A minimal reproduction package can be provided through an agreed channel. Current reproduction is intermittent; a deterministic reproduction of the original historical 415 is not claimed.

Nobody will investigate such "report".

No code. No log. Nothing. I didn't even read all this text.

paburon:
Please advise whether this is a known issue and whether a diagnostic build can record queue identity, notification send, counter update, receiver reset and timeout using a common monotonic clock.

Forum on trading, automated trading systems and testing trading strategies

ChartSymbol() function return error 4102 in build 4231

AIRAT SAFIN, 2024.03.11 11:42

Inserting delay <for example 1000-2000 milliseconds> inside this hard loop has a chance that then everything will be fine

 

Although the above pocketed post relates to an older MT5 Build, the 3 second _StopFlag remains the same today.
Thank you. I have prepared a small synthetic code package and the complete two-reader logs from one recorded failure.

It creates one fixed HLINE and performs ObjectGetInteger(0, "RR_FIXED", OBJPROP_TYPE) from an EA and an indicator callback. The object is not modified during the measured reads. Both readers returned error4102 at round745 after3047ms; the attached logs contain all745 calls from each reader. The sources/templates are unchanged from that archived test. The failure was intermittent under CPU load, and a later repeat did not reproduce it.

The README includes installation, bounds, log format and a serialized scheduling control. The busy-poll Global Variable barrier is deliberate diagnostic scheduling; please advise if this is outside the supported threading contract. This package contains no proprietary indicators, account information, debugger, or memory-patching code. No claim is made that it explains the historical415.
paburon #:
Thank you. I have prepared a small synthetic code package and the complete two-reader logs from one recorded failure.

It creates one fixed HLINE and performs ObjectGetInteger(0, "RR_FIXED", OBJPROP_TYPE) from an EA and an indicator callback. The object is not modified during the measured reads. Both readers returned error4102 at round745 after3047ms; the attached logs contain all745 calls from each reader. The sources/templates are unchanged from that archived test. The failure was intermittent under CPU load, and a later repeat did not reproduce it.

The README includes installation, bounds, log format and a serialized scheduling control. The busy-poll Global Variable barrier is deliberate diagnostic scheduling; please advise if this is outside the supported threading contract. This package contains no proprietary indicators, account information, debugger, or memory-patching code. No claim is made that it explains the historical415.

EventSetMillisecondTimer(200) in RaceReadController.mq5 is likely insufficient.

Also:

Closing a file when you're finished working with it is an important rule to follow. This is due not only to the caching of the information being written, which may remain in RAM for some time and not saved to disk (as already mentioned above), if the file is not closed. In addition, an open file consumes some internal resource of the operating system, and we are not talking about disk space. The number of simultaneously open files is limited (maybe several hundred or thousands depending on Windows settings). If many programs keep a large number of files open, this limit may be reached and attempts to open new files will fail. (https://www.mql5.com/en/book/common/files/files_open_close).
paburon #:
Thank you. I have prepared a small synthetic code package and the complete two-reader logs from one recorded failure.

It creates one fixed HLINE and performs ObjectGetInteger(0, "RR_FIXED", OBJPROP_TYPE) from an EA and an indicator callback. The object is not modified during the measured reads. Both readers returned error4102 at round745 after3047ms; the attached logs contain all745 calls from each reader. The sources/templates are unchanged from that archived test. The failure was intermittent under CPU load, and a later repeat did not reproduce it.

The README includes installation, bounds, log format and a serialized scheduling control. The busy-poll Global Variable barrier is deliberate diagnostic scheduling; please advise if this is outside the supported threading contract. This package contains no proprietary indicators, account information, debugger, or memory-patching code. No claim is made that it explains the historical415.

I checked all this stuff.

As I understand the code is similar to your real code but with some features removed ? I want to know if the real is doing similar things, as otherwise it's useless. Your provided capture_X.tsv looks different from what your code produces. Did you really get error 4102 with the code provided ?

round    begin_relative_ms    end_relative_ms    value    error
1    0    0    1    0
2    0    0    1    0
3    0    0    1    0
4    0    0    1    0
5    0    0    1    0

Using GetTickCount64() how could you get 0 ?

I don't have the error 4102. So the problem is not reproducible.

When you got error 4102 with a ~3 seconds delay to answer, that means the queue processing the chart is full. Why ? It depends of the real code used, I can't check further as I can't reproduce the problem.

"Your" way to use a 3 seconds loop to check GlobalVariable is NOT good. I can't say for sure this is the problem but it's certainly a problem.

paburon #:
The failure was intermittent under CPU load...
Alain Verleyen #:
When you got error 4102 with a ~3 seconds delay to answer, that means the queue processing the chart is full.
Intermittently full, based on what's been posted─hence my references to slower reading and FileClose().
Thank you for checking. Yes, the supplied diagnostic sources produced the recorded error 4102. The public TSV files were postprocessed: I subtracted the same first-read GetTickCount64 value from both timestamp columns in both streams and added the column header. Thus zero means relative time zero, not a raw GetTickCount64 return of zero. This should have been clearer in my comment. Error codes, values, round numbers and durations were preserved.

This is a synthetic concurrency diagnostic with a deliberate busy-poll barrier, not a reduced production EA. I agree that it does not establish the cause of the separate historical 415-object discrepancy or demonstrate a production-safe scheduling pattern. The controller log function closes its file on each call; each reader accumulates rows in memory, then flushes and closes its log after the read loop.

I also added IsStopped() immediately before and after ObjectGetInteger, preserving the existing time bounds. In two further executions both readers returned 4102: round 8363 after 3031 ms, and round 1799 after 3000 ms. IsStopped was false before and after all four failing calls. A preceding healthy case ran for 30000 ms with 11757 calls per reader. These observations do not support forced shutdown as the explanation for those failures; they do not prove a terminal defect or the historical 415 cause.

I will now compare with callbacks that return after each read, without the busy-poll barrier. A clean result from slower/different scheduling alone will not be treated as proof of the underlying cause.
I have now recorded error 4102 without the busy-poll barrier. The attached v2 uses paired custom-event callbacks: each reader does one ObjectGetInteger and returns. Once both acknowledge that round, the second finisher queues the next event using GlobalVariableSetOnCondition. No waiting loop or Sleep is used.

In the attached M15 run, both readers completed 956 calls. The EA read succeeded; the indicator read returned 4102 after 3141 ms. IsStopped was false before and after the calls. The source/template files are unchanged from that execution. Both TSV files are raw output bytes with only their filenames changed: timestamps are unmodified GetTickCount64 values, and there is no added header. The README defines the seven columns and installation steps.

This remains an intermittent synthetic failure, not proof of the historical 415 cause or of an internal terminal defect. A simpler independent-timer control and an unpaired event-pump control completed without error, but their scheduling differs. Could you check whether the attached paired-callback pattern is supported and advise what additional supported diagnostic would distinguish a chart-queue timeout from another synchronization failure?
Further controls using the returning callbacks from v2 are attached, with unchanged executed sources/templates and raw TSV logs (unmodified timestamps; no added header). The README defines all columns and test bounds.

Using a positive ChartID captured at initialization instead of chart ID 0 still produced 4102: H4 indicator call 2758 took 3156 ms, while the EA call succeeded. Both queried the controller-owned chart ID; IsStopped was false before and after. Thus the zero-ID alias is not necessary for this observed failure.

With separate returning events for the EA and indicator reads, four timeframes completed 15064 reads without errors. Reverting to paired reads, with the same initialization diagnostics, reproduced 4102 on M15 indicator call 1795 after 3031 ms. A paired-read control with an intermediate returning event completed four timeframes / 16544 reads without error at about 66-73 calls/sec per reader. This scheduling also changes cadence, so the clean samples do not establish a concurrency fix. An earlier serial attempt timed out without reader logs and remains incomplete.

These synthetic tests do not resolve the historical 415 discrepancy or prove an internal terminal defect. Could you advise on a supported diagnostic for identifying what prevents the timed-out chart request from completing? No proprietary indicator code, account data or private paths are included.
paburon #:
I have now recorded error 4102 without the busy-poll barrier. The attached v2 uses paired custom-event callbacks: each reader does one ObjectGetInteger and returns. Once both acknowledge that round, the second finisher queues the next event using GlobalVariableSetOnCondition. No waiting loop or Sleep is used.

In the attached M15 run, both readers completed 956 calls. The EA read succeeded; the indicator read returned 4102 after 3141 ms. IsStopped was false before and after the calls. The source/template files are unchanged from that execution. Both TSV files are raw output bytes with only their filenames changed: timestamps are unmodified GetTickCount64 values, and there is no added header. The README defines the seven columns and installation steps.

This remains an intermittent synthetic failure, not proof of the historical 415 cause or of an internal terminal defect. A simpler independent-timer control and an unpaired event-pump control completed without error, but their scheduling differs. Could you check whether the attached paired-callback pattern is supported and advise what additional supported diagnostic would distinguish a chart-queue timeout from another synchronization failure?

In your custom indicator file, you have:

int OnCalculate(const int total,const int prev,const datetime &time[],const double &open[],const double &high[],const double &low[],const double &close[],const long &tv[],const long &vol[],const int &spread[]){return total;}

(emphasis added).

I don't see total defined anywhere else in the indicator code.

There are 2 valid forms of OnCalculate(), both of which use rates_total: https://www.mql5.com/en/docs/event_handlers/oncalculate

On a more general note, I would probably embed all of the MQL5-side code into an MQL5 service which has MT5 terminal-wide access─instead of separate mq5 files. In this way, "source" chart(s) for an indicator nor an EA would be required.

12
New comment