Support Board
Date/Time: Sat, 29 Aug 2026 23:25:15 +0000
Post From: v2891: All chart updating silently stops mid-session (3 dumps, all threads idle)
| [2026-07-18 11:18:40] |
| User703790 - Posts: 5 |
|
Follow-up with our completed analysis — we finished the 2-night retest on 2927 and did a deep forensic pass on night two (Fri 7/17). Correcting our earlier working theory: this now looks like an application-level stall, not only a network issue. Night one (Thu) had five data interruptions we have not yet re-analyzed under this lens. All times CDT, Fri 7/17: 1. 09:03–09:19 — five cycles of "Denali Data Feed | There has been no activity on the network socket for 60s. Will reconnect.", hopping ds7→ds26-2→ds32-2→ds26→ds28→ds32→ds45 (ports 10048/443), errors mostly 10053, some 10054. Full SC restart at 09:28 cured it. 2. 10:07 — all our ACSIL studies stopped executing, with no reconnect or error entries in the Message Log from 09:40 to 10:15. Full SC restart at 10:19 cured it. 3. 11:05:24 — every study across all three charts in the chartbook stopped within the same ~20-second window (our studies run UpdateAlways=1 and UsesMarketDepthData=1 and write throttled heartbeat logs; all logs ceased between 11:05:05 and 11:05:24 and never resumed). At 11:05:31 the server force-closed the feed socket (10054); reconnect succeeded at 11:05:35 ("Market Depth data restarted", "Clearing market depth", 2.3-minute intraday catch-up completed 11:05:41). From then to the 16:00 close, the receive/write side stayed perfectly healthy — 259,187 records written to the .scid, max inter-record gap 11.4 seconds — while zero study executions occurred for 5 hours. The process stayed alive (scheduled Daily HD Request logged at 16:50, feed-lost notice at 17:01) and the UI kept painting live bid/ask while chart times stayed frozen. We also analyzed our two full-memory dumps locally (captured during episodes 1 and 2 that night): in both, all 24 threads are idle in kernel waits — the worker pool parked in WaitForMultipleObjects at a common return address — no critical section is owned by any thread, no thread is busy in user code, and zero stack frames reference our custom-study DLL (loaded but never on a stack). It looks like the study/chart-update workers are waiting on a wake-up that never arrives, while the network receive path keeps writing the .scid. So: data reception and .scid writing = healthy; study/chart-update execution = permanently stopped; only a full restart recovers. The study stall began seconds BEFORE the server-side disconnect, and episode 2 had no network event at all — the disconnect may be a consequence rather than the cause. Questions: 1. Is this a known issue — chartbook-wide study/chart-update scheduling permanently stalling around a feed disconnect + market-depth clear/restart sequence? We saw five freezes with the same on-screen signature on 2891, so it does not appear new in 2927. 2. We hold the two externally captured full-memory dumps described above. You asked us not to upload externally captured dumps — please either share the exact steps for SC's built-in dump generation so future captures match your requirements, or tell us how you'd like to receive the existing files. Thank you. |