[문의] 나스닥/SP500/골드 분·틱 6개 스크립트 동시 실행 시 약 30분 경과 지점 다운 - 크래시 덤프 분석 결과 첨부

■ 증상

ReqChartEx 요청 → 응답 → RemoveObject 지연삭제 → 다음 타임프레임 요청, 이 루프를

분봉(1~110분) / 틱봉(30~1000틱) 전체 타임프레임에 대해 페이싱 0~1000ms로 끝없이 순환.

나스닥(NQU26), SP500(ESU26), Gold(GCZ26) 종목마다 분/틱 파일로 나눠 총 6개 파일을 동시

실행하면 약 30분 경과 시점에 프로그램이 다운됩니다.

■ 크래시 덤프(.dmp) 분석 결과 (직접 파싱해서 확인한 사실)

- 예외 코드: 0xC0000005 (ACCESS_VIOLATION)

- 접근 종류: 읽기(read) 시도, 대상 주소 = 0x0 (널 포인터)

- 크래시 발생 위치: SystemTrading.dll 모듈 내부, 오프셋 0x3D65D

- 크래시 순간 레지스터: EAX=0, EBX=0, ECX=0, EDX=0

(ECX는 x86 MSVC에서 보통 this 포인터를 담는 레지스터라, 이미 유효하지 않은 객체에

대해 멤버함수를 호출하려다 발생한 크래시로 보입니다.)

- 크래시 지점 직전 스택(리턴주소 후보): YesChartLibrary.dll, YesSystemChart.dll

(둘 다 차트 관련 DLL로, 차트 객체 처리 도중 SystemTrading.dll로 진입해 크래시)

■ 저희 쪽에서 자체 점검한 내용

- ReqChartEx 응답을 받은 뒤 RemoveObject로 삭제하는 구조에서, 삭제 타이머와 다음 요청

타이머가 동시에 도는 구간이 있어 이론상 삭제 전에 객체가 재할당될 수 있는 구조적

문제를 발견하여 큐(대기열) 방식으로 수정, 삭제 성공/실패 여부와 누적 생성-삭제

카운트를 로그로 추적하도록 진단 스크립트를 개선해 재현 테스트 중입니다.

- 다운 직전 로그에서 특정 응답이 7초 이상 지연되는 현상(SLOW_RESPONSE)도 함께

확인되어, 응답 지연과 크래시 사이의 연관 가능성도 의심하고 있습니다.

■ 문의드리고 싶은 부분

1. SystemTrading.dll+0x3D65D 부근에서 차트 객체(ChartEx)를 참조하는 코드 중,

객체가 삭제되었거나 유효하지 않을 때 널 체크 없이 접근하는 구간이 있는지

내부적으로 확인 가능하신지요.

2. 다중 종목(6개 파일)에서 ReqChartEx를 짧은 주기로 반복 호출할 때, 엔진 내부에

차트 객체 핸들 개수 제한이나 동시 요청 제한이 있는지, 있다면 권장 상한값을

안내해주실 수 있는지요.

3. RemoveObject 호출 시 이벤트 핸들러(OnRcvChartEx) 내부가 아닌 별도 타이머에서

지연 삭제하는 저희 방식 자체가 엔진 설계상 안전한지, 혹은 권장되는 다른

삭제 시점/방식이 있는지 안내 부탁드립니다.

첨부: eBestYesTraderRun_26_08_10_20_30_11.dmp