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.

Attached to Project: POV-Ray
Opened by Grimbert Jérôme - 2010-09-30
Last edited by Christoph Lipka - 2010-12-09

FS#167 - Core dump when rendering to huge dimensions

From post in povray.general (circa 29 september 2010: “Maximum Resolution of Renders?”)

The ultimate goal would be a 41000×41000 image. However each time I have attempted to render that Pov-Ray has crashed on
me. Even when using a single, simple test object (a plain white sphere that
should use a single pixel). So I think this is running into a program limitation
at present.

It won’t be for the faint hearted: a 30500 x 30500 does still produces the bug, but you’d better have 24 GB of true ram to test it.
(it’s a render of a few “real” minutes if you do not swap, for any very quick scene (a 305 x 305 in 0.117s moved to 220s for 30500×30500 on my system when corrected))

With core-dumped enable, the issue is pointed in the creator of PixelContainer.
The problem is due to the resize() parameter: despite the parameter being a size_t (8 bytes long on 64bits), the computation ( h * w * 5 ) use unsigned int for h & w (and signed int for 5).

As a consequence, the value of resize is computed as a signed int... havoc might happen when the signed bit (#31) is propagated to the #63 to #32 of size_t... vector does not enjoy a negative value for resize (and destroy itself: no iterator on coming soon call! hence the crash when the values in the vector are to be initialised)

30500²: (in hex)

1 15 3C 71 50 floats
4 54 F1 C5 40 bytes

Basic solution: promote the 5 to an unsigned long, forcing the computation to happen on unsigned long, avoiding promotion of silly sign-bit, and keeping the resize’s value as a good number.

aka: resize( w * h * 5) becomes resize ( w * h * 5ul )

This solution has been tested and seems fine (it’s just that in base/image/image.cpp, there is a lot of resize()!).
For all resize(), the “ul” must be added. (and that means also that resize( w * h ) must be rewritten as ( w * h * 1ul ). )

Closed by  Christoph Lipka
Thursday, 09 December 2010, 13:56 GMT
Reason for closing:  Fixed
Additional comments about closing:  

Reported as fixed by OP

Grimbert Jérôme commented on Tuesday, 26 October 2010, 21:45 GMT

Should be corrected with change #5166 (#5164)

Christoph Lipka commented on Saturday, 30 October 2010, 12:58 GMT

For even cleaner code, "size_t(5)" might be used.

Grimbert Jérôme commented on Thursday, 09 December 2010, 12:51 GMT

Beta 40 (take 2), linux from source: no problem with huge dimensions anymore.
(-W51200 -H38400 (aka a 640x480 zoomed x40 ))


Available keyboard shortcuts


Task Details

Task Editing