Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Get Qt Extensions
  • Unsolved
Collapse
Brand Logo
  1. Home
  2. Qt Development
  3. Qt Creator and other tools
  4. [Solved] Cannot continue debugged process ... (debugger error)
Forum Updated to NodeBB v4.3 + New Features

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

Scheduled Pinned Locked Moved Qt Creator and other tools
7 Posts 3 Posters 7.1k Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • S Offline
    S Offline
    sprl111
    wrote on 14 Aug 2012, 22:41 last edited by
    #1

    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:
    Warning:
    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?

    Thanks.

    @
    class DINIBOARD : public QObject
    {
    Q_OBJECT

    private:
    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;
    // }

    }
    

    @

    1 Reply Last reply
    0
    • K Offline
      K Offline
      koahnig
      wrote on 15 Aug 2012, 06:58 last edited by
      #2

      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.

      Vote the answer(s) that helped you to solve your issue(s)

      1 Reply Last reply
      0
      • A Offline
        A Offline
        apoenitz
        wrote on 15 Aug 2012, 14:02 last edited by
        #3

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

        1 Reply Last reply
        0
        • S Offline
          S Offline
          sprl111
          wrote on 16 Aug 2012, 16:29 last edited by
          #4

          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.

          1 Reply Last reply
          0
          • S Offline
            S Offline
            sprl111
            wrote on 16 Aug 2012, 16:31 last edited by
            #5

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

            1 Reply Last reply
            0
            • K Offline
              K Offline
              koahnig
              wrote on 16 Aug 2012, 16:44 last edited by
              #6

              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

              Vote the answer(s) that helped you to solve your issue(s)

              1 Reply Last reply
              0
              • S Offline
                S Offline
                sprl111
                wrote on 16 Aug 2012, 17:24 last edited by
                #7

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

                1 Reply Last reply
                0

                1/7

                14 Aug 2012, 22:41

                • Login

                • Login or register to search.
                1 out of 7
                • First post
                  1/7
                  Last post
                0
                • Categories
                • Recent
                • Tags
                • Popular
                • Users
                • Groups
                • Search
                • Get Qt Extensions
                • Unsolved