Opened 9 years ago
Closed 8 years ago
#1278 closed defect (invalid)
Assertion failure on Debian/macppc with clang
Reported by: | sjamaan | Owned by: | |
---|---|---|---|
Priority: | critical | Milestone: | 4.11.0 |
Component: | unknown | Version: | 4.10.x |
Keywords: | Cc: | ||
Estimated difficulty: |
Description
Running "make check" on an iBook G4 on Debian Jessie with clang gives the following error:
'clang' 'embedded.o' -o 'a.out' -L/home/sjamaan/src/chicken-4.11.0rc1/tests/.. -Wl,-R/home/sjamaan/src/chicken-4.11.0rc1/tests/.. -L/home/sjamaan/chickens/4.11.0rc1/lib -Wl,-R/home/sjamaan/chickens/4.11.0rc1/lib -lchicken -lm -ldl rm embedded1.o a.out: runtime.c:2795: void C_save_and_reclaim(void *, int, int *): Assertion `C_temporary_stack == C_temporary_stack_bottom' failed.
Marking this as critical until research confirms suspicions voiced by some that this could just be a clang bug because macppc is not a very "alive" platform.
Change History (2)
comment:1 Changed 8 years ago by
comment:2 Changed 8 years ago by
Resolution: | → invalid |
---|---|
Status: | new → closed |
I'm going to assume it's just clang generating shit code.
Even a relatively basic check of running sqlite3 (without a preexisting db or entering any commands) spams the Valgrind log with Invalid read of size 4, 4 bytes below stack pointer
messages. This seems to indicate that clang is consistently clobbering stuff on the stack. Or something...
Stepping through the code with gdb (after upgrading to a recent version of clang) seems to indicate that everything goes well, up until the very moment
CHICKEN_run
callsreturn C_restore;
when it wants to return to the host.I've checked, but if I put a breakpoint on the return line itself, the backtrace/stack frames look fine, but then if I step instruction-wise, the moment it tries to retrieve the return address from the stack, it takes it from the wrong place. Then it returns to the address which is in the temporary stack, instead of the address which it should return to. This is only 3 instructions or so from the actual jump instruction which gets us out of the function.
So I'm not sure yet (a bit more investigation is required), but it looks like Clang is mixing up its registers here.