The Persistence of Vision Raytracer (POV-Ray).
This is the legacy Bug Tracking System for the POV-Ray project. Bugs listed here are being migrated to our github issue tracker. Please refer to that for new reports or updates to existing ones on this system.
Opened by Grimbert Jérôme - 2009-05-11
Last edited by Thorsten Fröhlich - 2011-08-23
FS#23 - X Window preview might lock
Beta 32, compiled from source on Linux/Ubuntu, amd64.
The random “window display lock” is back.
(as the previous “solution” was to get no window display usable, that’s not so bad).
What is it: sometime, when the rendering window is activated, povray just draw the frame
of the window, paint it black, does not display anything else but seems to perform the
rendering in separate threads. Whenever the mouse move over the frame of the window, it
unlock the updating process and big parts of the rendered image pop up.
What it is not fine: if you do not move the mouse over the window, povray will just stall.
This is more a problem for animation rendering, as getting the display might be a wanted
bonus to monitor the rendering images, and you just fall into that lock: your expected
night rendering could very well be suspended on the first frame.
Moreover, the “move the mouse over” works only for local display. In previous beta (not
yet checked with 32), with a remote display, there was no way to unlock povray.
It seems tied to a race condition when setting the title of the window (on the bar above the preview window).
Commenting the SDL_WM_SetCaption solves the issue, at the price of a nameless window.
As observed above, the problem indirectly comes from libSDL rather than POV.
Looking at the source code of SDL-1.2.13 as well as the debug logs reported in here the "lock" seems to occur in libxcb (a replacement for Xlib found in recent GNU/Linux distros) while SDL is asking X to process the text strings for the title of the display window and icon name. The relevant log shows that, in the end, libc waits for some input from select() which may be provided by e.g. moving the mouse over the window:
This problem might be worked around by preventing libSDL to call Xutf8TextListToTextProperty(), i.e. by discarding support for UTF-8 when compiling libSDL. I believe this should be done by specifying –disable-x11-shared at configure time in SDL-1.2.13. Note this is my current SDL configuration on a system (also without libxcb) that does not show this lock-alike problem and that was used to build earlier 3.7 beta binaries.
Another and likely better workaround could be indeed to not use SDL_WM_SetCaption(), assuming the lock would not appear elsewhere. That would be done by calling directly the relevant X11 functions.
Another is to completely drop support for SDL, but this is not planned for the next beta
Changed bug severity to “medium” (POV is still usable w/o display) and task type to “compatibility issue” (SDL and/or X11 problem).
On Ubuntu 9.04 (and libSDL from the repo) I cannot manage to reproduce the problem with recent (at least two weeks old) system updates.
IIRC libc and libxcb are found among those updates, so the situation described above may indeed be fixed in that distro. Please test again.
Leaving the bug open for now.
Source Beta 33:
On 23 july 2009, on up-to-date Ubuntu 9.04 (with latest available libSDL), architecture amd64, the problem is still there.
libc6 is 2.9-4ubuntu6
libxcb is 1.1.93-0ubuntu3.1
Relying on "updated system" seems a bit optimistic.
A workaround would be welcome.
Notice: commenting (= removing from live code) the SDL_WM_SetCaption(f.str().c_str(), PACKAGE_NAME); line really improves issue with broken X11 connection which appears also randomly at the very start of a rendering. (about 113 X11 messages processed, then crash!)
May be the title of the window could be set at the window creation time (forget about the "Paused" tag) once and for all.
The title of the SDL preview window is temporarly disabled as of change #4889.
I just witnessed an apparently spontaneous lockup of POV-Ray while a preview window was not displayed (POV-Ray was started with the -D option), and with change #4889 included.
As it is the first time I ever witnessed such an effect, and I have just recently managed to compile POV-Ray with X-Window support enabled, I guess it's still the same issue.
Anniversary report: no lock seen since the removal of the title.
Using valgrind, there is still some wolf within the code...
14838
==14838== Use of uninitialised value of size 8
==14838== at 0x4E44CE7: ??? (in /usr/lib/libSDL-1.2.so.0.11.3)
==14838== by 0x4E44B29: ??? (in /usr/lib/libSDL-1.2.so.0.11.3)
==14838== by 0x4E5ADFB: SDL_LowerBlit (in /usr/lib/libSDL-1.2.so.0.11.3)
==14838== by 0x4E5B008: SDL_UpperBlit (in /usr/lib/libSDL-1.2.so.0.11.3)
==14838== by 0x40DED8: pov_frontend::UnixSDLDisplay::UpdateScreen(bool) (disp_sdl.cpp:578)
==14838== by 0x42AF74: main (unixconsole.cpp:571)
14838
==14838== Use of uninitialised value of size 8
==14838== at 0x4E44CEA: ??? (in /usr/lib/libSDL-1.2.so.0.11.3)
==14838== by 0x4E44B29: ??? (in /usr/lib/libSDL-1.2.so.0.11.3)
==14838== by 0x4E5ADFB: SDL_LowerBlit (in /usr/lib/libSDL-1.2.so.0.11.3)
==14838== by 0x4E5B008: SDL_UpperBlit (in /usr/lib/libSDL-1.2.so.0.11.3)
==14838== by 0x40DED8: pov_frontend::UnixSDLDisplay::UpdateScreen(bool) (disp_sdl.cpp:578)
==14838== by 0x42AF74: main (unixconsole.cpp:571)
14838
I Will try to run more options with valgrind to find a way to fix it (povray 3.7RC3)
Jérôme, what is the progress on this?
Since #4889, and nearly two years of usage, no more lock of the X11 window with SDL.
About the report of valgrind, I went no further.(valgrind has some limitation about shared memory and other communication, it cannot mark as initialised an area set by a separate process (and yet, it works)). As far as I'm concerned, running povray under valgrind currently (#5480!) only provides leaks reported in SDL; these leaks are not increased by animation (kind of fixed footprint), so I can live with them (the destruction of the process will recollect them, even if a cleaner exit from the SDL point of view might be better. Alas, I'm totally lost with SDL).
IMHO, if we keep #4889, this report can be closed.