BtoLuevano DJ
App: VirtualDJ Remote App version: 9.0.8515 (build 1) Device: iPad 6th generation (model iPad7,1) OS: iPadOS 17.7.11 (build 21H461) Reporter: Long-time VirtualDJ Pro user, custom skin author (BL Audio Systems)
Both crashes below are confirmed reproducible, symbolicated, and occur with no custom skin loaded vs. with a custom skin — same result. They are internal app crashes, not skin/XML issues. Full raw crash logs (Apple .ips format) are attached/available for both incidents on request.
Bug 1 — SIGSEGV in coverEngine thread on track load / during Automix
Incident ID: E20C5C44-90CD-43C0-8C4F-D9882A7F7627 Timestamp: 2026-08-05 12:30:23 -0600 Exception: EXC_BAD_ACCESS / SIGSEGV, KERN_INVALID_ADDRESS at 0x10a5ee3ec Crashing thread: coverEngine
Description
The app terminates abruptly (no error dialog, no warning — the process simply exits) when a new track is loaded into a deck, and reliably during Automix sessions with frequent track transitions. The crash is a segmentation fault inside the thread named coverEngine, which handles album-art/cover-art decoding and (in skins using <cover rotate="yes">) real-time rotation of the artwork bitmap.
Reproduction steps
Load VirtualDJ Remote on an iPad, connected to VirtualDJ desktop (Pro).
Play tracks continuously and load new tracks into either deck (manually or via Automix) at a normal mixing pace.
Within a short session (observed within minutes), the app crashes to the Home Screen with no on-screen error.
Root cause (as far as we could isolate it)
The crash consistently traces to the coverEngine thread — the internal routine responsible for extracting and rendering track cover art. Any skin element that repeatedly triggers cover-art re-render on track change (e.g. a rotating jog-wheel <cover> element) reliably triggers it faster, but the crash also occurs with the stock skin under normal use — it is not dependent on any specific third-party skin.
Workaround currently in use
We removed all <cover> elements from our custom skin (jog-wheel cover art, deck-info thumbnail cover art) as a mitigation. Since removing them, the app has run for extended sessions (tested with rapid, repeated track ejects during Automix) with zero crashes. This strongly confirms the cover-art rendering pipeline (coverEngine) as the fault origin.
Requested fix
Please investigate the coverEngine thread's handling of cover-art bitmap decoding/rotation on rapid track changes for a memory-safety issue (invalid pointer access / use of a stale buffer). This is a segmentation fault (SIGSEGV), not a benign warning — it is fully reproducible and currently forces users to either avoid cover art in skins entirely or risk crashes mid-set.
Bug 2 — SIGSEGV in AURemoteIO::IOThread when VirtualDJ desktop is closed
Incident ID: 70CE12E5-3C7A-4DB2-829F-D8836630E11D Timestamp: 2026-08-05 14:00:30 -0600 Exception: EXC_BAD_ACCESS / SIGSEGV, KERN_INVALID_ADDRESS at 0x0000000000000620 (Data Abort, byte read translation fault, far: 1568) Crashing thread: AURemoteIO::IOThread
Description
When VirtualDJ desktop (Mac) is closed/quit for any reason while VirtualDJ Remote is actively connected, VirtualDJ Remote itself also crashes a moment later — it is not manually closed by the user. The crash is unrelated to Bug 1 and occurs on a completely different thread.
Reproduction steps
Connect VirtualDJ Remote (iPad) to VirtualDJ desktop as usual, with the Remote actively receiving the live audio stream (used for on-screen metering/monitoring).
Quit VirtualDJ on the desktop (Mac) side.
VirtualDJ Remote on the iPad crashes almost immediately afterward, without any user interaction on the iPad.
Root cause (as far as we could isolate it)
The crashing thread, AURemoteIO::IOThread, is the Core Audio remote I/O render thread — responsible for continuously pulling the incoming audio stream from the desktop connection. The crash trace goes through AudioConverterV2::fillComplexBuffer → AUInputElement::PullInput → AUInputFormatConverter2::InputProc, reading from a near-null pointer (far: 0x620). This is consistent with the audio session/connection being torn down (because VirtualDJ desktop just quit) while the render callback on the iPad is still actively trying to pull audio from it, dereferencing a pointer that is no longer valid.
Requested fix
Please add a graceful teardown path for the AURemoteIO render thread when the network connection to VirtualDJ desktop is lost or closed by the remote side (i.e., stop/tear down the audio render callback before the underlying connection object is invalidated, rather than after). Currently there is no safe disconnect path — any unexpected shutdown of the desktop app takes the Remote app down with it.
Note on a previous feature request (context only, not a bug)
We previously requested wired-network (Ethernet/USB, not Wi-Fi) support/compatibility for VirtualDJ Remote for more reliable live use, and did not receive traction on it. For the record: we've since confirmed that forcing a wired connection has no effect on either crash described above — both are internal app bugs unrelated to connection medium. We're separating that feature request from these two bug reports so it doesn't dilute or delay a fix for the crashes, which are the priority here.
Summary: Two independently reproducible SIGSEGV crashes, both fully symbolicated with named threads (coverEngine, AURemoteIO::IOThread), on a supported OS/device combination (iPadOS 17.7.11, iPad7,1), with clear, minimal reproduction steps. Happy to provide the full raw .ips crash logs for both incidents, and to test any proposed fix.
Both crashes below are confirmed reproducible, symbolicated, and occur with no custom skin loaded vs. with a custom skin — same result. They are internal app crashes, not skin/XML issues. Full raw crash logs (Apple .ips format) are attached/available for both incidents on request.
Bug 1 — SIGSEGV in coverEngine thread on track load / during Automix
Incident ID: E20C5C44-90CD-43C0-8C4F-D9882A7F7627 Timestamp: 2026-08-05 12:30:23 -0600 Exception: EXC_BAD_ACCESS / SIGSEGV, KERN_INVALID_ADDRESS at 0x10a5ee3ec Crashing thread: coverEngine
Description
The app terminates abruptly (no error dialog, no warning — the process simply exits) when a new track is loaded into a deck, and reliably during Automix sessions with frequent track transitions. The crash is a segmentation fault inside the thread named coverEngine, which handles album-art/cover-art decoding and (in skins using <cover rotate="yes">) real-time rotation of the artwork bitmap.
Reproduction steps
Load VirtualDJ Remote on an iPad, connected to VirtualDJ desktop (Pro).
Play tracks continuously and load new tracks into either deck (manually or via Automix) at a normal mixing pace.
Within a short session (observed within minutes), the app crashes to the Home Screen with no on-screen error.
Root cause (as far as we could isolate it)
The crash consistently traces to the coverEngine thread — the internal routine responsible for extracting and rendering track cover art. Any skin element that repeatedly triggers cover-art re-render on track change (e.g. a rotating jog-wheel <cover> element) reliably triggers it faster, but the crash also occurs with the stock skin under normal use — it is not dependent on any specific third-party skin.
Workaround currently in use
We removed all <cover> elements from our custom skin (jog-wheel cover art, deck-info thumbnail cover art) as a mitigation. Since removing them, the app has run for extended sessions (tested with rapid, repeated track ejects during Automix) with zero crashes. This strongly confirms the cover-art rendering pipeline (coverEngine) as the fault origin.
Requested fix
Please investigate the coverEngine thread's handling of cover-art bitmap decoding/rotation on rapid track changes for a memory-safety issue (invalid pointer access / use of a stale buffer). This is a segmentation fault (SIGSEGV), not a benign warning — it is fully reproducible and currently forces users to either avoid cover art in skins entirely or risk crashes mid-set.
Bug 2 — SIGSEGV in AURemoteIO::IOThread when VirtualDJ desktop is closed
Incident ID: 70CE12E5-3C7A-4DB2-829F-D8836630E11D Timestamp: 2026-08-05 14:00:30 -0600 Exception: EXC_BAD_ACCESS / SIGSEGV, KERN_INVALID_ADDRESS at 0x0000000000000620 (Data Abort, byte read translation fault, far: 1568) Crashing thread: AURemoteIO::IOThread
Description
When VirtualDJ desktop (Mac) is closed/quit for any reason while VirtualDJ Remote is actively connected, VirtualDJ Remote itself also crashes a moment later — it is not manually closed by the user. The crash is unrelated to Bug 1 and occurs on a completely different thread.
Reproduction steps
Connect VirtualDJ Remote (iPad) to VirtualDJ desktop as usual, with the Remote actively receiving the live audio stream (used for on-screen metering/monitoring).
Quit VirtualDJ on the desktop (Mac) side.
VirtualDJ Remote on the iPad crashes almost immediately afterward, without any user interaction on the iPad.
Root cause (as far as we could isolate it)
The crashing thread, AURemoteIO::IOThread, is the Core Audio remote I/O render thread — responsible for continuously pulling the incoming audio stream from the desktop connection. The crash trace goes through AudioConverterV2::fillComplexBuffer → AUInputElement::PullInput → AUInputFormatConverter2::InputProc, reading from a near-null pointer (far: 0x620). This is consistent with the audio session/connection being torn down (because VirtualDJ desktop just quit) while the render callback on the iPad is still actively trying to pull audio from it, dereferencing a pointer that is no longer valid.
Requested fix
Please add a graceful teardown path for the AURemoteIO render thread when the network connection to VirtualDJ desktop is lost or closed by the remote side (i.e., stop/tear down the audio render callback before the underlying connection object is invalidated, rather than after). Currently there is no safe disconnect path — any unexpected shutdown of the desktop app takes the Remote app down with it.
Note on a previous feature request (context only, not a bug)
We previously requested wired-network (Ethernet/USB, not Wi-Fi) support/compatibility for VirtualDJ Remote for more reliable live use, and did not receive traction on it. For the record: we've since confirmed that forcing a wired connection has no effect on either crash described above — both are internal app bugs unrelated to connection medium. We're separating that feature request from these two bug reports so it doesn't dilute or delay a fix for the crashes, which are the priority here.
Summary: Two independently reproducible SIGSEGV crashes, both fully symbolicated with named threads (coverEngine, AURemoteIO::IOThread), on a supported OS/device combination (iPadOS 17.7.11, iPad7,1), with clear, minimal reproduction steps. Happy to provide the full raw .ips crash logs for both incidents, and to test any proposed fix.
Inviato Wed 05 Aug 26 @ 8:37 pm
Adion
Can you still reproduce with 9583?
Inviato 7 days ago @ 4:39 pm
BtoLuevano DJ
Adion wrote :
Can you still reproduce with 9583?
Yes, still fully reproducible on build 18.0.9583. All the crash logs I've collected from this machine show that exact desktop build across multiple sessions (Aug 2–Aug 7), paired with VirtualDJ Remote 9.0.8515 on the iPad side. The coverEngine SIGSEGV happens consistently on track load/Automix regardless of skin used, and I've now got several separate crash reports confirming it on that build. Happy to pull the exact incident IDs/timestamps if it helps narrow it down.
Inviato 7 days ago @ 6:54 pm