Panic in route test but tps test runs fine

Clovertech Forums Read Only Archives Cloverleaf Cloverleaf Panic in route test but tps test runs fine

  • Creator
    Topic
  • #53130
    Brian Beverage
    Participant

      Hello fellow Cloverleaf users,

      I have the following tps proc as well as 2 others that are running currently and have for months now. This code in the testing tool and our test site panics the engine and shuts down the process.

      The below proc just copies the number to MSH 6 so the other vendor can identify the messages.

      Code:

      run {
               # ‘run’ mode always has a MSGID; fetch and process it
      keylget args MSGID mh
      set msg [msgget $mh]
               set fs [crange $msg 3 3]
               set cs [crange $msg 4 4]
               set rs [crange $msg 5 5]
      set tmpMSH {}

                    set segmentList [split $msg r]
                   
                    foreach segment $segmentList {
                       set segmentid [crange $segment 0 2]
                       switch -exact — $segmentid {
      MSH {
      set splitsegment [split $segment $fs]
      set tmpMSH $splitsegment
      set tmpMSH [join [lreplace $tmpMSH 6 6 171003] |]
                         }
                       
                        }
                     }

      set segmentList [lreplace $segmentList 0 0 $tmpMSH]
      #create a new message and continue it on.
      set nmh [msgcreate -recover [join $segmentList r]]
      echo [msgget $mh]
      lappend dispList “KILL $mh”
      lappend dispList “CONTINUE $nmh”

      }

      I have tried this 2 ways one creating the new message using mh and just continue mh that panics the engine and the way above that panics the engine. The echo statement prints fine. I can comment out the CONTINUE and the proc will run.

      Below is the panic codes I see in the testing tool.

      Code:

      [pti :sign:WARN/0:  UNNAMED_TID:06/06/2012 15:37:10] Thread 0 received signal 11
      [pti :sign:WARN/0:  UNNAMED_TID:06/06/2012 15:37:10] PC = 0xffffffff
      PANIC: “0”
      PANIC: Calling “pti” for thread UNNAMED_TID
      —– Scheduler State —–
      Thread Events     State      Priority Runnable  PT Msgs
        0      0   SCHED_IDLE         0       0       1,0,0

      ————– Thread 0 ————–
      ti: 0x0xa0286c8
         tid           :    0
         HostPthreadId : 0x(nil)
         EventList     : 0x0xa027608
         PolledEvents  : 0x0xa028628
         PthreadEvent  : 0x(nil)
         ReadyEvents   : 0x0xa028598
         CtrlMsgs      : 0x0xa0287c8
         UserCtrlMsgs  : 0x0xa0287d8
         UserDataMsgs  : 0x0xa0287e8
         StartArgs     : 0x(nil)
         SchedState    : SCHED_IDLE
         SchedPriority : 0
         Killed        : 1
      —– Registered Events —–
      el: 0x0xa027608
         elCount : 0
         elHead: 0x(nil)
         elTail: 0x(nil)
      —– Polled Events —–
      el: 0x0xa028628
         elCount : 0
         elHead: 0x(nil)
         elTail: 0x(nil)
      —– Ready Events —–
      el: 0x0xa028598
         elCount : 0
         elHead: 0x(nil)
         elTail: 0x(nil)
      —– Outstanding Pthread Ctrl Msgs —–
      pmq: 0x0xa0287c8
      Count   : 1
      Head    : 0x0xb822060
      Tail    : 0x0xb822060
      PthreadMsg: 0x0xb822060
         ptmType   : 1
         ptmSender : 0
         ptmCtrl   : 3358
         ptmNext   : 0x(nil)
         ptmDataPtr: 0x(nil)
         ptmDataInt: 0
      —– Outstanding Pthread User Ctrl Msgs —–
      pmq: 0x0xa0287d8
      Count   : 0
      Head    : 0x(nil)
      Tail    : 0x(nil)
      —– Outstanding Pthread User Data Msgs —–
      pmq: 0x0xa0287e8
      Count   : 0
      Head    : 0x(nil)
      Tail    : 0x(nil)

      PANIC: Process panic—engine going down
      PANIC: assertion ‘0’ failed at PthreadInterface.cpp/715

      Any help is greatly appreciated.

      Thanks

      Brian

    Viewing 3 reply threads
    • Author
      Replies
      • #76673
        Charlie Bursell
        Participant

          Change the msgcreate to msgcopy.  msgcreate has no meta data.  The engine doe not know what to do with it

          Sure is a lot of work to change one field in the MSH  ðŸ˜€

        • #76674
          Brian Beverage
          Participant

            Quote:

            Sure is a lot of work to change one field in the MSH  

            The plan is since this proc will be used on several different routes. Once it is working the number placed in MSH6 will be passed in as an ARG to the proc. If you have a better solution I am open to suggestions.

            I have changed to this:

            Code:

                  run {
                     # ‘run’ mode always has a MSGID; fetch and process it
            keylget args MSGID mh
            set msg [msgget $mh]
                     set fs [crange $msg 3 3]
                     set cs [crange $msg 4 4]
                     set rs [crange $msg 5 5]
            set tmpMSH {}
            set nmh [msgcopy $mh]
            set nmsg [msgget $nmh]
            set nmhseglist [split $nmsg r]
                          set segmentList [split $msg r]
                         
                          foreach segment $segmentList {
                             set segmentid [crange $segment 0 2]
                             switch -exact — $segmentid {
            MSH {
            set splitsegment [split $segment $fs]
            set tmpMSH $splitsegment
            set tmpMSH [join [lreplace $tmpMSH 6 6 171003] |]
                               }
                             
                              }
                           }

            set nmhseglist [lreplace $segmentList 0 0 $tmpMSH]
            #create a new message and continue it on.
            set nmh [join $nmhseglist r]
            lappend dispList “KILL $mh”
            lappend dispList “CONTINUE $nmh”

            }

            Now I see ‘ (returned by ‘tps_MSH6GreenwayNumber ‘) does not match { } after the CONTINUE It looks like the message is working in both the route test and tps test but both show the message.

            Thanks Again,

            Brian

          • #76675
            Charlie Bursell
            Participant

              Hard to tell.  Why do you need two message handles if you KILL the original?

              Unless I am missing something Try this

              run {

                       

                keylget args MSGID mh

                set msg [msgget $mh]

                set fs [string index $msg 3]

                set seglist [split $nmsg r]

                set MSH [split [lindex $seglist 0] $fs]

                set MSH [lreplace $MSH 6 6 171003]

                set seglist [lreplace $seglist 0 0 [join $MSH $fs]]

                 msgset $mh [join $seglist r]

                 return “{CONTINUE $mh}”

              }

            • #76676
              Brian Beverage
              Participant

                Quote:

                Hard to tell.  Why do you need two message handles if you KILL the original?

                No reason.

                Works like a charm.

                Thanks Charlie for the help.

                Thanks,

                Brian

            Viewing 3 reply threads
            • The forum ‘Cloverleaf’ is closed to new topics and replies.