I do not know how you can more clearly describe this funny situation. For all the time I worked with Qt, I used the signals / slots mechanism. But what is happening now I can not describe. He spent a lot of time on solving this problem, but he never came to answer. So, there is a class that works with the database:

#ifndef DATABASE_H #define DATABASE_H #include <QObject> #include <QSql> #include <QSqlQuery> #include <QSqlError> #include <QSqlDatabase> #include <QFile> #include <QDate> #include <QDebug> class DataBase : public QObject { Q_OBJECT private: QSqlDatabase db; public: explicit DataBase(QObject *parent = 0); ~DataBase(){ db.close(); } signals: void updateLocationsModel(); public slots: /**...**/ void createLocalPoint(double lat, double lon, QString type); void deleteLocalPoint(int id); }; #endif // DATABASE_H

A piece of his description:

 void DataBase::createLocalPoint(double lat, double lon, QString type) { QSqlQuery query; query.prepare("INSERT INTO LocationsPoints (lat, lon, type) VALUES (:lat, :lon, :type);"); query.bindValue(":lat", lat); query.bindValue(":lon", lon); query.bindValue(":type", type); if (!query.exec()){ qDebug() << "Error SQLite:" << query.lastError().text(); } emit updateLocationsModel(); } void DataBase::deleteLocalPoint(int id) { QSqlQuery query; query.prepare("DELETE FROM LocationsPoints WHERE LocationsPoints.id = :id;"); query.bindValue(":id", id); if (!query.exec()){ qDebug() << "Error SQLite:" << query.lastError().text(); } qDebug() << query.lastQuery(); emit updateLocationsModel(); qDebug() << "++++++"; }

Problem: When calling the createLocalPoint function, the code executes perfectly. Calling deleteLocalPoint crashes spontaneously. I did not see any sensible logic, but I tried to leave one line in this and that function

  emit updateLocationsModel();

And you know what? Crash in the second function remained, and the first one worked and works ...

enter image description here

Not finding a solution, I went to the debug tab.

enter image description here

Here something clears up. Maybe QML is to blame for everything, which I also actively use.

A bit of the main.cpp file

 LocationsModel locationsModel; QObject::connect(&db, SIGNAL(updateLocationsModel()), &locationsModel, SLOT(updateModel())); QGuiApplication app(argc, argv); QQmlApplicationEngine engine; QQmlContext* ctx = engine.rootContext(); ctx->setContextProperty("locationsModel", &locationsModel);

In QML, functions are called like this:

 dataBase.createLocalPoint(coordinates.latitude, coordinates.longitude, type);

AND

 dataBase.deleteLocalPoint(id);

Here is the slot

 void LocationsModel::updateModel() { QString str_query("SELECT "); str_query.append("LocationsPoints.id, "); str_query.append("LocationsPoints.lat, "); str_query.append("LocationsPoints.lon, "); str_query.append("LocationsPoints.type "); str_query.append("FROM LocationsPoints; "); this->setQuery(str_query); qDebug() << str_query << endl; qDebug() << "End" << endl; }

For reference. It was established experimentally that both deleteLocalPoint is executed to the end and emit (Debug info is output to qDebug ())

  • github.com/yashart/neva_project/tree/segfault1 there is all the code, but you do not run it without a database. In case the problem is not solved, I will get confused and post the .db file. PS Because of reputation, they were not allowed to include the link in the main post. - Vladislav Buzdin
  • I got confused and launched the .bd file into the project. It should be in the working directory of the program, Qt Creator calls it the working directory (usually the directory where the debug and release folder is located). The problem is detected when you remove the installed label (Pokemon). Set point on the right mouse button. - Vladislav Buzdin
  • Apparently, you are trying to use (read / write) memory outside the allocated volume. In this case, I would recommend that you use a tool to find such problems. QtCreator for Linux has built-in support for valgrind . - αλεχολυτ
  • @alexolut This, unfortunately, is obvious. I am sure that valgrind will add a portion of hemorrhoids here, but it will not lead to an unequivocal solution. Well, there it is impossible to stick with pointers, so fly away into the memory will not work. Once again . It works from one function, not from the other, even if only emit is left in both. - Vladislav Buzdin
  • in the presence of errors in working with memory, problems can manifest themselves in completely unexpected places. Valgring could well help you, I do not understand why you refuse it. Functions have at least a different set of parameters, make the same and check again. Try to delete the extra code until the problem ceases to appear. In extreme cases, you can still collect Qt from source and more accurately catch the point of departure. You can also test the performance on different versions of Qt. - αλεχολυτ

1 answer 1

Do you happen to tell the signal in QML that you are having something going on from another thread? If yes, then the crash may be due to this. You should not send a signal directly to QML, but to an object that operates in the main thread, just like QML, specifying when connecting Qt :: DirectConnection. And then from this object send a signal to QML.

  • Thanks for the advice! Called not from another thread. Repaired by changing the algorithm, acting on which the user reports the signal. Simply put, he removed the signal from the mouse and installed the keyboard button :) - Vladislav Buzdin