On 3/26/19 8:10 AM, clipka wrote:
> Am 26.03.2019 um 11:46 schrieb William F Pokorny:
> 
>> Quick additional question. Is it the --enable-debug configure flag 
>> that - normally - turns on the pov asserts? I've never verified this 
>> assumption of mine by creating a pov assert in the code I know should 
>> fail.
> 
> To be honest, I haven't a clue. I'm not sure what the `--enable-debug` 
> flag does exactly (it's some standard mechanism in the Automake tools), 
> nor whether and how assertions are enabled or disabled in Unix builds.
> 
> I'm pretty sure that `--enable-debug` does enable the creation of debug 
> information in the binaries, so that a debugging tool can correlate 
> binary code addresses with original source code lines, so that you can 
> e.g. set breakpoints and step through the code line by line with a 
> debugger. I also wouldn't be surprised if it turns off optimizations by 
> default, because those tend to re-order instructions and make a 
> line-by-line correlation impossible. Whether it does anything beyond 
> that I do not know. It might dictate whether `NDEBUG` is defined or not, 
> which would conceivably disable/enable assertions.

Back at it this morning.

First, flipping the file name compare so it's ahead of the file position 
compare (and assert) works fine too with all the test cases I have that 
fail.

Second, on enabling the POV_ASSERT source code mechanism, took the time 
to do some full compiles with a known fail assert of 1 == 0 and the 
short of it for *nix is doing something like:

./configure COMPILED_BY="wfp__POV_DEBUG" CXXFLAGS="-DPOV_DEBUG"

works. The -D<var> form on the define is added as a compiler flag to do 
the POV_DEBUG define, which, turns on the POV asserts that exist in the 
code (except I guess where not otherwise controlled or hard-set).

Lastly, on the --enable-debug flag, it is not today defining POV_DEBUG 
which is what turns on the POV_ASSERTs. Most of my actual debug compiles 
use a configure command like:

./configure COMPILED_BY="wfp" --disable-optimiz --disable-strip \ 
CXXFLAGS="-Og -ggdb fverbose-asm"

so --enable-debug isn't strictly needed for debugging though on line 
documentation I read just now indicates - by default anyway - it does 
something equivalent given certain arguments. Looks like you can select 
what sort of debugging gets turned on - and you can provide a second 
argument defining variables explicitly (ie POV_DEBUG) and there is the 
NDEBUG you mentioned (boost seems to use this some) getting set by 
default if the flag's argument turns debugging off (or the flag's not 
used but enabled?). What some documentation says only; Not sure what 
works or not for --enable-debug with our current set up without doing a 
bunch of compiles and tests. An investigation for another time. The flag 
doesn't control the POV_ASSERTs today via NDEBUG in any case - so at 
best it might provide another way to define POV_DEBUG using that second 
argument.

Bill P.

Post a reply to this message

On 3/28/19 6:49 AM, William F Pokorny wrote:
> On 3/26/19 8:10 AM, clipka wrote:
...
> 
> Second, on enabling the POV_ASSERT source code mechanism, took the time 
> to do some full compiles with a known fail assert of 1 == 0 and the 
> short of it for *nix is doing something like:
> 
> ./configure COMPILED_BY="wfp__POV_DEBUG" CXXFLAGS="-DPOV_DEBUG"
> 
> works. 
...
> 

With the thought I might help others doing debug by rambling more about 
my ignorance/learning while attempting to debug this issue...

Woke up this morning remembering seeing a core file when I did my 
POV_ASSERT(1 == 0) test with a compile where POV_DEBUG was really 
defined. This got me wondering why I didn't get a core file with initial 
failing code here given an assert ran and I did a debug compile. A core 
file would have have made it easy to look at the call stack with gdb.

Well, looking at the source code this morning it's because we have this 
set up today for the parser related asserts in ./parser/configparser.h :

#ifndef POV_PARSER_DEBUG
     #define POV_PARSER_DEBUG POV_DEBUG
#endif

...

#if POV_PARSER_DEBUG
     #define POV_PARSER_ASSERT(expr) POV_ASSERT_HARD(expr)
#else
     #define POV_PARSER_ASSERT(expr) POV_ASSERT_SOFT(expr)
                                  // POV_ASSERT_DISABLE(expr)
#endif

I wasn't previously getting POV_DEBUG set so I was getting a soft assert 
which parse.cpp catches triggering a more graceful - but less 
informative (no core file) - program exit. Trying my debug compile again 
just now with POV_DEBUG set, I do get a core file and gdb gives me :

     ...
#4  0x000055a82da4b703 in pov_parser::LexemePosition::operator==
     o=...) at parser/parsertypes.cpp:62
#5  0x000055a82da40420 in pov_parser::Parser::IsEndOfInvokedMacro
     at parser/parser_tokenizer.cpp:964
#6  0x000055a82da44dcd in pov_parser::Parser::Get_Token
     at parser/parser_tokenizer.cpp:289
#7  0x000055a82da05cf7 in pov_parser::Parser::Parse_Frame
     at parser/parser.cpp:6559
#8  0x000055a82da06591 in pov_parser::Parser::Run
     at parser/parser.cpp:242
#9  0x000055a82d9cb3ef in pov::ParserTask::Run
     at backend/control/parsertask.cpp:81
...

Today, I'd find my way to IsEndOfInvokedMacro in less than an hour 
instead of the full day it took me to trace top down - so to speak.

The lessons I learned: Get POV_DEBUG set in your compile while debugging 
any issue. If still no core file generated and tangled in a POV-Ray code 
assert, be sure you're getting a hard assert and not a soft one. I 
didn't know we had 'soft' POV_ASSERT* version until today.

Bill P.

Post a reply to this message

On 3/26/19 6:46 AM, William F Pokorny wrote:
> On 3/25/19 7:41 PM, clipka wrote:
>> Am 25.03.2019 um 23:55 schrieb clipka:
>>
>>> If `Cond_Stack.back().PMac->endPosition == CurrentFilePosition()` 
>>> throws an exception, it means either of two things:
>>>
>>> (A) The positions compared are from two different files, which means 
>>> the calling code has failed to check whether it is even in the right 
>>> file.
>>>
>>> (B) The line/column tracking is buggy, and yields different positions 
>>> in different situations.
>>
>>
>> Well, looking at the code of `IsEndOfInvokedMacro()` again, it 
>> _strongly_ reeks of scenario (A):
>>
>>      return (Cond_Stack.back().PMac->endPosition ==
>>                  CurrentFilePosition()) &&
>>             (Cond_Stack.back().PMac->source.fileName ==
>>                  mTokenizer.GetInputStreamName());
>>
>> should probably be swapped around, like so:
>>
>>      return (Cond_Stack.back().PMac->source.fileName ==
>>                  mTokenizer.GetInputStreamName()) &&
>>             (Cond_Stack.back().PMac->endPosition ==
>>                  CurrentFilePosition());
>>
>> so that the `LexemePosition` comparison operator is only invoked if 
>> the file names match.
>>
...

Documenting that Christoph's suggested code change up top, which fixed 
the bug with Warren's original test case and related test cases I 
created, is NOT in the v38 master branch as of commit 74b3ebe0 (March 8, 
2019).

Christoph - I think - planned to fix the core issue, but this has not 
happened as of today so the bug persists.

Bill P.

Post a reply to this message