> On Fri, 2005-11-25 at 11:10 +1030, Jonathan Woithe wrote: > > I have since discovered (thanks to strace) that the problem lies in an > > mmap2() call which requests a size of around 8MB. It appears to be > > part of the NPTL pthread_create() function. The error returned by > > mmap2() (EAGAIN) indicates either a locked file or "too much locked > > memory" (according to the manpage). Because this is an anonymous map > > the problem must have been the latter. Increasing the "locked memory" > > limit from 20MB to 40MB made jackd start without having to resort to > > the LD_ASSUME_KERNEL hack. > > I stumbled across the same problem a few weeks ago working on another > project. This is glibc allocating an 8MB (!) stack for each thread. It > gets the default thread stack size from getrlimit(). With mlockall() > you will go OOM really fast like that. > > The real fix is for JACK to set a reasonable thread stack size in > jack_create_thread. You can work around the problem by appending this > line to /etc/security/limits.conf: > > * hard stack 512 > > for a 512KB stack.
I tried this. Although this reduced the size of the mlock calls I found I still needed an mlock limit of at least 40MB for jack and ardour to start. However, even with this loading a large session into ardour failed to load with no error given (beyond the fact that the loading failed). You mentioned in another post that you're working on a "proper" fix for jack. I'll wait for this to be implemented before digging into this issue further since the correct fix might change things. Drop me a line when a fix has made it into CVS and I'll resume my testing. Regards jonathan
