PDA

View Full Version : QString::operator=(QString &) problem, after moving some functionality to so lib



kornicameister
10th February 2012, 07:52
Hi again,

Recently I have created my own library (dynamically linked, Linux controlled os) and managed to successfully linked my application to it.
Sadly I encountered a problem that in previous version (in which classes located now in library, where in application code). Where is the problem ?

Here is the code snippet which generates SIGSEGV exception.


void WorkerQuery::worker_mode(const QSqlRecord& rec) {
w = new Worker(selfPointer);
w->setPrimaryKey(rec.value("idWorker").toInt());
w->setNames(rec.value("fname").toString(),rec.value("lname").toString()); //PROBLEM HERE
w->setLogin(rec.value("login").toString()); //PROBLEM ALSO HERE
w->setPriviliges(rec.value("authorization").toString()); //BUT THIS LINE GENERATES NO ERROR
}


QtCreator right after it's caught the exception is moving me to Dissambler, where I can see disassembled operator= from QString library and debugger is pointing at

0x7ffff6921e50 <+032>: lock decl (%rax)
this instruction

One more thing...
here are declarations of the method setNames and setLogin


void setLogin(const QString &login);
void setNames(const QString &a,const QString &b);
void setPriviliges(const QString &c);


What is more interesting is that only setLogin, setNames generates exception but setPriviliges generates no error still having same declarations as for example setLogin.

kornicameister
12th February 2012, 14:02
I found out that the same problem occurs under Windows...

ChrisW67
12th February 2012, 23:33
What does the code inside those three functions look like?
What does the stack backtrace look like?
Are you sure that rec is valid and does it have columns called "fname", "lname" and "login"?

kornicameister
13th February 2012, 04:16
These questions are now irrelevant, however rec was valid, the problem was somewhere else, where I did not except it to come up.
I'd simply forgotten to properly create private objects in dll, so despite valid access to Worker object, this object itself was encountering the problem when accessing to private members via d_ptr...

so there is everything fine with QString and it was due to my neglect....