Custom Query (1030 matches)

as of Cocotron 2845a0e2fa, doing:

(#_NSRunAlertPanel #@"title" #@"message" #@"Yes" #@"No" #@"Maybe")

from the main thread hangs, burning 100% CPU and (apparently) slowly leaking memory.

I haven't yet tried to create an ObjC example that demonstrates this, though it doesn't seem likely that it's CCL-specific.

See the attached test case.

It appears that the TF bit in the flags register is getting set sometimes when restoring the saved flags from tcr.unboxed0 in SPffcall.

I don't understand how that bit is getting set. I added code to see if the bit was set when doing the initial pushfl, and never saw it. Yet, somehow, tcr.unboxed0 will occasionally end up with the TF bit set, and then we get the 0x80000004 (single-step) exception from Windows after we restore the flags with popfl.

(defun f (n) (if (> n 0) (1+ (f (1- n))) 0))

In GCL,

(handler-case (f 100000)(error (x)(format t "~% handler-case caught error ~s" x) 'boohoo))

results in this:

handler-case caught error #<CONDITIONS::INTERNAL-SIMPLE-STREAM-ERROR.0>

BOOHOO

In Allegro CL, it results in this:

handler-case caught error #<synchronous-operating-system-signal @ #x221524ca>

boohoo

but in CCL we get this...

(handler-case (f 100000)(error (x)(format t "~% handler-case caught error ~s" x) 'boohoo))

Error: Stack overflow on value stack. While executing: F, in process listener(1). Type :POP to abort, :R for a list of available restarts. Type :? for other options

So CCL does not have error handling for this kind of error. If it is to be used seriously as a replacement for GCL on Windows, it has to recover better than this.

version: Welcome to Clozure Common Lisp Version 1.6-r14468M (WindowsX8632)!

Thanks

Richard Fateman fateman@…