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 Jim Holsenback - 2011-07-27
Last edited by Christoph Lipka - 2012-06-21

FS#215 - Double Error Reporting

Certain types of errors are being reported twice. For example:

Parse Error: Expected ‘numeric expression’, } found instead
Parse Error: Expected ‘object’, undeclared identifier ‘foo’

The first error was a user typo when not enough parameters were specified, and the later when calling a yet to be declared object.

During investigation it was also discovered that improperly formed scale statements also produced the double error report: <scale 1,0.5,1>

Verified on linux and windows platforms.

Closed by  Christoph Lipka
Thursday, 21 June 2012, 23:14 GMT
Reason for closing:  Fixed
Additional comments about closing:  

no news, so I guess the fix was effective

Grimbert Jérôme commented on Sunday, 07 August 2011, 12:28 GMT

It's a double call to vfeParserMesageHandler::Error (vfe/vfe.cpp), which outputs the formatted string.

The calls which output twice the line have identical stacks, which means it might be due to a double inherited sub-object.

#0 vfe::vfeParserMessageHandler::Error (this=0x97a180, Con=0x971f90, Obj=<value optimized out>, conout=true) at vfe.cpp:400
#1 0x00000000005d4318 in pov_frontend::ParserMessageHandler::HandleMessage (this=0x97a180, sd=..., ident=1165128262, obj=...) at parsermessagehandler.cpp:179
#2 0x000000000044fedb in pov_frontend::RenderFrontend<vfe::vfeParserMessageHandler, pov_frontend::FileMessageHandler, vfe::vfeRenderMessageHandler, pov_frontend::ImageMessageHandler>::HandleParserMessage (this=<value optimized out>, sid=..., ident=<value optimized out>, msg=<value optimized out>) at ../source/frontend/renderfrontend.h:822
#3 0x00000000005d5a63 in pov_frontend::RenderFrontendBase::HandleMessage (this=0x96ae08, msg=..., result=...) at renderfrontend.cpp:632
#4 0x000000000062cfee in POVMS_MessageReceiver::ReceiveHandler (msg=0x7ffff1773c00, result=0x7ffff1773bf0, mode=1, privatedataptr=<value optimized out>) at povmscpp.cpp:1773
#5 0x000000000063c98b in POVMS_Receive (contextref=0x95fe10, msg=0x7ffff1773c00, result=0x7ffff1773bf0, mode=1) at povms.cpp:961
#6 0x000000000063f553 in POVMS_ProcessMessages (contextref=0x95fe10, blocking=<value optimized out>, yielding=<value optimized out>) at povms.cpp:691
#7 0x0000000000421f26 in vfe::vfeSession::WorkerThread (this=0x95d510) at vfesession.cpp:667
#8 0x00007ffff59d016e in thread_proxy () from /usr/lib/libboost_thread.so.1.42.0
#9 0x00007ffff500bd8c in start_thread (arg=0x7ffff1774700) at pthread_create.c:304
#10 0x00007ffff4d5704d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#11 0x0000000000000000 in ?? ()

Grimbert Jérôme commented on Saturday, 13 August 2011, 11:39 GMT

I'm wrong (again ? no, as usual!)

Adding a trace in POVMS_ProcessMessages (with a suspending sleep(1)), the message is received twice by the thread.

Information Output Options
  All Streams to console..........On 
  Debug Stream to console.........On 
  Fatal Stream to console.........On 
  Render Stream to console........On 
  Statistics Stream to console....On 
  Warning Stream to console.......On 
==== [Parsing...] ==========================================================
New message
New message
New message
File 'a.pov' line 2: Parse Error: Expected 'numeric expression', } found instead
New message
File 'a.pov' line 2: Parse Error: Expected 'numeric expression', } found instead
Fatal error in parser: Cannot parse input.
New message
New message
Render failed

So, now, I should redirect my focus on the parsing thread, not the vfeSession one.
(who said when the bug report uses its finger to show the moon, the idiot looks at the finger ?)

Grimbert Jérôme commented on Saturday, 13 August 2011, 12:48 GMT

I think I found something... on a parallel branch.
Revision 5161 was ok.
Revision 5182 get the reported bug.

In parse.cpp, the exception is "now" trapped in a try/catch.
And an Error is re-created, using e.what member (so duplication occurs).

Grimbert Jérôme commented on Saturday, 13 August 2011, 13:50 GMT

should be fixed with #5465 (tested ok with both samples scenes)

Jim Holsenback commented on Saturday, 13 August 2011, 17:16 GMT

pulled your fix ... confirmed. Excellent detective work :-)


Available keyboard shortcuts


Task Details

Task Editing