Created attachment 587599 [details] strace of binary Description of problem: When I try to compile and run an application I'm developing, I'm getting segmentation faults from the QString library. This same bit of code compiled and ran fine under Slackware, Windows, and openSUSE. The problem initially showed up a month or two ago if I remember correctly in Fedora 16, I thought that my libraries had just gotten screwed up somehow, and so I waited until 17 to come out to reinstall, and I tested it on that on a clean system and it's still broken. Version-Release number of selected component (if applicable): Qt 4.8.x How reproducible: I have yet to actually reproduce the error itself in independent code however however I am attaching the file that causes the QString libraries to break. Steps to Reproduce: 1. use Qt Creator and create a basic project 2. take the attached node class and hook it into this basic project 3. compile and try to run Actual results: Segmentation Fault Expected results: Program runs, just as it does under wine, windows, slackware, and openSUSE. Additional info: License on the class itself is intended to be either GPL or LGPL, and I'm still undecided on which version.
Created attachment 587600 [details] header file
Created attachment 587601 [details] implementation file Line 20 in the file is set up in the stack that causes the segfault according to the debugger.
Comment on attachment 587599 [details] strace of binary That's an strace, not a stack trace. Unfortunately, the latter is what we really need.
FYI, QString is a very frequently used class. It's highly unlikely that it is really buggy. Crashes in QString are normally bugs in the application using it, due to use of an uninitialized, already deleted etc. QString.
And for a more useful debugging trace, please try using valgrind instead of strace. That will give us actual stack traces, not only of the crash, but also hopefully of its true cause.
(In reply to comment #2) > Created attachment 587601 [details] > implementation file > > Line 20 in the file is set up in the stack that causes the segfault > according to the debugger. imo it's a bug in line 20. the empty stringlist causes the crash in this case. You have to check the qstringlist with isEmpty() before call last() function.
Oh right, last() on an empty list is not allowed in Qt 4. (It used to be allowed in Qt 3 and always returned a default-constructed object, but in Qt 4, this guarantee was removed for performance reasons. Even if it happened to work for you so far, you were relying on undefined behavior.)
it should crash on slackware/opensuse too if you compiles it without the flag -DQT_NO_DEBUG
Okay you're right in that it's crashing because the QStringlist is empty, and I will admit I should have provided at least a template of one of the resource files so that It could be better reproduced. However what appears to be happening is that there's a qrc related bug, which is causing QDir not to populate the QStringList when it's querying for .hjt files, which was then is causing the crash.
So then a testcase actually using qrc is needed.
Created attachment 587908 [details] qrc file used
Created attachment 587909 [details] Sample resource file, created for use as a test case There I've uploaded the qrc and a resource file that can be used as a test case. Note that the .hjt file should go under a folder called Resources in the source code directory.
How do we compile the resources? Do you have a build script, .pro file, CMakeLists.txt file or whatever?
Created attachment 587914 [details] Qt .pro file, modified for use with the testcase here's the .pro file, I've already commented out everything not related to the usecase so should be set up to go without need for extra modification.
main.cpp is also needed.
Created attachment 587916 [details] Qt .pro file modified for use with the test case in that case I'm going to update the .pro file and give you the node manager class as well
Created attachment 587917 [details] nodemanager header for use with the node class
Created attachment 587918 [details] Nodemanager implementation
Created attachment 587922 [details] all thats required to build and test Okay, I'm just going to be efficient here and just attach this as a tar.gz
as a side note I removed the ':/' in the copy of the node.cpp I put in the tar.gz so you're going to have to move the resources folder to the build location otherwise it won't work, and obviously put back the ':/' to for qrc testing
(In reply to comment #19) > Created attachment 587922 [details] > all thats required to build and test > > Okay, I'm just going to be efficient here and just attach this as a tar.gz it's a bug in your codes, you are using assignments at names scope, it's not allowed. you have to move them inside of your constructor node::node()
(In reply to comment #21) > (In reply to comment #19) > > Created attachment 587922 [details] > > all thats required to build and test > > > > Okay, I'm just going to be efficient here and just attach this as a tar.gz > > it's a bug in your codes, you are using assignments at names scope, it's not > allowed. you have to move them inside of your constructor node::node() If I'm understanding what you're saying right then you're wrong, those are static variables which must be initialized outside of the constructur or any function, and static variables as long as it's in the initialization statement can be assigned values outside of functions.
This message is a reminder that Fedora 17 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 17. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '17'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 17's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 17 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 17's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 17 changed to end-of-life (EOL) status on 2013-07-30. Fedora 17 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.