[Openmcl-devel] CCL trunk on Linux ARM / Ubuntu - Unhandled exception 4

[Gary Byers]

One of the changes that I neglected to mention in my message the other day is
that the ARM port now tried to reserve more address space on startup than it
had in the past.  It traditionally reserved about .5GB and now it tries to
reserve 1.5GB.

The thing that seems to kind of shoot that theory down is that it looks
like the image loaded for you where it's supposed to now (starting at
#x10000000).

A couple of things that may be worth trying:

1) do things behave differently if you tell the lisp to try to reserve less
memory ?  E.g.

$ ./armcl -R 1G --no-init

2) If it still crashes, could I see the output of the kernel debugger's R
command (which just prints the machine registers in hex.)

It doesn't make sense that the main thread would die with an illegal instruction
188 bytes into DRAIN-TERMINATION-QUEUE or that any thread would die with an
"unhandled exception 4" (SIGILL/illegal instruction) at #x10083464), and we may
just be seeing some artifact related to memory-mapping limitations.


On Fri, 30 May 2014, Rainer Joswig wrote:

> Hi,
>
> I've got a fresh CCL from the SVN trunk into a new directory.
>
> Machine is a ODROID XU. Ubuntu Linux. On my ODROID U3 it seems to work, though.
>
> Recompiling the kernel doesn't help. The error appears immediately after starting armcl .
>
>
> ... at odroidxu:~/Lisp/ccl/ccl$ ./armcl --no-init
> Welcome to Clozure Common Lisp Version 1.10-dev-r16089M-trunk  (LinuxARM32)!
> ? Unhandled exception 4 at 0x10083464, context->regs at #xbed4c288
> ? for help
> [3493] Clozure CL kernel debugger: B
> current thread: tcr = 0x31448, native thread ID = 0xda5, interrupts enabled
>
>
> (#xBED4C558) #x1039C558 : #<Function DRAIN-TERMINATION-QUEUE #x14158be6> + 188
> (#xBED4C588) #x1039C4F0 : #<Function DRAIN-TERMINATION-QUEUE #x14158be6> + 84
> (#xBED4C5B0) #x108679B4 : #<Function (:INTERNAL ADD-GC-HOOK) #x143dd686> + 88
> (#xBED4C5C0) #x104632C0 : #<Function HOUSEKEEPING #x141b0d66> + 44
> (#xBED4C5D0) #x103A4890 : #<Function HOUSEKEEPING-LOOP #x1415c71e> + 348
> (#xBED4C600) #x103A4840 : #<Function HOUSEKEEPING-LOOP #x1415c71e> + 268
> (#xBED4C630) #x103A4830 : #<Function HOUSEKEEPING-LOOP #x1415c71e> + 252
> (#xBED4C670) #x103A47F0 : #<Function HOUSEKEEPING-LOOP #x1415c71e> + 188
> (#xBED4C6E8) #x00009AFC : (subprimitive ret1valn)
> (#xBED4C6F8) #x103A4BD0 : #<Function (:INTERNAL (TOPLEVEL-FUNCTION (LISP-DEVELOPMENT-SYSTEM T))) #x1415c906> + 140
> (#xBED4C728) #x103A4BB4 : #<Function (:INTERNAL (TOPLEVEL-FUNCTION (LISP-DEVELOPMENT-SYSTEM T))) #x1415c906> + 112
> (#xBED4C9B0) #x0000D430 : (subprimitive (null))
> (#xBED4C9E0) #x0000D420 : (subprimitive (null))
> (#xBED4C9F0) #x0000D4D4 : (subprimitive start_lisp)
>
>
> TCR = 0xb6900468, cstack area #xb6902aa0,  native thread ID = 0xda6, interrupts enabled
>
> Regards,
>
> Rainer Joswig
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://lists.clozure.com/mailman/listinfo/openmcl-devel
>
>