Summary: | core dumps when rendering (some glyphs of) CFF fonts | ||
---|---|---|---|
Product: | Ghostscript | Reporter: | Thomas Kaiser <ghostscript> |
Component: | Font API | Assignee: | Ray Johnston <ray.johnston> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | alex, ray.johnston |
Priority: | P4 | ||
Version: | 9.00 | ||
Hardware: | All | ||
OS: | All | ||
Customer: | Word Size: | --- |
Description
Thomas Kaiser
2010-11-23 16:06:57 UTC
Local copy of the sample files is available in spectre.ghostscript.com:/home/support/691792/ On Linux amd64 sample files run to completion when -dNumRenderingThreads=1 and deadlock otherwise. Hmm, I wrote this up a couple of weeks ago, but I must have forgotten to hit the commit button :-( The deadlock, I thought, was due to a race condition in gsicc_findcachelink() here: while (curr->valid == false) { curr->num_waiting++; gx_monitor_leave(icc_link_cache->lock); gx_semaphore_wait(curr->wait); gx_monitor_enter(icc_link_cache->lock); /* re-enter breifly */ } I figured that if, say, thread A is blocked by icc_cache_link->lock in gsicc_set_link_data(), and thread B is doing a cache lookup, thread B finds the cache entry, and identifies that the entry is not yet valid, and enters the above while loop to await for gsicc_set_link_data() to complete its work. In the time between thread B unlocking icc_link_cache->lock and reaching the low level "wait" function, thread A can have completed gsicc_set_link_data() and moved on. The trouble, then, is that gx_semaphore_wait(curr->wait) above is waiting for a signal that has already gone past. This may not be an issue for Windows (I'm not totally sure of the behavior of ReleaseSemaphore/WaitForSingleObject), but is a problem with pthreads. But an experiment to allow gx_semaphore_wait() to unlock the data monitor (icc_link_cache->lock) after it had locked the wait condition mutex didn't change the lockup, so maybe I'm barking up the wrong the tree. However, changing the loop to not use a semaphore, but busy loop polling for valid to become true prevents the lockup (not a suggested fix!). I don't *think* the lockup is to do with FAPI directly, I suspect it's just that it changes the timings slightly, and changes how the rendering code is exercised slightly, and pushes it through the problem code. So reassigning to Michael (sorry!), and explicitly cc-ing Ray, as it's threading related. Reassigning to ray since this is a multi threaded issue. Reassigning to ray since this is a multi threaded issue. It looks like everything works in the current development version. A new release is scheduled this August. I've tried the sample files on AMD x6 box and found no SEGVs. At 360 dpi, 2 rendering threads have the smallest run time. At 1440 dpi, rendering time is about reverse proportional to the number of threads up to 6, which is the number of cores on my box. (I used bmp16m instead of tiff32nc and /dev/null for output) Threaded rendering works well now. |