Custom Query (1030 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


Results (292 - 294 of 1030)

Ticket Resolution Summary Owner Reporter
#768 fixed ObjC instance initialization failures Gary Byers
Description

Several people have reported (http://clozure.com/pipermail/openmcl-devel/2010-October/012207.html) that the IDE can fail to start properly; one symptom is that creation of the initial listener can fail with a message to the effect that a Hemlock buffer named "Untitled" already exists.

This seems to be caused by the fact that an earlier attempt to create a listener fails (after the "Untitled" Hemlock buffer is created) because some instances of some hybrid objects (HEMLOCK-TEXT-STORAGE and friends) aren't properly initialized, which in turn seems to be due to the fact that the hash table which maps ObjC classes to sets of init keywords has been an EQL hash table; if foreign addresses of classes change, there's a good chance that classes won't be found in that table and their instances won't be correctly initialized.

We canonicalize ObjC class pointers and preserve them across sessions. *CLASS-INIT-KEYWORDS* should hash on identity, not foreign address.

This should be fixed in a minute. It was introduced in the trunk in r14263.

#815 fixed Linux stack overflow detection Gary Byers
Description

http://clozure.com/pipermail/openmcl-devel/2011-January/012498.html

describes a problem which affected someone running ARM Linux. It's not clear what Linux versions and architectures are affected.

Traditionally, Linux maps in pages of the initial thread's control/C stack as they're touched. The new (or at least previously unobserved) behavior involves the kernel not mapping a page that would be adjacent to another mapped region (like the guard page region that CCL uses to detect stack overflow) and causes the stack limit check in the recursive marker to fail.

I think that the simplest fix is likely to ensure that all pages between the stack area's softlimit and current sp are mapped read-write, so that the kernel's lazy faulting-in of stack pages doesn't try to exercise policy.

#818 fixed NSRunAlertPanel() hangs on Cocotron Gary Byers
Description

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.

Batch Modify
Note: See TracBatchModify for help on using batch modify.
Note: See TracQuery for help on using queries.