Mismatch between natural and non-natural types

[pakin]

In the following code,

Code: Select all

startshape begin

myfunc(thing) = thing

shape begin {
  SQUARE [ h myfunc(1) sat 1 b 1 ]
}

I'm receiving an error message that I don't understand:

Error in example.cfdg at line 3 - Mismatch between declared natural and defined not-natural type of user function

Is this somehow related to a restriction to preserve context-free purity?

Thanks,
— Scott

[MtnViewJohn]

You are the second person to report this behavior. I cannot reproduce it on Windows, Linux, or Mac. Could it be a 32/64-bit issue? What OS and CPU are you running on?

[pakin]

What OS and CPU are you running on?

32-bit Debian Linux on x86, GCC 4.4.5.

[pakin]

I just tried running Valgrind on cfdg. Perhaps the source of the problem lies in the following use of uninitialized variables?

Code: Select all

$ valgrind cfdg -s 512 example.cfdg -o example.png
==8466== Memcheck, a memory error detector
==8466== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==8466== Using Valgrind-3.6.0.SVN-Debian and LibVEX; rerun with -h for copyright info
==8466== Command: cfdg -s 512 example.cfdg -o example.png
==8466==
Reading rules file example.cfdg
Restarting as a version 3 design
==8466== Conditional jump or move depends on uninitialised value(s)
==8466==    at 0x8063495: Builder::push_paramDecls(std::string const&, yy::location const&, std::string const&) (in /usr/local/stow/ContextFree3.0-v17/bin/cfdg)
==8466==    by 0x80B50EE: yy::CfdgParser::parse() (in /usr/local/stow/ContextFree3.0-v17/bin/cfdg)
==8466==    by 0x804CCB7: CFDG::ParseFile(char const*, AbstractSystem*, int) (in /usr/local/stow/ContextFree3.0-v17/bin/cfdg)
==8466==    by 0x80A78E3: main (in /usr/local/stow/ContextFree3.0-v17/bin/cfdg)
==8466==
Compiling 2nd phase
Error in example.cfdg at line 3 - Mismatch between declared natural and defined not-natural type of user function
==8466== Conditional jump or move depends on uninitialised value(s)
==8466==    at 0x804E090: Rand64::xorString(char const*, int&) (in /usr/local/stow/ContextFree3.0-v17/bin/cfdg)
==8466==    by 0x8087A1A: AST::ASTmodification::addEntropy(std::string const&) (in /usr/local/stow/ContextFree3.0-v17/bin/cfdg)
==8466==    by 0x8092432: AST::ASTreplacement::ASTreplacement(AST::ASTruleSpecifier&, std::string const&, std::auto_ptr<AST::ASTmodification>, yy::location const&, AST::ASTreplacement::repElemListEnum) (in /usr/local/stow/ContextFree3.0-v17/bin/cfdg)
==8466==    by 0x8063C23: Builder::MakeElement(std::string const&, std::auto_ptr<AST::ASTmodification>, std::auto_ptr<AST::ASTexpression>, yy::location const&, bool) (in /usr/local/stow/ContextFree3.0-v17/bin/cfdg)
==8466==    by 0x80B2888: yy::CfdgParser::parse() (in /usr/local/stow/ContextFree3.0-v17/bin/cfdg)
==8466==    by 0x804CCB7: CFDG::ParseFile(char const*, AbstractSystem*, int) (in /usr/local/stow/ContextFree3.0-v17/bin/cfdg)
==8466==    by 0x80A78E3: main (in /usr/local/stow/ContextFree3.0-v17/bin/cfdg)
==8466==
==8466==
==8466== HEAP SUMMARY:
==8466==     in use at exit: 5,852 bytes in 19 blocks
==8466==   total heap usage: 609 allocs, 590 frees, 223,109 bytes allocated
==8466==
==8466== LEAK SUMMARY:
==8466==    definitely lost: 0 bytes in 0 blocks
==8466==    indirectly lost: 0 bytes in 0 blocks
==8466==      possibly lost: 0 bytes in 0 blocks
==8466==    still reachable: 5,852 bytes in 19 blocks
==8466==         suppressed: 0 bytes in 0 blocks
==8466== Rerun with --leak-check=full to see details of leaked memory
==8466==
==8466== For counts of detected and suppressed errors, rerun with: -v
==8466== Use --track-origins=yes to see where uninitialised values come from
==8466== ERROR SUMMARY: 7 errors from 2 contexts (suppressed: 91 from 8)

[MtnViewJohn]

That was an interesting uninitialized data bug. It manifests itself only in 32-bit.

Alas, I cannot get my Ubuntu or Debian VMs to build in 32-bit. Would you pull the latest changes from https://code.google.com/p/context-free/ and try valgrind again?

[pakin]

Would you pull the latest changes from https://code.google.com/p/context-free/ and try valgrind again?

Whatever you did fixed the problem!

Code: Select all

$ valgrind ./cfdg example.cfdg -o example.png
==3877== Memcheck, a memory error detector
==3877== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==3877== Using Valgrind-3.6.0.SVN-Debian and LibVEX; rerun with -h for copyright info
==3877== Command: ./cfdg example.cfdg -o example.png
==3877== 
Reading rules file example.cfdg                            
Restarting as a version 3 design                            
Compiling 2nd phase                            
1 rules loaded                            
Generating 8bit color PNG image, variation BEUMJW...
500w x 500h pixel image.
Generating...

Rendering...

Writing 500w x 500h pixel image...
    1 shapes                                    
DONE!
The output file name is example.png
==3877== 
==3877== HEAP SUMMARY:
==3877==     in use at exit: 6,308 bytes in 22 blocks
==3877==   total heap usage: 701 allocs, 679 frees, 1,440,121 bytes allocated
==3877== 
==3877== LEAK SUMMARY:
==3877==    definitely lost: 288 bytes in 1 blocks
==3877==    indirectly lost: 168 bytes in 2 blocks
==3877==      possibly lost: 0 bytes in 0 blocks
==3877==    still reachable: 5,852 bytes in 19 blocks
==3877==         suppressed: 0 bytes in 0 blocks
==3877== Rerun with --leak-check=full to see details of leaked memory
==3877== 
==3877== For counts of detected and suppressed errors, rerun with: -v
==3877== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 91 from 8)

Thanks,
— Scott

[MtnViewJohn]

Yay. When I added the isNatural flag to the parameter class I forgot to initialize it in the constructor. I have no idea why it initialized properly anyway with the 64-bit builds but not the 32-bit builds.

I did manage to get valgrind to run with the 64-bit build after I turned off SSE4 instructions. The small memory leak is inside of libpng12, so I am not worried about it. I will run valgrind on some other cfdg files to see if there are memory leaks in the rendering engine or more uninitialized memory errors.