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 Mike H - 2010-06-20
Last edited by William F Pokorny - 2017-01-21

FS#145 - Stack trace report on error

In other languages if you encounter an error you’ll often be presented with a stack trace showing not only the file and line number the error occurred at, but also any calling functions and _their_ calling functions and so on.

Currently, Povray reports the line number of the error as well as the last five or so lines prior to the error. This is usually OK in simple scenes, but breaks down when you start making use of inclusion and macros.

Let’s say you have a macro located in a file that you then include in your scene. Within your scene you call the macro multiple times, passing input to it. However, by accident you pass _invalid_ input to the macro at some point, resulting in an error when parsing. In this case Povray will report the error as belonging to the macro whereas the actual bug exists in the calling code. If the macro is called more than once in your scene it can be difficult to figure out _which_ instance is the one supplying the bad input.

Not sure how much of this is achievable in Povray.

Chris Cason commented on Monday, 21 June 2010, 19:16 GMT

It would be possible using existing code to trace the inclusions of files via #debug statements, which could be conditionally enabled if you are trying to trace down a problem. However that isn't very convenient.

The current POV-Ray code does have available the tree of included files, which I suppose we could print. Note that a true stack trace as you are describing isn't really the right thing because macros aren't functions. The include tree (which would include the line the file was included from) should be sufficient. I'll keep this in mind, but no guarantee it'll be added.

Mike H commented on Monday, 28 June 2010, 22:20 GMT

Is it possible to track the position where the macro was called from? Or are macros expanded at a different stage than they are evaluated at?

Consider the following case:

#macro this_and_that(them)

#debug this_and_that("those")

The first case works properly.

#macro this_and_that(them)

#debug this_and_that(4)

In the second case the error is reported as being within the macro.

#macro this_and_that(them)

#debug this_and_that()

But in the third case the parser knows to go to the calling block instead.

Thorsten Fröhlich commented on Friday, 02 July 2010, 05:06 GMT

I have a fairly concrete idea how to implement this and will take a look.

Grimbert Jérôme commented on Saturday, 21 May 2011, 16:52 GMT

Any progress ? (just wondering)

Thorsten Fröhlich commented on Wednesday, 27 June 2012, 12:57 GMT

No progress in the core code, but I do have an on the fly parser for the preprocessor in my branch of the smp tree in Perforce. Currently its used for context sensitive syntax-highlighting in my Qt-based frontend development. For the backend I have a somewhat different idea though.

William F Pokorny commented on Saturday, 21 January 2017, 15:45 GMT

Now tracked on github as issue #203.


Available keyboard shortcuts


Task Details

Task Editing