Unsolved segmentation fault caused by setText()
-
Well, your explanation makes sense but I created several breakpoints to find out the source of the problem. One breakpoint was at the same line as
void MainWindow::rejectIllegalCharacters()
and another was at the closing brace of it. The breakpoints didn't cause the problem.
So, I assume that rejectIllegalCharacters() is only called once when the constructor is first called. Correct me if I wrong, but the behavior you describe will happen if I actually enter text into the text edit not when I make the connect?
I also made other breakpoints after the
connect(ui->notesTEdit, SIGNAL(textChanged()), this, SLOT(rejectIllegalCharacters()));
is callled, all run with no issues until I hit the call to clear()
What would be the best way to fix it?
-
@WhatIf said:
ui->notesTEdit->setText should trigger textChanged ?
the connect WILL not! its just set up the signal + slot.But if you debug it and u say it dont , its not that then.
but no reason for
ui->notesTEdit->clear();
to crash. (unless it calls textchange and u get loop) -
@WhatIf If you call
ui->notesTEdit->clear()
after the connect statement then it most probably causes that infinite loop.
In void MainWindow::rejectIllegalCharacters() you should disconnect before setting text and then connect again to avoid infinite loop. -
@WhatIf said:
You cant do this ,as soon as there is signal textChanged , the slot is called,
and the emitter ui->notesTEdit is blocked . inside the slot you are trying to access the emitter only, which is blocked.
However , if you want to do this , then you need to put Qt::QueuedConnection.
connect(ui->notesTEdit, SIGNAL(textChanged()), this, SLOT(rejectIllegalCharacters()), Qt::QueuedConnection);It works , try once.
-
I don't think it's an infinite loop because after the first call the illeal characters are already remomved and the text will not change again with the second call. But if you say you get a segfault when calling
clear()
- maybe yourrejectIllegalCharacters()
can't handle empty strings? Could that be the problem? What exactly are you doing in that method? -
@Sudo007 What do you mean by "blocked". Nothing is blocked here. It is perfectly fine to access ui->notesTEdit in the slot. Qt::QueuedConnection is needed when using signals/slots across threads which is not the case here.
-
@WhatIf
hi
I think its infinite loopif i make small test
void MainWindow::on_textEdit_textChanged() {
qDebug() << " --- in on_textEdit_textChanged";
QString textWithoutIllegalChars = "";
ui->textEdit->setText(textWithoutIllegalChars);
}void MainWindow::on_pushButton_released()
{
ui->textEdit->clear();
}This will crash it as soon as i press button and clear is called.
so it was as expected that clear alter text, on_textEdit_textChanged is called and it
call setText that make signal fire again , over and over ..
-
@mrjj said:
so it was as expected that clear alter text, on_textEdit_textChanged is called and it
call setText that make signal fire again , over and over ..Uhm, I thought there's a check that emits the signal only if the text has really changed - if the text is replaced with the same string again, it's not a "change" in my eyes... (I don't have an example at hand but I think I saw other signals in Qt where such checks are done and a
fooChanged
signal is fired only iffoo
has really changed....)
Good to know... I didn't expect this behaviour. -
@micland
frankly i did not think it was that either but at least here - the mini test
crash so it seems it works that way.
It seems clear does trigger textchanged and even
setText("") also does.edit:
Maybe the text after clear is not the same as "" -
Any change in text (plain or html) will cause the signal to be fired, so there's indeed a recursion here.