You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
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.
The text was updated successfully, but these errors were encountered: