[Openmcl-devel] ticket 670 (webkit crash in 64-bit ccl)

[Gary Byers]

Someone on #ccl a few months ago claimed that they'd written an ObjC 
equivalent and that it didn't crash.  I think that I've run the lisp
example a few times without crashing, so that isn't really conclusive.

In most of the times that I've seen it crash (for me or others), some
JITted JavaScript code has branched into the middle of a JMP instruction;
I don't know whether it's just miscalculating a branch displacement or
what the story is, but I don't know how we'd affect that if we wanted
to.

CCL's WebKit example is pretty old; I don't know whether there's such
a thing as a more modern (but equally simple) example, or whether such
a thing would crash in the same way.

I have no objection to making DTS engineer's head explode.  (By accident
and with plausible deniability, of course.)  If there was some way to
use a strictly-ObjC example to cause that accidental explosion, that'd
be a way to kill two birds with one stone, as it were (get something
into Apple's bug tracking system and provide cheap entertainment at the
same time.)  A lisp example might cause an even larger explosion, but
after the thrill of that wears off there's little reason to believe that
any underlying bug would actually be brought to the attention of someone
who could do something about it.

The "OpenGL bug" that Gary Palter had been working on was actually caused
by user code allocating too small of a buffer; OpenGL quite reasonably
wrote past the end of the allocated buffer.  Sometimes, that caused a
violent crash and other times there were no observable effects.  (As 
address spaces get larger, the chances that randomly scribbling over
memory scribbles over something important decrease.)  The little bit
that I could understand about the JIT/JavaScript crash here included
the observation that some of the buffers that the JIT engine used were
(a) large and (b) not at fixed addresses.  It's possible (just as an
example) that some variable somewhere is only 32 bits wide but really
needs to be 64 bits wide, that things only work correctly if some JIT
engine data structures are within 32 bits of each other and that loading
the framework(s) into a running ccl64 makes that harder to achieve.  That
may or not be plausible, but it's an example of how CCL could expose an
existing bug in other code just by hogging some address space.

Whatever ccl would be doing to trigger this bug, it's not clear that it's
any less passive than it would be in that example.


On Mon, 19 Apr 2010, R. Matthew Emerson wrote:

> http://trac.clozure.com/ccl/ticket/670
>
> I'm not sure what to do about this bug.  It *seems* to be something that ccl can't do anything about.
>
> I guess the thing to do is to create a bug report with Apple, attach a copy of Clozure CL64.app, and tell them to type
>
> (require 'webkit)
> (ccl::browser-window "http://www.apple.com")
>
> I wonder if that would cause some DTS engineer's head to explode.
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
>
>