Error codes should be expanded to string representations

[AlexDaniel]

Example here:

MoarVM/src/core/threads.c

Line 171 in 8e078a2

MVM_panic(MVM_exitcode_compunit, "Could not spawn thread: errorcode %d", status);

The error message appeared during Blin run:

🥞🥞🥞 Testing Benchmark::Plot (new)
⏳ 901 out of 1305 modules processed
🥞🥞🥞 Testing App::Pray (new)
🥞🥞🥞 Testing Cro::HTTP (new)
🥞🥞🥞 Testing Auth::SCRAM (new)
🥞🥞🥞 Testing CPAN::Uploader::Tiny (new)
MoarVM panic: Could not spawn thread: errorcode -11

However, it's hard to tell what -11 is.

Seems like all you have to do is call uv_strerror or similar function (docs).

[jeffythedragonslayer]

What does your Blin command look like to recreate this?

[AlexDaniel]

@jeffythedragonslayer I don't think you'll be able to reproduce it now, and it doesn't really matter. The point is that it'll be more useful to have readable error messages rather than error codes.

MoarVM/src/core/threads.c

Line 171 in 8e078a2

MVM_panic(MVM_exitcode_compunit, "Could not spawn thread: errorcode %d", status);

.

[jeffythedragonslayer]

Ok, I usually try to recreate bugs I want to fix so I can see the difference before-and-after that my fix works, is all.

[AlexDaniel]

@jeffythedragonslayer but, if you want to reproduce something like this:

echo 1000 > /proc/sys/kernel/threads-max # limit the max num of threads to some small number
perl6 -e 'loop { say $++; Thread.start(sub { sleep ∞ }); }'

Result:

MoarVM panic: Could not spawn thread: errorcode -11

There you go :)

[jeffythedragonslayer]

Ok, this looks like an easy one so long as we are sure the types of errors that cause memory leaks from uv_strerrorrs don't happen, but idk.

[jeffythedragonslayer]

It seems to me that the correct thing to do, if an unknown error occurs, is to call uv__free(void*) on the char* returned by uv_strerrors, since those "Unknown system error" strings are dynamically allocated. For known errors, in uv_strerrors the macroexpansion of UV_ERRNO_MAP(UV_STRERROR_GEN) is a big list of string literals (which probably are statically initialized in .rodata) so those can't leak. Perhaps we should just test whether the returned string begins with "Unknown system error" and if so, free it after printing.

[ugexe]

There is uv_error_r if you want to avoid leaking