[Openmcl-devel] Crash on x64 ccl when loading weblocks

Gary Byers gb at clozure.com
Fri Dec 3 02:08:22 PST 2010



On Fri, 3 Dec 2010, Ralph Moritz wrote:

> I followed the instructions
> in?http://trac.clozure.com/ccl/wiki/CclUnderGdb?& adapted them for Visual
> Studio. %rip is inside ntdll.dll (Windows kernel functions).
> 
> The stacktrace is as follows:
> 
> ?? ?ntdll.dll!0000000077c01da0()
> ?? ?msvcrt.dll!000007feff5010c4()
> ?? ?wx86cl64.exe!000000000002b3ca()
> 
> Would this indicate that code within CCL is calling a Windows function
> incorrectly?

I'm not sure that I trust the address 0x2b3ca; in every copy of
wx86cl64.exe that I've looked at, that address is in the middle of
some instruction.  The ability of MS tools to generate meaningful
backtraces for GCC-compiled code (and vice versa) is pretty limited.
If the call that led to the crash was indeed from that address, it
-may- be in code that tries to free "GCable pointers" after the GC
runs; a scenario like:

(let* ((p (make-gcable-record ...)))
   (use p) ; somehow
   (#_free p))

can cause problems where the GC tries to free the pointer again.
This may be a red herring, since again I'm not sure that the
reported address #x2b3ca is meaningful.

All foreign function calls go through a little bit of code in
the lisp kernel, so seeing that something in wx86cl64.exe called
into some other libraries -could- mean that some foreign function
call is responsible.  If so, we can't tell what foreign function
call, or whether it's a part of CCL itself or some lisp library or
...)

CCL 1.5 on Windows had some general stability problems (related to
threads and GC) and the Win64 FFI had problems passing arguments
in some cases.  (IIRC, the cases in question had to do with functions
whose first few args were a mixture of floating-point and non-FP
values, and with functions whose first several arguments were floats.)
We fixed these in the 1.5 svn tree; if you haven't already done so,
it'd be a good idea to do an "svn update" of a 1.5 installation followed
by a (rebuild-ccl :clean t), or to switch to the 1.6 prerelease.

> 
> Regards,
> Ralph
>






More information about the Openmcl-devel mailing list