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.


FS#167 - Core dump when rendering to huge dimensions

Attached to Project: POV-Ray
Opened by Grimbert Jérôme (Le_Forgeron) - Thursday, 30 September 2010, 18:01 GMT
Last edited by Christoph Lipka (clipka) - Thursday, 09 December 2010, 13:56 GMT
Task Type Definite Bug
Category Backend → Other
Status Closed
Assigned To No-one
Operating System All
Severity Medium
Priority Normal
Reported Version 3.70 beta 38
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No


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 ). )

This task depends upon

Closed by  Christoph Lipka (clipka)
Thursday, 09 December 2010, 13:56 GMT
Reason for closing:  Fixed
Additional comments about closing:  Reported as fixed by OP
Comment by Grimbert Jérôme (Le_Forgeron) - Tuesday, 26 October 2010, 21:45 GMT

Should be corrected with change #5166 (#5164)

Comment by Christoph Lipka (clipka) - Saturday, 30 October 2010, 12:58 GMT

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

Comment by Grimbert Jérôme (Le_Forgeron) - 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 ))