Ticking "Seed the crawl from the site's sitemap" on the Spider tab kills the crawl thread with SIGSEGV. The app shows "HTTrack Website Copier has stopped" and the mirror is left half-written. Reproduced 3/3 on an API-25 x86_64 emulator with only that box ticked. --single-file and --changes are unaffected and work correctly.
The GUI is not at fault. The option reaches the engine as its own argv token and logcat shows the sitemap logic working (2 of 2 URL(s) added). The crash is in the engine's hts_log_vprint(), which hands the log callback the caller's va_list and then re-reads that consumed list with vfprintf() when writing hts-log.txt. %d renders 0 and %s becomes a junk pointer that gets dereferenced. Only an embedder that installs a log callback is affected, so the CLI never sees it; this app installs one in htslibjni.c. The --sitemap LOG_NOTICE lines are the first on Android to carry arguments, which is why vc84 exposed a bug older than the feature.
Fixed upstream by xroche/httrack#801. Once that lands: bump the submodule, re-run the device test, ship vc85 (the engine stays 3.49.14, so versionName 3.49.14.85). Already confirmed on device against a locally patched engine, where the sitemap arm finishes, the sitemap-only page is mirrored, and hts-log.txt renders correctly.
vc84 is live on the internal track, so anyone ticking that box there hits this today.
Test harness and full evidence: httrack-works/android-newopts-devicetest/.
Ticking "Seed the crawl from the site's sitemap" on the Spider tab kills the crawl thread with SIGSEGV. The app shows "HTTrack Website Copier has stopped" and the mirror is left half-written. Reproduced 3/3 on an API-25 x86_64 emulator with only that box ticked.
--single-fileand--changesare unaffected and work correctly.The GUI is not at fault. The option reaches the engine as its own argv token and logcat shows the sitemap logic working (
2 of 2 URL(s) added). The crash is in the engine'shts_log_vprint(), which hands the log callback the caller'sva_listand then re-reads that consumed list withvfprintf()when writing hts-log.txt.%drenders 0 and%sbecomes a junk pointer that gets dereferenced. Only an embedder that installs a log callback is affected, so the CLI never sees it; this app installs one inhtslibjni.c. The--sitemapLOG_NOTICE lines are the first on Android to carry arguments, which is why vc84 exposed a bug older than the feature.Fixed upstream by xroche/httrack#801. Once that lands: bump the submodule, re-run the device test, ship vc85 (the engine stays 3.49.14, so versionName
3.49.14.85). Already confirmed on device against a locally patched engine, where the sitemap arm finishes, the sitemap-only page is mirrored, and hts-log.txt renders correctly.vc84 is live on the internal track, so anyone ticking that box there hits this today.
Test harness and full evidence:
httrack-works/android-newopts-devicetest/.