I recently installed PC-BSD and of course tried to compile Panda on it.
After some modifications (I also had to change executionEnvironment to use /proc/curproc stuff) I’m now running into a weird error that I didn’t have before.
It’s at the first interrogate step:
Assertion failed: (_global_ptr != (NeverFreeMemory *)NULL), function make_global_ptr, file dtool/src/dtoolbase/neverFreeMemory.cxx, line 102.
Yesterday the compile got a lot further, when I didn’t make the /proc/curproc changes yet, so I’m kind of confused.
That’s very weird all right. It’s so weird, I don’t even know why I put that assertion there in the first place, since it can’t possibly trigger.
The assertion is saying that either a NULL value was just assigned to _global_ptr (meaning that “new NeverFreeMemory” returned NULL, which shouldn’t happen) or that the compare_and_exchange_ptr() call failed to assign the ptr, which should only be possible if the pointer wasn’t already NULL. Assuming you’re compiling without true threads–that is, either no threads or simple threads–then AtomicAdjust maps to AtomicAdjustDummyImpl, and you can see how very simple and foolproof that implementation of compare_and_exchange_ptr() is.
So, I’m very baffled. Compiler bug? Something more exotic? I guess you’ll have to put in more assertions and/or debug statements (or try trapping it in gdb) to track it down further.
Hmm, after some further investigation it appears to be a compiler bug indeed. Bleh, I seem to be getting those too often lately.
If I “cerr << result” after the compare_and_exchange_ptr call, _global_ptr seems not to be suddenly reset to NULL anymore.
Any ideas how I can work around without having to print this out?
That’s the most frustrating kind of bug. Are you sure you’re not compiling with true threads enabled? It might also conceivably be a race condition between two different threads.
Other than that, no. You could examine the disassembly generated by the compiler and see if you can determine the nature of the bug, but that’s pretty hardcore.
Ah, I think I see the problem. It is indeed a compiler bug. At address 515 it performs the assignment of mem = new_value, and then the very next instruction is jne, which is the assertion test. But it didn’t actually make the comparison of mem == NULL again; it assumes that the register flags still held the result of the comparison from the line above (where it tested mem == old_value).
It’s as if the compiler didn’t realize that the assignment would change the result of the comparison test.
Well, there’s a simple workaround in this case: comment out or remove altogether the assertion. You don’t really need it.
All I ever did was Z80 ASM.