[Openmcl-devel] Webkit issue

Gary Byers gb at clozure.com
Wed Sep 2 17:59:15 UTC 2009

On Wed, 2 Sep 2009, Raffael Cavallaro wrote:

> Under ccl-64 intel, if I do:
> (require 'webkit)
>  and  then use ccl::browser-window to load a static web page,
> everything is fine.
> However, if I use ccl::browser-window to load anything more complex
> (e.g., the Apple home page) then I consistently get the following crash.
> Possibly this is because Safari knows how to talk to server versions
> of browser plug-ins that are still only 32-bit (e.g., QuickTime 7) and
> ccl-64 doesn't? Just a wild guess.
> FWIW, the equivalent is not an issue under either ccl-32 intel or
> LWM-64 intel 5.1.2.
> Should I open a ticket on this?

Yes, but I'm not sure who to open it with.

There doesn't seem to be an issue with visiting www.apple.com with the
simple browser window under Leopard; on Snow Leopard, I crashed at
0x5ab447628ca4; the #x...8ca4 part of that address is similar enough
to the address where you crashed that it seems likely that we're
looking at the same thing.  I attached to the process inGDB, set a
breakpoint there, got to that address, and tried to see how I got there:

Breakpoint 1, 0x00005ab447628ca4 in ?? ()
(gdb) x/i $pc
0x5ab447628ca4:	(bad) 
(gdb) up
#1  0x00007fff8592f9a2 in JSC::Interpreter::execute ()
Initial frame selected; you cannot go up.

I assume that JSC::Interpreter::execute () is part of a JavaScript interpreter.

I'd be pretty confident in saying that nothing that the lisp does intentionally
affects the behavior of a JavaScript interpreter.  I can't say that it's not
unintentionally causing it to call a bogus address, but ... well, I can't say
anything too useful.

I was curious about what method the lisp had last called;

> (#x0000000000442F48) #x00003000410BBBF4 : #<Function (:INTERNAL SEND-
> T))) #x00003000410BBA0F> + 485

doesn't really tell us, and I'd made a change that was supposed to
replace that closure with a uniquely- (and possibly more
meaningfully-) named function.  The lisp that I had on Snow Leopard
was a little old, so I updated it and tried again; www.apple.com loaded
without incident, and (inconclusively) haven't been able to get it to
fail since.

Small sample size, but I have no idea what the bug is or whether CCL
is involved or not.  The webkit "example" is pretty minimal - it
sort of demonstrates that a few lines of code can create something
that's almost a web browser - but once it creates the window/web view/
URL request, there isn't obviously any lisp code involved.

> warmest regards,
> Ralph
> Unhandled exception 4 at 0x5d9945628ca4, context->regs at #x7fff5fbfcff0
> Exception occurred while executing foreign code
> ? for help
> [9551] Clozure CL kernel debugger: ?
> (G)  Set specified GPR to new value
> (R)  Show raw GPR/SPR register values
> (L)  Show Lisp values of tagged registers
> (F)  Show FPU registers
> (S)  Find and describe symbol matching specified name
> (B)  Show backtrace
> (T)  Show info about current thread
> (X)  Exit from this debugger, asserting that any exception was handled
> (P)  Propagate the exception to another handler (debugger or OS)
> (K)  Kill Clozure CL process
> (?)  Show this help
> [9551] Clozure CL kernel debugger: b
> current thread: tcr = 0x100700, native thread ID = 0x207, interrupts
> enabled
> (#x0000000000442F28) #x0000300041389D3C : #<Anonymous Function
> #x0000300041389C8F> + 173
> (#x0000000000442F48) #x00003000410BBBF4 : #<Function (:INTERNAL SEND-
> T))) #x00003000410BBA0F> + 485
> (#x0000000000442F88) #x00003000414F3D04 : #<Function EVENT-LOOP
> #x00003000414F3B5F> + 421
> [9551] Clozure CL kernel debugger: t
> Current Thread Context Record (tcr) = 0x100700
> Control (C) stack area:  low = 0x7fff5f99c000, high = 0x7fff5fbffad0
> Value (lisp) stack area: low = 0x200000, high = 0x443000
> Exception stack pointer = 0x7fff5fbfd4c0
> [9551] Clozure CL kernel debugger: r
> %rax = 0x00000000153e9f00      %r8  = 0x000000000000003f
> %rcx = 0x0000000015d4fc3c      %r9  = 0x00000000152ac120
> %rdx = 0x0000000000000000      %r10 = 0x00000000153ea140
> %rbx = 0x0000000015d6b900      %r11 = 0x0000000015d48300
> %rsp = 0x00007fff5fbfd4c0      %r12 = 0x00000000000001e8
> %rbp = 0x00007fff5fbfd530      %r13 = 0x00000000158ff148
> %rsi = 0x00000000158ff148      %r14 = 0xffff000000000000
> %rdi = 0x0000000015331c00      %r15 = 0xffff000000000002
> %rip = 0x00005d9945628ca4   %rflags = 0x00010246
> [9551] Clozure CL kernel debugger: l
> [9551] Clozure CL kernel debugger: f
> f00: 0x153ea4c0 (3.850016e-26), 0x00000000153ea4c0 (1.760983e-315)
> f01: 0x153ea540 (3.850055e-26), 0x00000000153ea540 (1.760984e-315)
> f02: 0x153ea5c0 (3.850095e-26), 0x00000000153ea5c0 (1.760984e-315)
> f03: 0x153ea640 (3.850134e-26), 0x00000000153ea640 (1.760985e-315)
> f04: 0x153ea280 (3.849838e-26), 0x00000000153ea280 (1.760980e-315)
> f05: 0x74616369 (7.142841e+31), 0x416e6f6974616369 (1.595681e+07)
> f06: 0x00000000 (0.000000e+00), 0x0000000000000000 (0.000000e+00)
> f07: 0x00000000 (0.000000e+00), 0x4060e00000000000 (1.350000e+02)
> f08: 0x00000000 (0.000000e+00), 0x0000000000000000 (0.000000e+00)
> f09: 0x00000000 (0.000000e+00), 0x4080700000000000 (5.260000e+02)
> f10: 0x00000000 (0.000000e+00), 0x4030000000000000 (1.600000e+01)
> f11: 0x00000000 (0.000000e+00), 0x3ff0000000000000 (1.000000e+00)
> f12: 0x00000000 (0.000000e+00), 0x0000000000000000 (0.000000e+00)
> f13: 0x00000000 (0.000000e+00), 0x4030000000000000 (1.600000e+01)
> f14: 0x3b808081 (3.921569e-03), 0x3b8080813b808081 (4.368036e-22)
> f15: 0x3d042108 (3.225806e-02), 0x3d0421083d042108 (8.939086e-15)
> mxcsr = 0x00001fa1
> [9551] Clozure CL kernel debugger: x
> Unhandled exception 4 at 0x5d9945628ca4, context->regs at #x7fff5fbfcff0
> ? for help
> [9551] Clozure CL kernel debugger:
> Raffael Cavallaro
> raffaelcavallaro at me.com
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel

More information about the Openmcl-devel mailing list