POV-Ray

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.

Tasklist

FS#145 - Stack trace report on error

Attached to Project: POV-Ray
Opened by Mike H (SharkD) - Sunday, 20 June 2010, 19:23 GMT
Last edited by William F Pokorny (wfpokorny) - Saturday, 21 January 2017, 15:45 GMT
Task Type Feature Request
Category Backend → Parser/SDL
Status Tracked on GitHub
Assigned To Thorsten Fröhlich (thorsten)
Operating System All
Severity Low
Priority Normal
Reported Version 3.70 beta 37a
Due in Version Undecided
Due Date Undecided
Percent Complete 10%
Votes 0
Private No

Details

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.

This task depends upon

Comment by Chris Cason (chrisc) - 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.

Comment by Mike H (SharkD) - 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)
  them
#end

#debug this_and_that("those")

The first case works properly.

#macro this_and_that(them)
  them
#end

#debug this_and_that(4)

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

#macro this_and_that(them)
  them
#end

#debug this_and_that()

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

Comment by Thorsten Fröhlich (thorsten) - Friday, 02 July 2010, 05:06 GMT

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

Comment by Grimbert Jérôme (Le_Forgeron) - Saturday, 21 May 2011, 16:52 GMT

Any progress ? (just wondering)

Comment by Thorsten Fröhlich (thorsten) - 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.

Comment by William F Pokorny (wfpokorny) - Saturday, 21 January 2017, 15:45 GMT
  • Field changed: Status (Assigned → Tracked on GitHub)
  • Field changed: Due in Version (3.70 release → Undecided)

Now tracked on github as issue #203.

Loading...