[Bug 828751] liblcms2 ver. 2.5 in same process with Ghostscript that has lcms2 2.4 built-in leads to segfault

From my non-expert point of view the fact that downgrading

https://bugzilla.novell.com/show_bug.cgi?id=828751 https://bugzilla.novell.com/show_bug.cgi?id=828751#c14 --- Comment #14 from Johannes Meixner 2013-07-16 10:47:11 CEST --- Regarding comment#10 "there are no problems with lcms2 <= 2.4": I am really not an expert in linking but I think that using lcms2 2.4 only avoids the segfault but this does not mean that all runs correctly. I think when in one same address space (i.e. in one process) the same set of functions gets included two times (once via compiled-in sources and once via a linked library) and those duplicate set of functions is used simultaneously by several threads, but those functions are not thread-safe, then any kind of misbehaviour could happen. liblcms2 to lcms2 2.4 avoids the segfault indicates that somehow the lcms2 functions in Ghostscript and in liblcms2.so get used in a mixed up way. If Ghostscript would use only its built-in lcms2 functions and the other thread would use only the lcms2 functions from liblcms2.so so that both set of functions are used strictly separated, then there should be no segfault regardless what lcms2 version is used in Ghostscript and by the other thread.

From my non-expert point of view the actual bug lies deeper.

I think it is perfectly valid when one free software project incorporates source code from another free software project. For example see Gnulib http://www.gnu.org/software/gnulib/ ----------------------------------------------------------------- Its components are intended to be shared at the source level, rather than being a library that gets built, installed, and linked against. ----------------------------------------------------------------- Therefore I think it is o.k. when Ghostscript incorporates lcms2 at the source level. Furthermore I think it is o.k. when a library is not thread-safe provided it is sufficiently documented so that developers know that they cannot "just use" it in multi-threaded programs. Finally I think it belongs to the developers of a program to ensure that their program runs correctly. In the end this means (from my non-expert point of view): - Ghostscript is o.k. to incorporate lcms2 at the source level. - liblcms2.so is o.k. to be not thread-safe. - Any multi-threaded program that likes to run Ghostscript and liblcms2.so in several threads, must ensure that it runs correctly. Therefore I think that such multi-threaded programs like Evince and LeechCraft Monocle would need to be fixed. For example a multi-threaded program may no longer run Ghostscript and liblcms2.so in several threads simultaneously but only one after the other to get the different lcms2 usages strictly separated. Alternatively a multi-threaded program could get the different lcms2 usages strictly separated by running Ghostscript and liblcms2.so in separated processes via fork() or it may use the clone() system call in a more appropriate way to get the threads better separated. But again: I am really neither an expert in lcms2 nor in linking nor in multi-threading environments so that all I can do here is basically only guesswork. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.