[Solved] Cannot continue debugged process ... (debugger error)

  • Hello,

    I'm getting a debuggger error. It looks like it is happening when I step into a strcpy statement. The error dialog says,
    "Cannot continue debugged process:
    Cannot insert breakpoint -301
    Error accessing memory address 0xb93cd30: Input/output error."

    The debugger just seems to crash or at least discontinue the debugging session when the error occurs.

    Code snippet is below. I commented out the library call following the strcpy thinking that it might be the culprit, but I had the same result.

    I was wondering if anyone will help me solve this?


    class DINIBOARD : public QObject

    char bitfile_path[512]; // Assuming 512 byte max path
    QString filename;
    // in function within class
    char *temp;
    // program the FPGA
    filename = QFileDialog::getOpenFileName(gui, "Open Bit File", "/bitfiles", "FPGA Bit Files (*bit)");
    if( !(filename.isNull()) && (filename.length() < 512) )
    temp = filename.toUtf8().data();
    strcpy(bitfile_path, temp ); // error seems to be occuring here
    // apistatus = global_selected_board->emu_configure_fpga(/index/1,/file/bitfile_path,/on_marvell/false,/configmictor/0);
    // if (apistatus != DINIAPI_STATUS_SUCCESS)
    // {
    // emu_report_systemerror(apistatus);
    // return;
    // }



  • Moderators

    Does the debugging continue after strcpy without problems?
    strcpy is a routine of the standard c-lib. So, you cannot enter for debugging. Some debuggers will enter assembler mode.

  • Unrelated: temp = filename.toUtf8().data(); is wrong.

    toUtf8 creates a temporary QByteArray, data() gives a pointer to it's internal buffer, this gets assigned to temp. At the end of the full expression the temporary is destroyed, leaving the pointer dangling. Afterwards (in line 21) you use the dangling pointer as parameter to strcpy.

    QByteArray ba = filename.toUtf8(); strcpy(bitfile_path, ba.data()); is "safe".

  • Thank you for your answers. Actually, I discovered that the real culprit was the QFileDialog static function findFileName() that I was calling. I'm not sure why that was causing problems. I commented it out and the code built fine. In another section of code I called the same static function with no problem. However in that case the function was called from a function in the MainWindow class. In the problem case (this case), QFileDialog::getFileName() is called from a function in another class but a pointer to MainWindow is given to it. So, I don't get it. For expediency I hardwired a file name into the code in lieu of the file dialog with the intent of revisitiing that later when I get time. So, I'll call this case solved for now since I discovered the problem even though I don't understand why.

  • In the above post I ment to say "debugged just fine" not "built fine".

  • Moderators

    Your source example is a bit too much scaled down. We have the class declaration and suddenly we are in part of the implementation.
    However, what is gui? and where is this actually called?
    You may want to try it with "this" as in the "example":http://qt-project.org/doc/qt-4.8/qfiledialog.html#getOpenFileName

  • The argument "gui" is a pointer to MainWindow. I can't use "this" because the class is not the MainWindow clas.

Log in to reply

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