I'm going to fix some bugs and release a new version in a couple of weeks. Please file a bug and include the XML zipped. Also a small test case is good; but the XML in a zip file is critical.
thanks,
lee
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The attributes-vs-elements/text-node thing is a religious argument.
Its perfectly legitimate to have an attribute with a "/" in it - like '<a href="/foo/bar">' etc.
I've known some xml designers that use the text nodes *strictly* only for text (like descriptions of test cases, poetry, etc) and use attributes entirely for data like the OP did.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I guess the question isn't one of aesthetics but of functionality: does TinyXML choke when you put slashes in quoted text? It sure crashes a lot for me, and I can't see anything else wrong with the XML itself. :(
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If I take the slashes out, the program won't run because it needs to know the directories.. it isn't a trivial set of data that I can simply change the paths to.
I'm trying to test by putting the file paths into a <file>path/goes/here</file> element, but I can't figure out how to read the text from the element. Docs are sorely lacking, I'm afraid, and I've been digging through the API until I have a headache.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thats understandable - but you don't have to run the whole program. You can put breakpoints in just to see if its reading it correctly.
Or better, write a tiny program that loads the data file and put a whole lot of asserts in that it read it correctly, then read in a loop of 10,000. This will show up the bug quickly instead of this time consuming approach which also might be masking problems somewhere else in your code.
Text element: You want the first child of the element which is a text node, then get its value.
The code below is from my set of private CppUnit tests. <rant>CppUnit style tests are cool for a number of reasons. They start small (not shown) and build up - AND they show how to use features bit by bit AND they test stuff ;). I pitched the idea for TinyXml but didn't sell it ;)</rant>
The code shows how to get the value of a text node at the end. SF screws up the format but hopefully its readable.
It looks like the cause is from having slashes in an attribute, because I tested with a subset of the data and have yet to crash it. Not difinitive, but definitely a huge difference. I guess I'll convert all my xml files to not have file paths in the attributes.
*sigh of relief*
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Phooey. After some more testing, I did manage to crash it, even using: <file>path/to/file</file> syntax. I guess there's a general bug with slashes, but it seems a lot worse inside attributes.
Is there any hope of having this bug fixed soon? :) I don't want to switch libraries or do some other hard core change when I'm this close to the finish line....
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sorry to spam this forum, but I just noticed that the error was "Error reading attributes" which means that it didn't have anything to do with slashes because the only other attributes in the file in question were integer values.
???
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You're welcome for the help. Hope you can nail it soon :)
In my experience, 9 times out of 10 when someone thinks its a bug in the library its a bug in their code or their data. It definitely *could* be a bug and I'm not casting bad light on your efforts, its just been my experience (I've sworn there are compiler bugs and everything, only to find I had a #define or whatever).
The good news is that the solution is the same in both cases: write a really small program that reproduces the problem. The code I posted before is 99% of the way. I bet you there's something else going on. Frankly I'm fairly sure its nothing to do with slashes in the xml, but I'm prepared to 'eat my hat' if I'm wrong.
If you write the little proof program, one of two things will happen.
Either there will be no bug at all in your standalone program, proving that its something to do with your use of it or the data in the bigger app.
Or the program will prove once and for all that there is a bug in the library. In this case, you'll be able to get a really fast solution to your problem by debugging it and finding exactly where the bug is ;)
HTH
Ellers
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I did an isolated test case, and it didn't fail after 300,000 iterations, but it also wasn't comprehensive in that it was only one section where the program reads xml data.
I added debug output to the full program, and the failures so far all come when trying to read a 'file' element or attribute, which means there are slashes involved. I get either "Failed to read Element" or "Error reading Attributes" at the 'file' element/attribute.
Why this would crash sometimes, I have no idea. :( Even if it is my fault, although I can't figure out why it would happen and especially why it is not consistently crashing. I turned off optimizations and it is still happening, though much less frequently since I moved the file paths out of the atrributes and into a separate <file></file> element.
Just dumping thoughts hoping somebody will have an idea. :)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This time I managed to crash TinyXML and got a little stack trace:
EXCEPTION_ACCESS_VIOLATION, The thread attempted to read from or write to a virtual address for which it does not have the appropriate access.
-- Begin stack trace --
Nr Flags PC Return Frame Stack
0 .V 0046eb2a 20746365 090e0ae7 00000000 TiXmlBase::SkipWhiteSpace +122 bytes
Sig: TiXmlBase::SkipWhiteSpace
Decl: TiXmlBase::SkipWhiteSpace
...which is line 307...
while ( *p )
...in this block of code from "tinyxmlparser.cpp"...
const char* TiXmlBase::SkipWhiteSpace( const char* p, TiXmlEncoding encoding )
{
if ( !p || !*p )
{
return 0;
}
if ( encoding == TIXML_ENCODING_UTF8 )
{
while ( *p )
{
// Skip the stupid Microsoft UTF-8 Byte order marks
if ( *(p+0)==(char) 0xef
&& *(p+1)==(char) 0xbb
&& *(p+2)==(char) 0xbf )
{
p += 3;
continue;
}
else if(*(p+0)==(char) 0xef
...etc
Maybe that is a clue?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If the program is fairly small and self contained, can you post it (or mail a zip archive to me at ellers at ellerton dot net) and I'll try to have a go over the weekend, if that would be useful to you.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It crashed again in the whitespace function. Looks like maybe something gets corrupted in my code. I'm loading the xml file into memory and then parsing with:
Thanks very much for the generous offer, but it's a pretty big application and has a few other libs for dependencies, etc. I don't want to submit you to that kind of torture. :)
But after much time in the debugger, I am fairly certain that you were right--it's my code. I think there's a buffer overrun somewhere, which is invalidating either the pointer to the xml data or the data itself after it's in memory. This explains the random nature of it. It might also explain why it only happens in release mode: buffer checks are disabled for speed. Hopefully I'll uncover the problem soon....
Thanks a lot for your time and good will, Ellers.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This is a very long - but interesting - thread. I'm glad you are making some progress JM.
On the memory checker, I always check TinyXml before release with Valgrind - I'm a huge fan. Great memory checking code. The only downside is that it is linux only, I'd love to check agains the Windows libraries too.
Still pounding on this problem, and I noticed there's a new version of TinyXML up, so I'll compile that and see what happens.
The odd thing is that this problem doesn't happen in debug builds (or if I run a release build with the debugger via Visual Studio). I'm suspecting memory gets trampled, and maybe since debug mode adds padding to allocations (to test for overruns) it doesn't cause trouble. But I can't figure out much beyond that yet.
The other interesting note is that the app crashes every time in some relation to reading xml (usually SkipWhiteSpace or something close), so I don't know if this is my code or not. I'm loading a lot more data than just xml and none of it has caused a problem, so I'll keep digging.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I get seemingly random read errors with the following (and similar) XML:
<?xml version="1.0"?>
<sprite z_index="100">
<animation name="idle">
<frame file="dualists/images/brick_basic.png">
<tile width="16" height="32" x="3" y="0" />
</frame>
</animation>
</sprite>
Can anyone please tell me why? Sometimes it reads fine, sometimes it chokes on Attributes. VC7.1, Windows XP, compiled without STL, release mode.
I'm going to fix some bugs and release a new version in a couple of weeks. Please file a bug and include the XML zipped. Also a small test case is good; but the XML in a zip file is critical.
thanks,
lee
I'm going to guess that the slashes in your directory path might be causing a problem especiialy since they are in the attribute.
you might try
<frame>
<file>dualist/images/brick_basic.png</file>
<tile>
<width>16</width>
<height>32</height>
<x>3</x>
<y>0</y>
</tile>
</frame>
at least this is how i would construct the xml.
Attributes should be left to for such things as naming an item, or specifiy the data needs to be interpreted a particular way.
The attributes-vs-elements/text-node thing is a religious argument.
Its perfectly legitimate to have an attribute with a "/" in it - like '<a href="/foo/bar">' etc.
I've known some xml designers that use the text nodes *strictly* only for text (like descriptions of test cases, poetry, etc) and use attributes entirely for data like the OP did.
I guess the question isn't one of aesthetics but of functionality: does TinyXML choke when you put slashes in quoted text? It sure crashes a lot for me, and I can't see anything else wrong with the XML itself. :(
If you take the slashes out of your input does your build of TinyXML work consistently?
If I take the slashes out, the program won't run because it needs to know the directories.. it isn't a trivial set of data that I can simply change the paths to.
I'm trying to test by putting the file paths into a <file>path/goes/here</file> element, but I can't figure out how to read the text from the element. Docs are sorely lacking, I'm afraid, and I've been digging through the API until I have a headache.
Thats understandable - but you don't have to run the whole program. You can put breakpoints in just to see if its reading it correctly.
Or better, write a tiny program that loads the data file and put a whole lot of asserts in that it read it correctly, then read in a loop of 10,000. This will show up the bug quickly instead of this time consuming approach which also might be masking problems somewhere else in your code.
Text element: You want the first child of the element which is a text node, then get its value.
The code below is from my set of private CppUnit tests. <rant>CppUnit style tests are cool for a number of reasons. They start small (not shown) and build up - AND they show how to use features bit by bit AND they test stuff ;). I pitched the idea for TinyXml but didn't sell it ;)</rant>
The code shows how to get the value of a text node at the end. SF screws up the format but hopefully its readable.
void BasicParseTests::testSimpleXML_2( void )
{
const char* xml = "<simple_node attrib=\"attrib_value\">Bogus Content</simple_node>";
TiXmlDocument doc( NO_FILENAME );
doc.Parse( xml );
CPPUNIT_ASSERT( !doc.Error());
TiXmlNode* node = 0;
TiXmlElement* element = 0;
TiXmlAttribute* attrib = 0;
element = doc.RootElement( );
CPPUNIT_ASSERT( 0 != element );
// by definition, root element is same as documents first child element
CPPUNIT_ASSERT_EQUAL( element, doc.FirstChildElement());
node = doc.FirstChild( "simple_node" );
CPPUNIT_ASSERT( 0 != node );
CPPUNIT_ASSERT_EQUAL( element, node->ToElement( ));
// make sure the name is what we expect
CPPUNIT_ASSERT_CSTR_EQUAL( "simple_node", element->Value( ));
// check siblings
CPPUNIT_ASSERT( 0 == element->NextSibling( ));
// check attributes
attrib = element->FirstAttribute( );
CPPUNIT_ASSERT( 0 != attrib );
CPPUNIT_ASSERT_CSTR_EQUAL( "attrib", attrib->Name( ));
CPPUNIT_ASSERT_CSTR_EQUAL( "attrib_value", attrib->Value( ));
attrib = attrib->Next( );
CPPUNIT_ASSERT( 0 == attrib );
// process child node
node = element->FirstChild( );
CPPUNIT_ASSERT( 0 != node);
CPPUNIT_ASSERT_EQUAL( (int)TiXmlNode::TEXT, node->Type( ));
CPPUNIT_ASSERT( 0 == node->ToComment( ));
CPPUNIT_ASSERT( 0 == node->ToDeclaration( ));
CPPUNIT_ASSERT( 0 == node->ToDocument( ));
CPPUNIT_ASSERT( 0 == node->ToElement( ));
CPPUNIT_ASSERT( 0 != node->ToText( ));
TiXmlText* text = node->ToText( );
CPPUNIT_ASSERT( 0 != text );
CPPUNIT_ASSERT_CSTR_EQUAL( "Bogus Content", text->Value( ));
}
Ok, right after posting I found the Value() method in the Node class. Doh.
It looks like the cause is from having slashes in an attribute, because I tested with a subset of the data and have yet to crash it. Not difinitive, but definitely a huge difference. I guess I'll convert all my xml files to not have file paths in the attributes.
*sigh of relief*
Ellers: big thanks for your replies and time. I appreciate it!
Phooey. After some more testing, I did manage to crash it, even using: <file>path/to/file</file> syntax. I guess there's a general bug with slashes, but it seems a lot worse inside attributes.
Is there any hope of having this bug fixed soon? :) I don't want to switch libraries or do some other hard core change when I'm this close to the finish line....
Sorry to spam this forum, but I just noticed that the error was "Error reading attributes" which means that it didn't have anything to do with slashes because the only other attributes in the file in question were integer values.
???
You're welcome for the help. Hope you can nail it soon :)
In my experience, 9 times out of 10 when someone thinks its a bug in the library its a bug in their code or their data. It definitely *could* be a bug and I'm not casting bad light on your efforts, its just been my experience (I've sworn there are compiler bugs and everything, only to find I had a #define or whatever).
The good news is that the solution is the same in both cases: write a really small program that reproduces the problem. The code I posted before is 99% of the way. I bet you there's something else going on. Frankly I'm fairly sure its nothing to do with slashes in the xml, but I'm prepared to 'eat my hat' if I'm wrong.
If you write the little proof program, one of two things will happen.
Either there will be no bug at all in your standalone program, proving that its something to do with your use of it or the data in the bigger app.
Or the program will prove once and for all that there is a bug in the library. In this case, you'll be able to get a really fast solution to your problem by debugging it and finding exactly where the bug is ;)
HTH
Ellers
I'll write a small test app like you suggested. It probably is something in my code, but it's very subtle whatever it is.
Would some optimization setting cause this? It only happens with release builds. It's never done it with debug builds.
I did an isolated test case, and it didn't fail after 300,000 iterations, but it also wasn't comprehensive in that it was only one section where the program reads xml data.
I added debug output to the full program, and the failures so far all come when trying to read a 'file' element or attribute, which means there are slashes involved. I get either "Failed to read Element" or "Error reading Attributes" at the 'file' element/attribute.
Why this would crash sometimes, I have no idea. :( Even if it is my fault, although I can't figure out why it would happen and especially why it is not consistently crashing. I turned off optimizations and it is still happening, though much less frequently since I moved the file paths out of the atrributes and into a separate <file></file> element.
Just dumping thoughts hoping somebody will have an idea. :)
This time I managed to crash TinyXML and got a little stack trace:
EXCEPTION_ACCESS_VIOLATION, The thread attempted to read from or write to a virtual address for which it does not have the appropriate access.
-- Begin stack trace --
Nr Flags PC Return Frame Stack
0 .V 0046eb2a 20746365 090e0ae7 00000000 TiXmlBase::SkipWhiteSpace +122 bytes
Sig: TiXmlBase::SkipWhiteSpace
Decl: TiXmlBase::SkipWhiteSpace
...which is line 307...
while ( *p )
...in this block of code from "tinyxmlparser.cpp"...
const char* TiXmlBase::SkipWhiteSpace( const char* p, TiXmlEncoding encoding )
{
if ( !p || !*p )
{
return 0;
}
if ( encoding == TIXML_ENCODING_UTF8 )
{
while ( *p )
{
// Skip the stupid Microsoft UTF-8 Byte order marks
if ( *(p+0)==(char) 0xef
&& *(p+1)==(char) 0xbb
&& *(p+2)==(char) 0xbf )
{
p += 3;
continue;
}
else if(*(p+0)==(char) 0xef
...etc
Maybe that is a clue?
If the program is fairly small and self contained, can you post it (or mail a zip archive to me at ellers at ellerton dot net) and I'll try to have a go over the weekend, if that would be useful to you.
It crashed again in the whitespace function. Looks like maybe something gets corrupted in my code. I'm loading the xml file into memory and then parsing with:
TiXmlDocument xmlDoc.Parse( ptrToFile, 0, TIXML_ENCODING_UTF8 );
The pointer to the data isn't null (there's a check for that), but are there any "gotchas" with this Parse() method?
Thanks very much for the generous offer, but it's a pretty big application and has a few other libs for dependencies, etc. I don't want to submit you to that kind of torture. :)
But after much time in the debugger, I am fairly certain that you were right--it's my code. I think there's a buffer overrun somewhere, which is invalidating either the pointer to the xml data or the data itself after it's in memory. This explains the random nature of it. It might also explain why it only happens in release mode: buffer checks are disabled for speed. Hopefully I'll uncover the problem soon....
Thanks a lot for your time and good will, Ellers.
Hi,
Don't you thint those errors can be related to the problem I have:
<https://sourceforge.net/mailarchive/forum.php?thread_id=6169466&forum_id=7472>
I've had not time to test it under some memory debugger.
Greets
-- mateusz
You're welcome :) Hope you solve it soon.
On the topic of memory checkers, here's a thread including links to free checkers:
http://discuss.joelonsoftware.com/default.asp?joel.3.55283.7
I downloaded one of the free ones and it does report leaks, but I haven't found out how to work it yet. Anyway it could be useful.
Post back with an update ...
This is a very long - but interesting - thread. I'm glad you are making some progress JM.
On the memory checker, I always check TinyXml before release with Valgrind - I'm a huge fan. Great memory checking code. The only downside is that it is linux only, I'd love to check agains the Windows libraries too.
http://valgrind.kde.org/
Still pounding on this problem, and I noticed there's a new version of TinyXML up, so I'll compile that and see what happens.
The odd thing is that this problem doesn't happen in debug builds (or if I run a release build with the debugger via Visual Studio). I'm suspecting memory gets trampled, and maybe since debug mode adds padding to allocations (to test for overruns) it doesn't cause trouble. But I can't figure out much beyond that yet.
The other interesting note is that the app crashes every time in some relation to reading xml (usually SkipWhiteSpace or something close), so I don't know if this is my code or not. I'm loading a lot more data than just xml and none of it has caused a problem, so I'll keep digging.
Try adding calls to _CrtCheckMemory at regular intervals. That will tend to detect if you're overrunning some sort of boundary.