﻿id	summary	reporter	owner	description	type	status	priority	milestone	component	version	severity	resolution	keywords	cc
185	Poppler exhausts OS2's semaphore handles when opening large pdfs	Gregg Young		"Poppler has 13 classes that create a new semaphore for each class object. Created in the constructor destroyed in the distructor.  With large documents the number can grow to exhaust the 65,535 available semaphore handles. 

The fix should be relatively easy. Make the semaphores statics. Create in the constructor only if they don't exist then destroy in the exit code. I can do the fix but what should I checkout vendor/current or the trunk? Anything special needed to build it?

Note qpdfview suffers from the same problem. It is possible poppler is leaking semaphore handle but if it is it is at a very slow rate. The problem seems worse in later versions. 

See Lucide ticket 355 for more details. http://trac.netlabs.org/lucide/ticket/355  


"	defect	closed	major		poppler		medium	fixed		ygk@… steve53@…
