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

[Ralph Moritz]

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?

Regards,
Ralph


On 1 December 2010 22:44, Gary Byers <gb at clozure.com> wrote:

> All that we can really tell from that paste is that some sort of
> exception (illegal memory reference, illegal instruction, ...)
> occurred while executing foreign (C) code.  I can tell (by the
> value of %rip in the register display) that the foreign code
> isn't in CCL's kernel, but I have no idea what shared library
> it is in.
>
> My recollection is that someone on the #ccl IRC channel ran into this
> (or something very similar) a few weeks ago and that they eventually
> resolved the problem by upgrading to the 1.6 release candidate (see
> <http://trac.clozure.com/ccl/wiki/ReleaseNotes/1.6>, and note that
> those release notes mention the fact that older versions of CL-FAD
> define a conflicting version of the function CCL:DELETE-DIRECTORY.
> Loading older versions of CL-FAD in 1.6 will CERROR when reporting
> this conflict; it's possible to safely continue at that point.
>
> On Wed, 1 Dec 2010, Ralph Moritz wrote:
>
>  Hi everyone,
>>
>> I know this might be regarded as OT but someone suggested this might
>> be a Clozure CL bug & that I should post it here.
>>
>> Anyway, a paste is worth a 1,000 words:
>> http://paste.lisp.org/display/117085#1
>>
>> TIA,
>> Ralph
>>
>>
>> _______________________________________________
>> Openmcl-devel mailing list
>> Openmcl-devel at clozure.com
>> http://clozure.com/mailman/listinfo/openmcl-devel
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clozure.com/pipermail/openmcl-devel/attachments/20101203/7c2e288b/attachment.htm>