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

[Ralph Moritz]

Thanks for explaining Gary. I've tried debugging with gdb & results are
similar to VS, but now we have a function name:
RtlGenerate8dot3Name. Unfortunately, I'm stuck at this point since I don't
know what foreign code is calling RtlGenerate8dot3Name since the addresses
further up the stack seem to be bogus. FYI I'm running the latest ccl trunk.
There has to be some way to figure out  what code is responsible for the
crash! If you know any advanced debugging techniques that you could share
with me that would be great.

gdb session paste: http://paste.lisp.org/+2ICD/2

On 3 December 2010 12:08, Gary Byers <gb at clozure.com> wrote:

>
>
> 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
>>
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clozure.com/pipermail/openmcl-devel/attachments/20101203/2d377d5e/attachment.htm>