usdrecord keeps waiting after its Arras render worker exits
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 4/5
- Thời gian dự kiến
- 3-5 ngày
- Mức phù hợp với người mới
- 53/100
Hướng nghiên cứu
Start by reading ArrasRenderer::statusHandler and the frame completion logic around isFrameComplete() in hdMoonray, then trace how usdrecord waits for convergence after the Arras session stops. The control probe and logs linked in the issue reproduce the hang by killing execComp during rendering. Done means usdrecord reports the failed render and stops waiting after Arras reports a stopped session, allowing a batch to continue.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
During a benchmark run with the MoonRay Hydra delegate in OpenMoonRay v2026.29.1 and OpenUSD 24.08 on Rocky Linux 8.10.
The Moana Island worker exited with signal 9. Arras reported the failure, but usdrecord stayed alive without its render worker for about 2 hours 46 minutes, until the benchmark's own deadline stopped it. No Moana image was produced. I don't have evidence establishing why the worker died in this run.
I reproduced this behavior separately on OpenUSD 23.08, using McUsd under Xvfb/Mesa and deliberately killing the Arras worker (execComp). No OOM or GPU was needed:
Error: Arras session stopped, compExited: mcrt exited due to signal 9
RESULT: CLIENT STILL ALIVE 150s after its render worker died
Control probe and logs. The probe script starts usdrecord on McUsd, waits for the worker, kills it while the frame is still rendering, and observes the client.
In hdMoonray, ArrasRenderer::statusHandler logs stopped/stopping and sets the connection state to disconnected, but leaves the unfinished frame waiting for completion. Without a final image, isFrameComplete() remains false and usdrecord keeps waiting for convergence.
I would expect usdrecord to stop waiting and report the failed render when Arras reports that the worker has stopped. One failed render should not block the rest of a batch until an external timeout.
The reason the worker stopped and usdrecord's handling of an aborted recording are separate questions. This report is about the client continuing to wait after Arras has already reported the stopped session.
- Ngôn ngữ chính
- CMake
- Star
- 4.7k
- Fork
- 321
- Merge trung bình
- 13 phút
- Pull request đã merge (30 ngày)
- 3
Chuẩn bị môi trường
- Không có Dockerfile hay tệp Docker Compose
- Có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của OpenMoonRay/openmoonray
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
OpenMoonRay/openmoonray#332 ·
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 64/100
OpenMoonRay/openmoonray#320 ·
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 64/100
OpenMoonRay/openmoonray#233 ·
-
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 57/100
OpenMoonRay/openmoonray#331 ·
-
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 68/100
OpenMoonRay/openmoonray#330 ·
Tất cả issue của OpenMoonRay/openmoonray
Issue tương tự
-
Websockify heartbeat for vnc_containerCó thể đã có người làm @robinkar đã nhận hôm nay. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
Maintainer thường phản hồi trong vòng 1 ngày
-
needs-triage
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 77/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
swc-project/swc-ai-issues#414 ·
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 84/100
swagger-api/swagger-client#4318 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
line/centraldogma#1397 ·
Maintainer thường phản hồi trong vòng 2 ngày