Panic in route test but tps test runs fine

[Brian Beverage]

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

Topic

[Charlie Bursell]

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  😀

[Brian Beverage]

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

[Charlie Bursell]

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}”

}

[Brian Beverage]

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

[Author]

Replies