Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Get Qt Extensions
  • Unsolved
Collapse
Brand Logo
  1. Home
  2. Qt Development
  3. General and Desktop
  4. Run-time error "index out of range"
Forum Updated to NodeBB v4.3 + New Features

Run-time error "index out of range"

Scheduled Pinned Locked Moved General and Desktop
7 Posts 3 Posters 4.5k 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.
  • R Offline
    R Offline
    ruehlchr
    wrote on last edited by
    #1

    Hi all,

    I fighting with a nasty problem on my Windows port (VS2008/VC++v9) for a test-tool with 2 threads.
    To give you an overview what I did:

    MainThread (keeps fingers on the Display/Input-Events)
    WorkerThread (did some serial communication)

    MainThread send commands by QQueue to the WorkerThread to tell what command to execute.
    WorkerThread uses signal/slot to update the MainThreads QListWidget, QTextEdit, QLineEdit ....

    What happen under Windows, the WorkerThread use a signal to clear a logging window (QListWidget). Next it write some debug
    info's into it. ASSERT QVector<T>::at: "index out of range". (SOMETIMES)

    When I debug the session and go back in the call-stack and check the variables i(1) and d->size(20) the Assert condition
    not match any more ( i > 0 && i < d->size ).

    My workaround I sleep for 200ms after the QListWidget::clear() before I continue with the program.

    Not working: use a Mutex to protect the update calls in the MainThread to manipulate the display.

    Mainthread queue in:
    @
    void Reader::freqSetPreset()
    {
    Cmd cmd;
    cmd.cnum = Cmd::PRESETFREQ;
    cmd.freqMode = ( cbFrePreset->currentIndex() & 0xff );
    _thread1.queueCmd(cmd);
    }
    @

    WorkerThread Dequeue
    @
    worker::run(){
    ....
    forever {
    _mutex.lock();
    if ( _run ) {
    _mutex.unlock();
    if ( _cmdqueue.isEmpty() ) {
    usleep(100);
    }
    else {

    _queuemutex.lock();
    Cmd cmd = _cmdqueue.dequeue();
    _queuemutex.unlock();
    

    ...
    switch ( cmd ) {
    case Cmd::PRESETFREQ:
    {
    qDebug("Thread1 PresetFeq");
    clearlog();
    // workaround
    usleep(200000);
    freqSetPreset(cmd.freqMode);
    break;
    }

    ...

    void Worker::freqSetPreset(const quint8 FreMode)
    {
    ...
    if ( _rmu.SetFrequency( FreMode, FreBase, BaseFre, ChannNum, ChannSpc, FreHop ) ) {
    updateStatus("Preset Frequency\tOK"); // signal
    }

    @

    successions welcome.

    Chris

    If you want to make it fly. QTit!

    1 Reply Last reply
    0
    • F Offline
      F Offline
      Franzk
      wrote on last edited by
      #2

      Where exactly in the above code does your program crash?

      "Horse sense is the thing a horse has which keeps it from betting on people." -- W.C. Fields

      http://www.catb.org/~esr/faqs/smart-questions.html

      1 Reply Last reply
      0
      • R Offline
        R Offline
        ruehlchr
        wrote on last edited by
        #3

        Franz,

        I need to start the thing in the Virtual Studio ( ;-( ) ) then I can tell exactly.

        General
        a) QListWidget::clear()
        b) QListWidget::addItem(s) QString s

        sender WorkerThread via signal to receiver MainThread slot.

        I never face the problem on the Linux.

        If you want to make it fly. QTit!

        1 Reply Last reply
        0
        • G Offline
          G Offline
          goetz
          wrote on last edited by
          #4

          Could be an issue with non-queued signals between threads. Did you read Peppe's great wiki article "Threads, Events and QObjects":http://developer.qt.nokia.com/wiki/Threads_Events_QObjects already? It explains a lot of stuff in this area.

          http://www.catb.org/~esr/faqs/smart-questions.html

          1 Reply Last reply
          0
          • R Offline
            R Offline
            ruehlchr
            wrote on last edited by
            #5

            Volker,

            That's a succession ..
            thanks I will dig in - windows macht mich fertig!.

            But its 6:15pm in Hong Kong now and I go and have a beer. This problem needs to wait until tomorrow , but I let you know.

            Cheers
            Chris

            If you want to make it fly. QTit!

            1 Reply Last reply
            0
            • G Offline
              G Offline
              goetz
              wrote on last edited by
              #6

              Enjoy your "Feierabend" :-)

              http://www.catb.org/~esr/faqs/smart-questions.html

              1 Reply Last reply
              0
              • R Offline
                R Offline
                ruehlchr
                wrote on last edited by
                #7

                Hi All,

                I found the my problem. The Logging !
                I have my own MessageOutHandler .. this Handler wrote non synchronized directly to the ListWidget and triggers the ASSERT() .. - no need for the work around any more.

                Volker the article you refer was very nice. Some of the infos help me find my fault.

                cheers
                Chris

                If you want to make it fly. QTit!

                1 Reply Last reply
                0

                • Login

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