Run the jsc tests

[walkero-gr]

Once cmake stage is passed, run the JSC tests. Those will expose many potential issues with threading / compiler suite

• Log the process at repo wiki pages

[walkero-gr]

With the latest builds of JSC we get a few test binaries. Here is the outcome of these:

• testair: returns 3 lines of "B3 JIT is not enabled"
• tesdfg: returns "DFG JIT is not enabled"
• testmasm: returns "JIT is not enabled"
• LLIntOffestsExtractor: returns "0x535e5070"
• LLIntSettingsExtractor: returns "0x51213070"
• testb3: returns nothing and crashes after a while. Crashlog
• testapi: passes a lot of tests and crashes at some point Crashlog output: testapi output

[3246251196]

Firstly - the important thing: I can reproduce this on my machine.

It looks like (testapi):
void TestAPI::promiseDrainDoesNotEatExceptions() is the test that is crashing. I will have to do some printf debugging and probably need to run my own version of GCC 11.3 with more printf debugging to get some more information.

Before I do that, I intend to see whether we can build jscore-amigaos with a previous version of GCC (or without the call_once fix that we added). If we can, I would be interested to see if testapi works.

EDIT: Guessing it was that test was just that though - a guess having had a quick look at the testapi source file. Actually, looks like the tests are all ran in threads, so not possible to predict.

I am not so sure it is an actual test that is failing (could be still) versus the actual creation of threads for all of the the tests themselves.

===

1. Modify the testapi to run each test sequentially to see if that has any effect
   -> JSSynchronousGarbageCollectForDebugging(context); This line of code - this function is causing the crash. Drilling down the stack - more specifically: Heap::waitForCollection(Ticket ticket) / NEVER_INLINE bool Heap::handleNeedFinalize(unsigned oldState) [HEAP.CPP]

2. Try to compile with either an earlier version of GCC or 11.3 without the call_once fix
   -> I build 11.3 without patch 0036 (call-once fix). Even with that binary the test crashes. @walkero-gr would be nice if you can confirm this.

Without a debugger to help, I can continue to look into this.

[3246251196]

I do not think it is anything to do with call_once.

The issue seems to be in Heap::runTaskInParallel(task).

task->run(*m_collectorSlotVisitor);

Unfortunately I am dealing with the mess of new-age C++ template crazyness so it is hard to figure out even where the ProgramCounter goes after invoking this!

What I do notice is that in SlotVisitor.cpp there are some macros involving a check as to whether we are MORPHOS/AMIGAOS.

At the moment, my debugging is a matter of adding in printf()s, build, run on the X1000 next to my X5000. But, I think I have narrowed it down to task->run and something inside there.

To be clear: I modified the testapi source code so that it is only running the test: markedJSValueArrayAndGC since that is the test that causes the garbage collector to run.

@walkero-gr

[3246251196]

What am I thinking. Of course, I have a debugger for the x86 machine. I can use the debugger on that machine to figure out where we jump to after the invocation of run(). I'll work on that when I come back from holiday.

[walkero-gr]

@3246251196 Thank you so much for all the work you do on figuring out what the problem is.