Segmentation Fault after assigning QSqlQueryModel from function return in switch statement
-
Wait... why are you allocating your QSqlQuery object on the heap ? There's no reason for that.
-
Wait... why are you allocating your QSqlQuery object on the heap ? There's no reason for that.
wrote on 3 Mar 2022, 21:09 last edited by@SGaist What would you suggest we do to fix that? Sorry we are relatively new to Qt and are still learning
-
Just allocate it on the stack like all the examples show.
When you read a method signature that uses const references, it's usually not a good idea to create an object on the heap, only to de reference it to pass it to that method.
-
Just allocate it on the stack like all the examples show.
When you read a method signature that uses const references, it's usually not a good idea to create an object on the heap, only to de reference it to pass it to that method.
wrote on 3 Mar 2022, 21:20 last edited by@SGaist So create the QSqlQuery as a private member of the class rather than in the appliedSort() method?
-
No, just create it on the stack in the method, there's no need to use new, nor std::move, nor delete.
-
No, just create it on the stack in the method, there's no need to use new, nor std::move, nor delete.
wrote on 3 Mar 2022, 21:35 last edited by@SGaist Could that be what is causing the segmentation fault?
-
wrote on 3 Mar 2022, 23:02 last edited by
It looks like the model has already been deleted when the MainWindow's destructor tries to delete it again and that causes a segfault for what should be obvious reasons.
From the stack trace the SortLeadActor's destructor is called, and then the MainWindow destructor is called. Are you calling delete on the model that you're returning to MainWindow from appliedSort during ~SortLeadActor?
-
It looks like the model has already been deleted when the MainWindow's destructor tries to delete it again and that causes a segfault for what should be obvious reasons.
From the stack trace the SortLeadActor's destructor is called, and then the MainWindow destructor is called. Are you calling delete on the model that you're returning to MainWindow from appliedSort during ~SortLeadActor?
wrote on 3 Mar 2022, 23:19 last edited byYeah, that would also explain why they are facing the segfault not frequently... If you don't press that button which is connected to the slot where they delete the
model, the crash probably won't occur.Anyway, follow @SGaist 's instructions according to the query and in addition, don't try to double delete the pointer.
-
It looks like the model has already been deleted when the MainWindow's destructor tries to delete it again and that causes a segfault for what should be obvious reasons.
From the stack trace the SortLeadActor's destructor is called, and then the MainWindow destructor is called. Are you calling delete on the model that you're returning to MainWindow from appliedSort during ~SortLeadActor?
wrote on 4 Mar 2022, 00:03 last edited by@DeShark Thank you! The double delete was the issue and I have now fixed it
-
wrote on 4 Mar 2022, 00:50 last edited by
@RyanSolanki Please mark as solved if you are happy the issue is resolved. Also consider reading up further about Qt's memory management model (maybe it would make sense to pass a parent during the QSqlQueryModel's construction to avoid all that manual memory management or else perhaps smart pointers if there is no clear parent to assign ownership to).
Furthermore, SGaist's point about passing a pointer to a function whose signature expects a const reference cannot be understated. If the function expects a pointer, give it a pointer. If it expects a const reference, give it an object created on the stack! https://doc.qt.io/qt-5/qsqlquerymodel.html#details
The documentation is good; use it! It is unclear to me why you are using functions such as "clear" for the model. The setQuery() function already clears the model. Why mess around with new and delete several times when you can just pass in a new query to modify the existing model? Futhermore, why bother clear()-ing the model immediately before you delete it? The destructor is called during the delete, which itself frees up any resources, per the documentation.There are deeper problems of comprehension going on here!
14/14