segmentation fault caused by setText()



  • 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?


  • Qt Champions 2016

    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.



  • 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?


  • Qt Champions 2016

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


  • Moderators

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


  • Moderators

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


  • Qt Champions 2016

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



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


  • Qt Champions 2016

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


  • Qt Champions 2016

    @mrjj

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


Log in to reply
 

Looks like your connection to Qt Forum was lost, please wait while we try to reconnect.