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
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
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
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.
With core-dumped enable, the issue is pointed in the creator of PixelContainer.
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()!).
Thursday, 09 December 2010, 13:56 GMT
Reason for closing: Fixed
Additional comments about closing: Reported as fixed by OP