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 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.
Thursday, 21 June 2012, 23:14 GMT
Reason for closing: Fixed
Additional comments about closing:
no news, so I guess the fix was
effective
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 ?? ()
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.
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 ?)
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).
should be fixed with #5465 (tested ok with both samples scenes)
pulled your fix ... confirmed. Excellent detective work