Opened 5 years ago

Closed 5 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 5 years ago by sjamaan

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 calls return 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.

comment:2 Changed 5 years ago by sjamaan

Resolution: invalid
Status: newclosed

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...

Note: See TracTickets for help on using tickets.