Thanks for the quick response. Threading is not completely essential for what I'm doing right now, but certainly a nice-to-have at least. It seems disabling the thread check in this case removes the leak (I'm only using one context), but does introduce other odd behavior that I haven't figured out yet. I removed the other threads I had for now, but would be interested in looking at this some more -- perhaps I will stop by sometime next week.
David On Feb 2, 2012, at 4:56 PM, Andreas Kloeckner wrote: > On Thu, 2 Feb 2012 14:49:32 -0500, David Eigen <dei...@cs.nyu.edu> wrote: >> Hi, >> >> I ran into a gpu memory leak that appears to happen when gc frees GPUArrays >> that were created in a thread other than the one gc is running in. I did >> not see a github issue tracking this. Is this a known issue that others >> have run into? I'm using pycuda 2011.2.2 with python 2.6.7. >> >> This happens when gc frees a DeviceAllocation that had been created in >> another thread. Since there are no refs to it, it is indeed freed, and the >> destructor tries to free the corresponding CUdeviceptr. However, the >> following lines cause mem_free not to be called: the >> scoped_context_activation checks that the running thread matches the >> context's thread; since it doesn't, it throws an exception, which is >> silently caught in CUDAPP_CATCH_CLEANUP_ON_DEAD_CONTEXT: >> >> class device_allocation ... >> void free() >> { >> if (m_valid) >> { >> try >> { >> scoped_context_activation ca(get_context()); >> mem_free(m_devptr); >> } >> CUDAPP_CATCH_CLEANUP_ON_DEAD_CONTEXT(device_allocation); >> >> I was wondering how to go about fixing or working with this, or if >> anyone has any advice? > > OpenCL is a better API if you absolutely need threading, so using > PyOpenCL is one possible workaround. Using processes rather than threads > is another workaround, possibly with some explicitly shared memory. [1] > (Note you need to fork before pycuda.init(), it seems.) > > [1] > http://docs.python.org/dev/library/multiprocessing.html#module-multiprocessing > > If you absolutely want this fixed, you might introduce a per-context > queue of things to be freed. I'll warn you that context management in > CUDA is a mess with poorly documented semantics. This got partially > fixed with a new, less broken API in CUDA 4.0, and I'm happy that the > current code doesn't seem to be too horribly broken. If we were to > switch to APIs now, we'd ditch backward compatibility with CUDA 3.x and > below. > > If you like, you can also just come by to discuss this. (I'm in 1105A WWH) > > Andreas _______________________________________________ PyCUDA mailing list PyCUDA@tiker.net http://lists.tiker.net/listinfo/pycuda