CUPS cached data (string pool, languages, transcoding data) should be global #1530
Comments
CUPS.org User: mike Since previous versions of CUPS were not thread-safe, I don't think this is the issue, however I can reproduce the problem and will look into it... |
CUPS.org User: twaugh.redhat FWIW, putting 'return strdup (s);' at the very beginning of _cupsStrAlloc() makes the problem go away.. |
CUPS.org User: mike What version of GNOME are you running? I did my testing with the version included with FC4 (2.10.x); I don't see any problems with the 2.14 code, but it is possible they are reusing the string pointer without actually g_strdup'ing it, or perhaps g_strdup() is trying to optimize things by not actually strdup'ing an allocated buffer? If I set the initial reference count to 2, then the problem also goes away... |
CUPS.org User: mike OK, I'm running Valgrind on gedit from GNOME 2.10.x and getting a LOT of errors. When I instrument _cupsStrFlush(), I'm getting it called multiple times for the same thread (or at least the same globals pointer...) Also, if I comment out the _cupsStrFlush() code, then everything works (but still lots of duplicate frees in the GNOME code...) |
CUPS.org User: mike OK, my current working theory is that GNOME is accessing request data created by another thread; when the thread goes away, CUPS deletes the per-thread data and we see the problem. |
CUPS.org User: mike I'm renaming this STR to reflect the actual problem. I'm not sure where to proceed from here; the string pool stuff is a huge performance and memory usage win so we are definitely not going to go back to strdup and free. We might be able to update the implementation to use a single, global (all threads) string pool. We'll need to add a mutex for the string pool, but it should work... |
CUPS.org User: mike [changed STR summary again...] OK, looks like using a global string pool with a mutex protecting it does the trick. I'll do the same for the cups_lang_t and transcoding caches and commit later today. |
CUPS.org User: mike OK, I've commited a fix for this in r5366. Basically, all of the string pool, languages, and transcoding data is now shared among threads. |
CUPS.org User: twaugh.redhat Great, works fine here! Thanks for fixing this quickly. Yes, the string pool is a great idea, and I wouldn't suggest abandoning it. Another performance-only idea is to store large lists (printers, for example) in hash tables. |
CUPS.org User: mike Fixed in Subversion repository. |
Version: 1.2rc1
CUPS.org User: twaugh.redhat
Applications using libgnomeprint, such as gedit, do not work with CUPS 1.2rc1 at all, but work fine with CUPS 1.1.23.
It seems to be some sort of thread-safety issue. The CUPS_GET_PRINTERS request works fine (once the _cupsStrFree() issue I reported earlier is patched), but then the CUPS_GET_PRINTER_ATTRIBUTES requests, which are issued several at once from different threads, become garbled.
The result is that no CUPS queues are shown in the dialog.
Steps to reproduce:
The text was updated successfully, but these errors were encountered: