Let me chime in as the main upstream developper. Thomas thinks that plugin code can be called from multiple thread and proposes a patch for locking critical data structures. If this assumption is correct, Thomas patch seems perfectly sane On the other hand, I will not include and maintain such additional complexity upstream without evidence that the assumption is correct.
I understand that debian deadlines can suggest to do differently. The debian maintainers have the last say about that. I wrote a little code to check whether Thomas assumption is correct. Under firefox3 on ubuntu (my laptop), the plugin is always called from the same thread. There is no crash. It is possible that iceweasel does things differently. I'd be glad if someone can test it using the code attached with my previous post. If iceweasel calls plugins from multiple threads, it makes sense to include such a patch. It also makes sense to wonder whether more plugin issues would be solved by having iceweasel make all plugins calls from the same thread (something firefox apparently does). I would then add upstream a locking code with provisions to enable or disable it from the configure script (djvulibre has to work on lots of platforms.) If iceweasel does not call plugins from multiple threads, Thomas patch cannot solve the bug since it addresses a non existent condition. I do not think then that the patch should be included upstream. Another related bug also describes a djvulibre plugin crash from the kde plugin component nspluginviewer. This component is not multithreaded. Regardless of the conclusion of the iceweasel multithreading test, something is going on there as well. Finally I would also try to reduce the plugin optimization level from -O3 to -O2, just to see if improvements appear. This is another difference between Bastien's experiments (no crash, plugin compiled from djview4 source with -O2) and the distribution (crash, plugin compiled from djvulibre source with -O3)... In short, my upstream decision will depend on the result of additional investigation. Again, I understand that the debian schedule may incite the debian maintainers to decide otherwise... Happy new year for all of you. and warm thanks for the precious help. - Leon Bottou On Tuesday 23 December 2008 17:01:50 Thomas Viehmann wrote: > Hi, > > so Luk wanted to give people a chance to comment before deciding on this > largish fix. I have since privately received correspondence from Leon > indicating that at first sight, the patch looked sane but is doing too > much at once, but would not have time for a more thorough analysis > before the second week of next year. > I would really like to see a working djvulibre-plugin in lenny, so I > wonder what the plan should be. Please also add other djvulibre bugs to > fix in a t-p-u upload if you so desire. > > Kind regards > > T. > -- > Thomas Viehmann, http://thomas.viehmann.net/ > > > -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
