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

[Alexander Repenning]

On Aug 29, 2012, at 6:00 PM, R. Matthew Emerson wrote:

> 
> On Aug 29, 2012, at 7:04 PM, Alexander Repenning <Alexander.Repenning at colorado.edu> wrote:
> 
>> 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. 
> 
>> ;; CCL 1.8.1 64 (Mac App store) crash on Mountain Lion 10.8.1
> 
> The version of CCL in the Mac App Store still contains a bug in it that Mountain Lion triggers.  I am pretty sure that your test case is running into that bug.



I think we are going around in circles. While that bug does sound similar in spirit I am quite sure its not the one because:

1) the error also manifests itself in the 32 bit version of CCL

2) We tried the most recent version of CCL 1.9-dev-r15450-trunk  (DarwinX8632)! and the 64 bit version. Both the test case and the full app crashed with the same Memory surge.
 
When I try your modified version (which we actually did try before as well) things APPEAR to be better as long as you just dismiss the dialog with ESC. However, the reason for that appear to be that then the file choose dialog goes into this super slow, spinning indeterminate progress indicator mode where it does not list contents of folder. That is interesting. However, if you actually try to select a file, instead of pressing ESC, then there is a good chance it will crash even faster than before. I never made it beyond the first attempt. Can you confirm?

3) An even simpler test just starting 1000 processes, one after the other, does not exhibit the problem (32 bit).

In summary I think we still don't know what is going on but I don't think it is connected to that specific malloc issue you mention.

Need to run but I do remember reading that in sandbox mode (we are NOT running in sandbox or or are we?) file choosers are NOT running in the main thread but in some other special thread. 

hmmm....


puzzled,  Alex 







> 
> Gary mentioned this bug in a previous message:
> 
> - there's a known bug in 64-bit CCL on OSX that can cause lisp thread creation
>   to go into a horrible CPU-burning/memory-thrashing state.  I think that that
>   bug's been present for a long time (since PPC64 days), but it's apparently
>   much easier to trigger on 10.8 (and/or recent versions of CCL) than it has been.
>   The problem ultimately has to do with whether or not #_malloc (actually #_calloc)
>   returns a 64-bit pointer whose high 32 bits are 0 and there can be many factors
>   that affect that (many of them subtle), and the fix is to stop assuming that
>   it does and allocate such pointers ourselves.
> 
>   That's been fixed (in the trunk for a few weeks and in the 1.8 tree
>   for a few days) in svn; the symptoms happen to be very similar to
>   what people have reported seeing with CHOOSE-FILE-DIALOG, but the
>   CHOOSE-FILE-DIALOG problems seem to occur for at least some people
>   in 32-bit CCL (which was never affected by this thread-creation
>   problem) and in freshly-updated 64-bit versions.
> 
> The fix for this bug is not yet in the Mac App Store version of CCL.  I'll try to update the Mac App Store version soon, but in the meantime, please try using up-to-date CCL obtained via Subversion (either trunk or 1.8).
> 
> I modified your test case to make the call to the open panel take place in the main thread.  It seemed to work as expected for me in an up-to-date trunk CCL.
> 
> ;; modified to use gui:execute-in-gui
> (defun THE-AMAZING-MEMORY-SURGE ()
>   (dotimes (i 100)
>     (gui:execute-in-gui #'(lambda ()
>                             (choose-file-dialog2)))
>     (ccl::process-run-function "pretent to load project"  #'(lambda ()))))
> 
> 
> 
>> 
>> 
>> (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)
> _______________________________________________
> 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/e6429dfa/attachment.htm>