Deserialized bytecode does not have IC state, i.e., `bc->ic == NULL`.
That may or may not be bug (IMO, it is and we should rebuild the
IC state during deserialization) but, either way, don't segfault.
DRY add_ic_slot() and its call sites in a hopefully NFC manner.
Don't raise a "invalid tag 12" exception when encountering bytecode
and JS_READ_OBJ_BYTECODE is not set, because no one knows what "tag 12"
means without looking it up, not even quickjs maintainers.
Don't store the update flag in the IC because that's a) an out-of-band
signalling mechanism, and b) makes JSInlineCache bigger than it needs
to be. One is allocated per function so it adds up.
Another reason for making this change is that it makes visible what
I strongly suspect are bugs in the original implementation.
Otherwise it's too easy to tie up too many resources (cpu, memory) by
crafting inputs with a very large atom count (up to 4 billion.)
This may need some finetuning. If the limit proves too restrictive for
very large snapshots, we can make it relative to the size of the input.
Check inside the deserializer that const atoms are indeed const, don't
trust the input. The serializer only writes type 0 records for const
atoms but the byte stream may have been corrupted or manipulated.
Overlooked during review of c25aad7 ("Add ability to (de)serialize
symbols")
Found with libfuzzer and it found it _really_ fast. Great tool.
Before this commit it segfaulted, now it throws a SyntaxError.
That's still not correct behavior but better than segfaulting.
To be continued.
Includes a small run-test262 fix to handle Windows line endings.
Refs: https://github.com/quickjs-ng/quickjs/issues/567
`JS_NewClassID(rt, &class_id)` where `class_id` is a global variable
is unsafe when called from multiple threads but that is exactly what
quickjs-libc.c did.
Add a new JS_AddRuntimeFinalizer function that lets quickjs-libc
store the class ids in JSRuntimeState and defer freeing the memory
until the runtime is destroyed. Necessary because object finalizers
such as js_std_file_finalizer need to know the class id and run after
js_std_free_handlers runs.
Fixes: https://github.com/quickjs-ng/quickjs/issues/577
Make sure the one set in the malloc functions is used rather than the
default one, since it will likely use a different allocator.
For some reason, this didn't cause a problem on macOS, but it does in
Linux. Opsie! Added some CI to prevent these kinds of bugs.
After 56da486312 it's possible existing
code relied on the current exception not being null to dump it, and the
dumped value just said "[unsupported type]". This change provides a more
descriptive value.
Rather than having the user take care of JSMallocState, take care of the
bookkeeping internally (and make JSMallocState non-public since it's no
longer necessary) and keep the allocation functions to the bare minimum.
This has the advantage that using a different allocator is just a few
lines of code, and there is no need to copy the default implementation
just to moficy the call to the allocation function.
Fixes: https://github.com/quickjs-ng/quickjs/issues/285
