.readAll succeed but Segmentation fault on ~QByteArray when function return
-
@KJ92 Pugixml can load directly from a file, so I am not sure why you use the intermediate QByteArray.
Does it make any difference if you force the pugi::xml_document destruction before the return?
... int options = pugi::parse_default; pugi::xml_parse_result result; { pugi::xml_document xmlDoc; result = xmlDoc.load_buffer( document.constData(), document.size(), options); } ...@ChrisW67 said in .readAll succeed but Segmentation fault on ~QByteArray when function return:
@KJ92 Pugixml can load directly from a file, so I am not sure why you use the intermediate QByteArray.
Stack trace shows
#7 0x000055d8c4b1bc54 in xmlDoc (filePath=":/pc/xml/my_xml.xml")so OP is using a Qt resource file, hence can't ask Pugixml to open that! :)
Does it make any difference if you force the pugi::xml_document destruction before the return?
Yeah, so far as I can see existing code ought to do destruction in right/acceptable order, I wondered about that. Furthermore I looked up and pugixml
load_buffer()says it copies the buffer content passed in, so don't know what is going with theQByteArrayproblem!I think I would start by verifying that if the
xmlDoc.load_buffer()statement is commented out --- or pass some literal data in, not from theQByteArray documentvariable --- that all is well on theQByteArraydestructor not erroring? -
@KJ92 Pugixml can load directly from a file, so I am not sure why you use the intermediate QByteArray.
Does it make any difference if you force the pugi::xml_document destruction before the return?
... int options = pugi::parse_default; pugi::xml_parse_result result; { pugi::xml_document xmlDoc; result = xmlDoc.load_buffer( document.constData(), document.size(), options); } ...@ChrisW67 about
Pugixml can load directly from a file, so I am not sure why you use the intermediate QByteArray.please see @JonB 's comment. its because the path is a QT resource
about this,
Does it make any difference if you force the pugi::xml_document destruction before the return?In my original code, I get the pugi::xml_document as variable. so its destruction is not possible as its used in the code.
I think I would start by verifying that if the xmlDoc.load_buffer() statement is commented out --- or pass some literal data in, not from the QByteArray document variable --- that all is well on the QByteArray destructor not erroring?@JonB When i comment out xmlDoc.load_buffer() the code works.
BTW, I'm trying to upgrade my QT from 5 to 6. This code snippet worked well in QT5.
Now in QT6 its failing in QByteArray destructor. -
@ChrisW67 about
Pugixml can load directly from a file, so I am not sure why you use the intermediate QByteArray.please see @JonB 's comment. its because the path is a QT resource
about this,
Does it make any difference if you force the pugi::xml_document destruction before the return?In my original code, I get the pugi::xml_document as variable. so its destruction is not possible as its used in the code.
I think I would start by verifying that if the xmlDoc.load_buffer() statement is commented out --- or pass some literal data in, not from the QByteArray document variable --- that all is well on the QByteArray destructor not erroring?@JonB When i comment out xmlDoc.load_buffer() the code works.
BTW, I'm trying to upgrade my QT from 5 to 6. This code snippet worked well in QT5.
Now in QT6 its failing in QByteArray destructor.@KJ92 said in .readAll succeed but Segmentation fault on ~QByteArray when function return:
In my original code, I get the pugi::xml_document as variable. so its destruction is not possible as its used in the code.
That would be a possibly different situation. Are you saying that the code as you show presently, exactly that, produces the error?
BTW, I'm trying to upgrade my QT from 5 to 6. This code snippet worked well in QT5.
Now in QT6 its failing in QByteArray destructor.This sounds terribly relevant! Not that I know why, but someone....
P.S.
Have a try ofdocument.data()instead ofdocument.constData(), you should not have to and it ought make no difference but might be useful for investigation.... -
@KJ92 said in .readAll succeed but Segmentation fault on ~QByteArray when function return:
In my original code, I get the pugi::xml_document as variable. so its destruction is not possible as its used in the code.
That would be a possibly different situation. Are you saying that the code as you show presently, exactly that, produces the error?
BTW, I'm trying to upgrade my QT from 5 to 6. This code snippet worked well in QT5.
Now in QT6 its failing in QByteArray destructor.This sounds terribly relevant! Not that I know why, but someone....
P.S.
Have a try ofdocument.data()instead ofdocument.constData(), you should not have to and it ought make no difference but might be useful for investigation....@JonB said in .readAll succeed but Segmentation fault on ~QByteArray when function return:
That would be a possibly different situation. Are you saying that the code as you show presently, exactly that, produces the error?
yes . same code snippet fails as well.
@JonB said in .readAll succeed but Segmentation fault on ~QByteArray when function return:
Have a try of document.data() instead of document.constData(), you should not have to and it ought make no difference but might be useful for investigation....
same error
-
@ChrisW67 about
Pugixml can load directly from a file, so I am not sure why you use the intermediate QByteArray.please see @JonB 's comment. its because the path is a QT resource
about this,
Does it make any difference if you force the pugi::xml_document destruction before the return?In my original code, I get the pugi::xml_document as variable. so its destruction is not possible as its used in the code.
I think I would start by verifying that if the xmlDoc.load_buffer() statement is commented out --- or pass some literal data in, not from the QByteArray document variable --- that all is well on the QByteArray destructor not erroring?@JonB When i comment out xmlDoc.load_buffer() the code works.
BTW, I'm trying to upgrade my QT from 5 to 6. This code snippet worked well in QT5.
Now in QT6 its failing in QByteArray destructor.@KJ92 said in .readAll succeed but Segmentation fault on ~QByteArray when function return:
In my original code, I get the pugi::xml_document as variable. so its destruction is not possible as its used in the code.
so, the code sample you showed is not accurate. Please post the actually code.
-
@KJ92 said in .readAll succeed but Segmentation fault on ~QByteArray when function return:
In my original code, I get the pugi::xml_document as variable. so its destruction is not possible as its used in the code.
so, the code sample you showed is not accurate. Please post the actually code.
@J-Hilk said in .readAll succeed but Segmentation fault on ~QByteArray when function return:
so, the code sample you showed is not accurate. Please post the actually code.
Please see my comment
@KJ92 said in .readAll succeed but Segmentation fault on ~QByteArray when function return:
yes . same code snippet fails as well.
-
@J-Hilk said in .readAll succeed but Segmentation fault on ~QByteArray when function return:
so, the code sample you showed is not accurate. Please post the actually code.
Please see my comment
@KJ92 said in .readAll succeed but Segmentation fault on ~QByteArray when function return:
yes . same code snippet fails as well.
@KJ92
You need to establish definitively whether it's the act of passing someQByteArraytoxml_document.load_buffer()which is the cause. As opposed to anything else. The danger is somehow some sort of memory corruption going on, which makes tracking down bugs notoriously difficult.Also as I said the Qt6 vs Qt5 looks significant to me.
Just for me, change the code fragment you have (the one you have been showing, not something else which is in your code) from
QByteArray document = file.readAll();to something like
QByteArray *document = new QByteArray(file.readAll());Now the
QDocumentis on the heap not the stack. Do not bother to delete/free it, yes I know it leaks. Does this make the problem go away? Presumably it does since no destructor gets called. -
@KJ92
You need to establish definitively whether it's the act of passing someQByteArraytoxml_document.load_buffer()which is the cause. As opposed to anything else. The danger is somehow some sort of memory corruption going on, which makes tracking down bugs notoriously difficult.Also as I said the Qt6 vs Qt5 looks significant to me.
Just for me, change the code fragment you have (the one you have been showing, not something else which is in your code) from
QByteArray document = file.readAll();to something like
QByteArray *document = new QByteArray(file.readAll());Now the
QDocumentis on the heap not the stack. Do not bother to delete/free it, yes I know it leaks. Does this make the problem go away? Presumably it does since no destructor gets called.@JonB said in .readAll succeed but Segmentation fault on ~QByteArray when function return:
Now the QDocument is on the heap not the stack. Do not bother to delete/free it, yes I know it leaks. Does this make the problem go away? Presumably it does since no destructor gets called.
Yes the problem goes away. as a workaround i can add the heap allocation and then immedietly after
pugi::xml_parse_result result = xmlDoc.load_buffer( document.constData(), document.size(), options);to delete.
But it's interesting why having it on the stack make this segmentation fault and the supposedly memory corruption upon resource release
-
@JonB said in .readAll succeed but Segmentation fault on ~QByteArray when function return:
Now the QDocument is on the heap not the stack. Do not bother to delete/free it, yes I know it leaks. Does this make the problem go away? Presumably it does since no destructor gets called.
Yes the problem goes away. as a workaround i can add the heap allocation and then immedietly after
pugi::xml_parse_result result = xmlDoc.load_buffer( document.constData(), document.size(), options);to delete.
But it's interesting why having it on the stack make this segmentation fault and the supposedly memory corruption upon resource release
@KJ92 said in .readAll succeed but Segmentation fault on ~QByteArray when function return:
But it's interesting why having it on the stack make this segmentation fault and the supposedly memory corruption upon resource release
This is just by accident. It doesn't matter if you create a QByteArray on the stack or on the heap, the real data is stored on the heap so document.data() always points to the heap. You have another problem - someone writes around in your stack who shouldn't. I would guess you're mixing debug and release build - e.g. a Qt debug build and a pugi release build or the other way round so the sizes of the objects don't match the compilers expectations.
-
@ChrisW67 said in .readAll succeed but Segmentation fault on ~QByteArray when function return:
@KJ92 Pugixml can load directly from a file, so I am not sure why you use the intermediate QByteArray.
Stack trace shows
#7 0x000055d8c4b1bc54 in xmlDoc (filePath=":/pc/xml/my_xml.xml")so OP is using a Qt resource file, hence can't ask Pugixml to open that! :)
Does it make any difference if you force the pugi::xml_document destruction before the return?
Yeah, so far as I can see existing code ought to do destruction in right/acceptable order, I wondered about that. Furthermore I looked up and pugixml
load_buffer()says it copies the buffer content passed in, so don't know what is going with theQByteArrayproblem!I think I would start by verifying that if the
xmlDoc.load_buffer()statement is commented out --- or pass some literal data in, not from theQByteArray documentvariable --- that all is well on theQByteArraydestructor not erroring?
