Open santiago046 opened 11 months ago
Strange. This might be a bug in libuv. I suspect UV_THREADPOOL_SIZE
is ending up as a negative value? Or something? In that case, libuv would try to allocate 1024 threads, which might be crashing.
Does UV_THREADPOOL_SIZE=4 maxcso
work? It should be defaulting to 4, actually. I could add some detection.
-[Unknown]
Does UV_THREADPOOL_SIZE=4 maxcso work?
No, it didn’t work.
I tried setting --threads
to values beyond the total CPU cores that my device has (8) and I got some interesting outputs from fish shell.
$ maxcso --threads 355 game.iso
game.iso: 0%, ratio=10216%, speed= 0.20 MB/s<jemalloc>: Error allocating TSD
<jemalloc>: Error allocating TSD
fish: Job 1, 'maxcso --threads 355 game.iso' terminated by signal SIGABRT (Abort)
$ maxcso --threads 1024 game.iso
fish: Job 1, 'maxcso --threads 1024 game.iso' terminated by signal SIGABRT (Abort)
When not specified:
$ maxcso game.iso
fish: Job 1, 'maxcso game.iso' terminated by signal SIGSEGV (Address boundary error)
When
maxcso
is run on my ARMv7 Android device via Termux without specifying the number of threads, a segmentation fault occurs:However, when the
-h
option is used, or an invalid argument is provided, or the number of threads is specified without an input.iso
, the help text appears normally. Additionally, when the number of threads is specified with an input.iso
,maxcso
runs as expected.A friend of mine tried to reproduce this error on his AArch64 Android device, but fortunately had no problems.