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 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.
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.
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) them #end #debug this_and_that("those")The first case works properly.
In the second case the error is reported as being within the macro.
But in the third case the parser knows to go to the calling block instead.
I have a fairly concrete idea how to implement this and will take a look.
Any progress ? (just wondering)
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.
Now tracked on github as issue #203.