2
void MainWindow::save()
{
    const int currentIndex = tabWidget->currentIndex();
    if( currentIndex == -1 )
        return;

    QString filepath = m_fileList.at( currentIndex )->filepath();

    if( filepath.isEmpty() )
    {
        QString filters = tr("All files(*.*);;Textfiles(*.txt)");
        filepath = QFileDialog::getOpenFileName( this, tr("Save file"), QDir::homePath() );

        if( filepath.isEmpty() )
            return;
    }

    QFile file( filepath );
    if( !file.open( QIODevice::WriteOnly | QIODevice::Text ) )
        return;

    QTextStream str( &file );
    str << m_fileList.at( currentIndex )->textEdit()->toPlainText();

    file.close();

}

This code above works when debugging, only! If I run it, it crashes. But when I use the debugger and go through each step it doesn't. When I start the program through terminal and let it crash, it says Segmentation fault. I commented a lot of things out and ran it, to see where exactly it crashes. Apparently, when I call the QFileDialog, it crashes. It never shows but in debugging mode.

What's wrong? I'm on a linux machine (Ubuntu)

Davlog
  • 2,162
  • 8
  • 36
  • 60
  • 6
    At the moment I have no idea, but in general if you have a problem which does not happen while debugging you meight have a racing condition, while debugging the code is much slower executed (e.g. due stepping thrue the code). – rekire Nov 16 '13 at 20:47
  • 1
    Run it under Valgrind. – WhozCraig Nov 16 '13 at 20:47
  • @rekire yeah, I thought about it too. But what do I do when dealing with racing condition? – Davlog Nov 16 '13 at 20:48
  • race condition happens when you have multi threading, your code doesn't have such thing (at least part you have shown). First check application logs maybe there is some useful information, secondly clean project and build it again. – Marek R Nov 16 '13 at 21:21
  • 6
    Bugs that happen in Release but not in Debug are usually the result of uninitialized variables. Note: Variables that are uninitialized can be anything. So most Debug builds will usually force initialization to magic values to help tell when they have been used. But in Release build they are left un-touched. Tell your compiler to warn you about initialized variables fix them and re-run. Best make sure you code compiles with **zero** warnings even with warnings turned up. – Martin York Nov 16 '13 at 21:34
  • Minimum extra falgs are: `-Wall -Wextra` but check out http://stackoverflow.com/q/5088460/14065 – Martin York Nov 16 '13 at 21:38
  • 1
    No idea what kind of compiler and setting are used, but: many compilers add extra padding to memory allocations in debug mode (e.g. if you allocate 10*int32 you might access the 11th element and do not get a segfault in debug mode) Try to disable the extra padding in the compiler and debug the code; hopefully it will show you where the problem is – tebe Nov 17 '13 at 00:27
  • Still don't know why this happens but I noticed it does not happen in windows 8. I just opened that project, built and ran it and worked perfectly. – Davlog Nov 17 '13 at 21:03
  • Did you check your pro file? maybe there is a problem on config. – reggie Jul 15 '14 at 02:53
  • It's more fun when you debug true Release mode build on Windows (optimized Release mode with separate PDB) and with CDB attached the debuggee in Release mode runs fine... Without CDB it crashes very often. This is usually due to bad threading code. Under CDB, the app syncs on way more kernel objects that without CDB. – Петър Петров Oct 13 '14 at 22:38

0 Answers0