[Openmcl-devel] CCL/Cocoa Mountain Lion Challenges
Gary Byers
gb at clozure.com
Fri Aug 24 21:17:14 PDT 2012
I didn't see anything unusual running this under the trunk or running
it under the 32-bit 1.8.
The call to PROCESS-RUN-FUNCTION would likely have caused the 64-bit CCL 1.8
to have to have burned lots of CPU and memory, as has already been discussed.
On Fri, 24 Aug 2012, Alexander Repenning wrote:
>
> On Aug 24, 2012, at 9:07 AM, Gary Byers wrote:
>
> Your example leaks memory; it's not surprising that it behaves
> like it's leaking memory, is it ?
>
>
>
> The memory leak is not surprising and could be addressed with
> a?autorelease-pool. However, what we are seeing is very different. The
> memory leak makes RealMem (as observed via Activity Monitor) climb up, less
> than 1 MB per call. A leak to be sure, but its linear over time. When the
> CPU/Mem burst takes place memory is not growing linearly but is essentially
> EXPLODING to the point where the ALL physical system memory, e.g., 8GB, will
> be used up, i.e., no free system memory left, ?and ?CCL and sometimes even
> OS X itself will lock up. In other words, a single iteration of this loop
> will have memory go up by multiple gigabytes!
>
> Here is an example that I am pretty sure will also reproduce this strange
> behavior on your Mountain Lion machine. One difference, making it a bit more
> similar to our real code is the use of?choose-file-dialog instead of a
> standard alert. ?We ran this on several machines using just the current
> version of CCL from the Mac App store (untouched). This crashed CCL (1.8.1 I
> believe) on every Mountain Lion machine we have. Watch CPU and RealMem of
> CCL closely as you keep mindlessly selecting some silly file somewhere on
> your disk over and over.?
>
> Is this crashing now? I really hope this is because this is driving us
> crazy.?
>
> ___________
>
>
>
>
> (defmacro IN-MAIN-THREAD (() &body body)
> ? (let ((thunk (gensym))
> ? ? ? ? (done (gensym))
> ? ? ? ? (result (gensym)))
> ? ? `(let ((,done nil)
> ? ? ? ? ? ?(,result nil))
> ? ? ? ?(flet ((,thunk ()
> ? ? ? ? ? ? ? ? (setq ,result (multiple-value-list (progn , at body))
> ? ? ? ? ? ? ? ? ? ? ? ,done t)))
> ? ? ? ? ?(gui::execute-in-gui #',thunk)
> ? ? ? ? ?(process-wait "Main thread" #'(lambda () ,done))
> ? ? ? ? ?(values-list ,result)))))
>
>
> (defun CRASH-ME ()
> ? (in-main-thread ()
> ? ? (dotimes (i 100)
> ? ? ?; (ccl::with-autorelease-pool
> ? ? ? ? (ccl::choose-file-dialog)
> ? ? ? ? (ccl::process-run-function
> ? ? ? ? ?'(:name "pointless")
> ? ? ? ? ?#'(lambda ()
> ? ? ? ? ? ? ?))
> ? ? ? ? ;)
> ? ? ? )))
>
> ; (crash-me)
>
>
>
>
>
>
>
>
>
>
>
>
> ?
>
>
>
>
>
>
> I couldn't get this to crash under either Snow Leopard or
> Mountain Lion;
> my naive, uninformed guess is that the leak may be worse on Snow
> Leopard
> (because some of the Mountain Lion code may be using ARC.) ?It's
> also
> possible I suppose that something in the 10.6 Cocoa libraries
> establishes
> an autorelease pool to limit the memory leaking and that the
> 10.8 Cocoa
> libraries don't do this.
>
> (loop
> ?(create-a-bunch-of-autoreleased-nsobjects))
>
> will eventually run out of memory. ?That doesn't seem
> interesting.
>
> (loop
> ?(objc:with-autorelease-pool
> ???(create-a-bunch-of-autoreleased-nsobjects)))
>
> (or equivalent) will generally have bounded memory usage. ?(That
> isn't
> exactly interesting either, but none of this is news.)
>
> On Thu, 23 Aug 2012, Alexander Repenning wrote:
>
> A bit of a pattern is emerging:
>
> - no obvious connection to version of CCL
>
> - strong connection to version of OS X (Mountain
> Lion, 10.8.0 and 10.8.1
>
> only)
>
> - quite inconsistent
>
> - can happen when making threads or not servicing
> events from main thread
>
> for some time
>
> - more likely to crash on CCL 32 than CCL 64
>
> - has a CPU and RealMemory surge manifestation
> (observe with Activity
>
> Monitor)?
>
> Here is a test case.?
>
> ? -?Load code and eval?(crash-me)
>
> - observe CCL System memory in?Activity Monitor
>
> - keep pressing return to OK the modal dialog.
>
> Things may be fine OR you get some initial hick up
> with some small
>
> CPU/RealMem surges making things slower and slower.
> In some cases RealMem
>
> will just use up all you have and crash CCL after
> growing to a couple of
>
> GB.?
>
> If you have a Mountain Lion machine please let me
> know if you also get
>
> problems with this.?
>
> puzzled, ?Alex
>
> ____________
>
> ;(in-package :xlui)
>
> ;; inilined from Libraries
>
> (defun NATIVE-STRING (String) "
>
> ? Return a native string"
>
> ? (#/autorelease (ccl::%make-nsstring String)))
>
> (defmethod STANDARD-ALERT-DIALOG ((Message string)
> &key?
>
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? (Yes-Text "OK")
>
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? (No-Text nil)
>
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? (Cancel-Text nil)
>
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? (Explanation-Text)
>
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? (Is-Critical nil))
>
> ? (let ((Alert (#/init (#/alloc ns:ns-alert))))
>
> ? ? (#/setMessageText: Alert (native-string
> Message))
>
> ? ? (when Yes-Text (#/addButtonWithTitle: Alert
> (native-string Yes-Text)))
>
> ? ? (when No-Text (#/addButtonWithTitle: Alert
> (native-string No-Text)))
>
> ? ? (when Cancel-Text (#/addButtonWithTitle: Alert
> (native-string
>
> Cancel-Text)))
>
> ? ? (when Explanation-Text (#/setInformativeText:
> Alert (native-string
>
> Explanation-Text)))
>
> ? ? (#/setAlertStyle: Alert (if Is-Critical
> #$NSCriticalAlertStyle
>
> #$NSWarningAlertStyle))
>
> ? ? (case ?(#/runModal Alert)
>
> ? ? ? (#.#$NSAlertFirstButtonReturn t)
>
> ? ? ? (#.#$NSAlertSecondButtonReturn nil)
>
> ? ? ? (#.#$NSAlertThirdButtonReturn (throw :cancel
> nil)))))
>
> (defmacro IN-MAIN-THREAD (() &body body)
>
> ? (let ((thunk (gensym))
>
> ? ? ? ? (done (gensym))
>
> ? ? ? ? (result (gensym)))
>
> ? ? `(let ((,done nil)
>
> ? ? ? ? ? ?(,result nil))
>
> ? ? ? ?(flet ((,thunk ()
>
> ? ? ? ? ? ? ? ? (setq ,result (multiple-value-list
> (progn , at body))
>
> ? ? ? ? ? ? ? ? ? ? ? ,done t)))
>
> ? ? ? ? ?(gui::execute-in-gui #',thunk)
>
> ? ? ? ? ?(process-wait "Main thread" #'(lambda ()
> ,done))
>
> ? ? ? ? ?(values-list ,result)))))
>
> ;; the actual crasher
>
> (defun CRASH-ME ()
>
> ? (in-main-thread ()
>
> ? ? (dotimes (i 100)
>
> ? ? ? (standard-alert-dialog "HELLO")
>
> ? ? ? (ccl::process-run-function
>
> ? ? ? ?'(:name "pointless")
>
> ? ? ? ?#'(lambda ()
>
> ? ? ? ? ? ?)))))
>
> ; (crash-me)
>
> ?
>
> On Aug 23, 2012, at 1:17 PM, Paul Krueger wrote:
>
>
> ?????FWIW, I recently upgraded to Mountain Lion and
> am NOT seeing any
>
> ?????Cocoa-related problems with either the IDE or
> my own Cocoa
>
> ?????interfaces and I've been editing lots of lisp
> files. But I am
>
> ?????still on a pretty old version of CCL:
> 1.7-dev-r14583M-trunk
>
> ??????(DarwinX8664)
>
> Paul
>
> On Aug 23, 2012, at 1:21 PM, Alexander Repenning
>
> <Alexander.Repenning at colorado.edu> wrote:
>
>
> ?????We are experiencing some errors, e.g., crashing
> CCL/Cocoa
>
> ?????when just editing a file (with Hemlock). So far
> we have
>
> ?????nothing completely reproducible but I wonder:
>
> - how others experienced new kinds of issues with
> CCL in OS X
>
> Mountain Lion (10.8.0)?
>
> - is there a certain set of fixes introduced into
> CCL
>
> specifically addressing?OS X Mountain Lion. In other
> words is
>
> there some, presumably recent, ?version of CCL that
> should be
>
> used to avoid trouble?
>
> Alex
>
> Prof. Alexander Repenning
>
> University of Colorado
>
> Computer Science Department
>
> Boulder, CO 80309-430
>
> vCard:
> http://www.cs.colorado.edu/~ralex/AlexanderRepenning.vcf
>
> _______________________________________________
>
> 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
>
>
>
> Prof. Alexander Repenning
>
>
> University of Colorado
>
> Computer Science Department
>
> Boulder, CO 80309-430
>
>
> vCard: http://www.cs.colorado.edu/~ralex/AlexanderRepenning.vcf
>
>
>
>
>
More information about the Openmcl-devel
mailing list