[Bug-openmcl] processes not gc'd?
erik at adaptations.com
Sun Feb 29 23:53:58 MST 2004
Gary Byers wrote:
> On Sun, 29 Feb 2004, Erik Pearson wrote:
>>It looks like the creation of threads leads to a lot of memory
>>allocation that is not recovered by the gc. Here is a small test
>>function which creates n threads. I've tried it with n of 100, 1000,
>>10000, etc. and inspected memory allocation with top, and it just grows
> I found growth at 10000; I hadn't seen it earlier.
> When a thread exits, it deallocates the resources (stacks and semaphores)
> it had allocated on creation. This is pretty simple code and it seems
> to work reliably in simple cases.
Indeed. With DEBUG_THREAD_CLEANUP turned on (and recompiling the
kernel), it looks as if the thread termination code is not being run
correctly in the test code. If threads are created one at a time slowly
(by hand, once every few seconds), the termination code is executed each
time. However, when threads are created in rapid succession (with some
overlap) as in the test code, it looks like the cleanup code runs a few
times, and the stops after which it never runs. Perhaps something is
deadlocked? I don't know enough about this stuff or the codebase to say
>>(defun test (n)
>> (dotimes (i n)
>> (process-run-function ""
>> #'(lambda (j) (+ j j)) i)))
> The case that I'd want to look at harder is how well-serialized this
> deallocation is. Part of what happens there is that threads remove
> things from various lisp kernel data structures, and I'm not sure
> that all of those accesses are protected by locks. (For that matter,
> I'm not 100% sure that the additions to those data structures that
> occur when a thread's created are properly serialized, so there'd
> be two ways to lose here.) One of the first things that the lisp
> kernel does is to allocate a lock ('area_lock'), but that doesn't
> seem to be used anywhere.
> It seems pretty clear that if two threads try to manipulate the
> list of "interesting memory areas" at the same time, Bad Things
> Will Happen. It's less clear that these bad things will include
> never getting around to deallocating stacks, etc.
>>I discovered this when doing a test of a web-site-monitoring tool which
>>uses threads for timouts, and it eventually crashed.
> It should work to do so, but there's almost certainly a better way
> to do this.
More information about the Bug-openmcl