segmentation fault caused by setText()

WhatIf

Hi,

I ran into segmentation fault after the last modification I made to a test program. Inside MainWindow constructor, I make a function call, makeConnections(), which is responsible to create signals/slots that I need. Here is the code that I recently added:

connect(ui->notesTEdit, SIGNAL(textChanged()), this, SLOT(rejectIllegalCharacters()));

void  MainWindow::rejectIllegalCharacters()
{
    
QString textWithoutIllegalChars = "";
.
.
.
ui->notesTEdit->setText(textWithoutIllegalChars);
}

All this code executes and runs without any problems. I get the segmentation fault, when the first call to

ui->notesTEdit->clear();

is made. How can I fix it?

mrjj

hi
what might be wrong is that
SIGNAL(textChanged()) calls rejectIllegalCharacters
and then u call setText which calls rejectIllegalCharacters again
and u set text and it calls rejectIllegalCharacters again
until you crash.

U make infinite loop i think.

WhatIf

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?

mrjj

@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)

jsulm

@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.

Sudo007

@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.

micland

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 your rejectIllegalCharacters() can't handle empty strings? Could that be the problem? What exactly are you doing in that method?

jsulm

@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.

mrjj

@WhatIf
hi
I think its infinite loop

if 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 ..

micland

@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 if foo has really changed....)
Good to know... I didn't expect this behaviour.

mrjj

@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 ""

kshegunov

@mrjj

Any change in text (plain or html) will cause the signal to be fired, so there's indeed a recursion here.