[Openmcl-devel] Modal dialog problems with CCL 1.9 32/64 on Mountain Lion

[Alexander Repenning]

I think I have here a pretty Kosher (uses retain, does not use depreciated functions) version of the dialog + memory surge problem. This version of choose-file-dialog is completely stripped of any non essential activity. It does not even return the path, i.e., there is no practical value to this function.

Please have a go and see if you can or cannot experience that Memory surge phenomenon. Please follow the instructions closely. Otherwise you may miss the issues at sometimes can be kind subtle. 

Alex


______________

;; CCL 1.8.1 64 (Mac App store) crash on Mountain Lion 10.8.1


(defun choose-file-dialog2 ()
  ;; 100% kosher: retain, no use of depreciated calls
  (let ((panel (#/retain (#/openPanel ns:ns-open-panel))))
    (#/runModal panel)
    (#/release panel)))


(defun THE-AMAZING-MEMORY-SURGE ()
  (dotimes (i 100)
    (ccl::with-autorelease-pool
        (choose-file-dialog2)
      (ccl::process-run-function "pretent to load project"  #'(lambda () )))))


;; this will pop up a file chooser for a number of times. Each time just press ESC and watch the Activity Monitor. 
;; Set view > update frequency in Actvity Monitor to very often (0.5s) for best results
;; Watch out for Clozure CL % CPU and Real Mem
;; for some time Real Mem will go up gradually (memory leak) then at some unpredicatable time it will SURGE to GIGABITES of memory and ultimately crash CCL
;; with with-autorelease-pool CCL may crash quite quickly with a Unhandled exception 10, comment out if needed

; (the-amazing-memory-surge)

_______________











On Aug 28, 2012, at 3:08 PM, Gary Byers wrote:

> 
> 
> On Tue, 28 Aug 2012, Raffael Cavallaro wrote:
> 
>> 
>> On Aug 28, 2012, at 9:21 AM, Gary Byers <gb at clozure.com> wrote:
>> 
>>> People who are
>>>  tempted to ascribe supernatural powers to some versions of CCL (powers that
>>>  allow it to hide some files/directories that would otherwise appear) might
>>>  want to try toggling the presentation style (whatever it's called) to see
>>>  if this is just a Mountain Lion display/caching bug.
>> 
>> I am not in any way tempted to ascribe supernatural powers to any version of CCL - though I have at times been tempted to ascribe supernatural powers to you and Matthew ;^)
>> 
>> Changing the presentation style (whatever it's called) does cause the directories to populate, and to remain populated when the style is changed back. However, subsequent calls to ccl::choose-file-dialog still show the same empty-directories-until-presentation-style-is-changed issue.
>> 
>> It would still be useful to know why this only manifests with ccl::choose-file-dialog and not with File:Open? (nor with any other application), but that's just idle curiosity?
> 
> My current theory is that the methods invoked by the shared instance
> of NSDocumentController (that implement things like File:Open) work
> more reliably because they aren't as brain-dead about autoreleasing
> things that need to stick around through a modal event-loop as
> CCL::CHOOSE-FILE-DIALOG seems to be.  According to TFM (which I just
> R'ed), the NSOpenPanel itself has to be explicitly retained on (at least)
> 10.6 and earlier, and I don't think that CHOOSE-FILE-DIALOG has ever bothered
> to do that.
> 
> 
>> 
>> Maybe its because the deprecated #/runModalForDirectory:file:types: is causing problems under Mountain Lion even for apps like CCL that are not sandboxed.
> 
> My first attempt at replacing the deprecated method with supported
> ones caused my tests to start showing unpopulated directories; I'd only
> seen that once before.  Alex was apparently getting reliably good results
> by mixing deprecated methods with their replacements; if his results were
> universally reproducible, I'd have publicly sworn off badmouthing Mountain
> Lion (since it'd have been obvious that the damned thing wasn't even finished
> yet.)
> 
> One of the worst aspects of bugs where things get freed prematurely is
> that the worst symptoms of those bugs may only appear if and when the
> freed memory is reallocated, and when and whether that happens tends
> to be dependent on lots of subtle little things.  That in turn can
> mean that different people see different results and different OS releases seem to behave differently for mysterious reasons.
> 
> I don't know if this is the only problem and I may do something other
> than Fighting The Good Mountain Lion Fight (like sleep ...) before trying
> to check these changes in, but it's pretty clear to me at this point that
> CHOOSE-FILE-DIALOG has never been quite right in its memory management
> behavior.
> 
> 
>> warmest regards,
>> 
>> Ralph
>> 
>> 
>> Raffael Cavallaro
>> raffaelcavallaro at me.com
>> 
>> 
>> 
>> 
>> 
>> _______________________________________________
>> Openmcl-devel mailing list
>> Openmcl-devel at clozure.com
>> http://clozure.com/mailman/listinfo/openmcl-devel
>> 
>> 
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel

Prof. Alexander Repenning

University of Colorado
Computer Science Department
Boulder, CO 80309-430

vCard: http://www.cs.colorado.edu/~ralex/AlexanderRepenning.vcf


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clozure.com/pipermail/openmcl-devel/attachments/20120829/586d9eea/attachment.htm>