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().
New comment