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.<div>
<div><br></div><div>gdb session paste: <a href="http://paste.lisp.org/+2ICD/2">http://paste.lisp.org/+2ICD/2</a></div></div><br><div class="gmail_quote">On 3 December 2010 12:08, Gary Byers <span dir="ltr"><<a href="mailto:gb@clozure.com">gb@clozure.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im"><br>
<br>
On Fri, 3 Dec 2010, Ralph Moritz wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I followed the instructions<br>
in?<a href="http://trac.clozure.com/ccl/wiki/CclUnderGdb?&" target="_blank">http://trac.clozure.com/ccl/wiki/CclUnderGdb?&</a> adapted them for Visual<br>
Studio. %rip is inside ntdll.dll (Windows kernel functions).<br>
<br>
The stacktrace is as follows:<br>
<br>
?? ?ntdll.dll!0000000077c01da0()<br>
?? ?msvcrt.dll!000007feff5010c4()<br>
?? ?wx86cl64.exe!000000000002b3ca()<br>
<br>
Would this indicate that code within CCL is calling a Windows function<br>
incorrectly?<br>
</blockquote>
<br></div>
I'm not sure that I trust the address 0x2b3ca; in every copy of<br>
wx86cl64.exe that I've looked at, that address is in the middle of<br>
some instruction.  The ability of MS tools to generate meaningful<br>
backtraces for GCC-compiled code (and vice versa) is pretty limited.<br>
If the call that led to the crash was indeed from that address, it<br>
-may- be in code that tries to free "GCable pointers" after the GC<br>
runs; a scenario like:<br>
<br>
(let* ((p (make-gcable-record ...)))<br>
  (use p) ; somehow<br>
  (#_free p))<br>
<br>
can cause problems where the GC tries to free the pointer again.<br>
This may be a red herring, since again I'm not sure that the<br>
reported address #x2b3ca is meaningful.<br>
<br>
All foreign function calls go through a little bit of code in<br>
the lisp kernel, so seeing that something in wx86cl64.exe called<br>
into some other libraries -could- mean that some foreign function<br>
call is responsible.  If so, we can't tell what foreign function<br>
call, or whether it's a part of CCL itself or some lisp library or<br>
...)<br>
<br>
CCL 1.5 on Windows had some general stability problems (related to<br>
threads and GC) and the Win64 FFI had problems passing arguments<br>
in some cases.  (IIRC, the cases in question had to do with functions<br>
whose first few args were a mixture of floating-point and non-FP<br>
values, and with functions whose first several arguments were floats.)<br>
We fixed these in the 1.5 svn tree; if you haven't already done so,<br>
it'd be a good idea to do an "svn update" of a 1.5 installation followed<br>
by a (rebuild-ccl :clean t), or to switch to the 1.6 prerelease.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Regards,<br>
Ralph<br>
<br>
</blockquote>
<br>
<br>
<br>
</blockquote></div><br>