strange Xlate IF logic bug

[Daniel Lee]

I’m using Cloverleaf 6.1 on Windows Server 2008 R2.

In my Xlate I’m checking the OBX-3.1 against a Table and if the value is not found in the table then the default output is “0”.  The goal is to suppress the OBX segment if the value is not in the table.  To do this I have my pathcopy and all of my copy statements for the OBX in an IF statement that evaluates if the output of the table is “0”.

THE ABOVE CODE WORKS.  So that’s not the issue.

The issue is that when I use my if statement in my Xlate to evaluate if the output of the table the process panics.  Below outlines the very odd behavior of this Xlate.

The If statement is:  @vitalsInd ne =0

1)  If I change the above if statement to say @vitalsInd eq =0 it does not panic!  (of course it gives me the exact opposite of what I want)

2) If I change the above if statement to say @vitalsInd ne =”0″ it does not panic.  (but then it also doesn’t suppress any of the OBX segments.

3) When I put debug statements in the Xlate I can see the Xlate is completing fine.  It’s just bombing out when it tries to write the outbound message.

Below is the panic message that I’m getting and attached is my Xlate screenshot.

Code:

[prod:prod:INFO/0:    proc5_cmd:10/12/2015 12:21:58] Thread fr_site1_vitals_adt_p5 not auto-started.
[prod:prod:INFO/0:    proc5_cmd:10/12/2015 12:21:58] Thread fr_site1_bar_p5 not auto-started.
[prod:prod:INFO/0:    proc5_cmd:10/12/2015 12:21:58] Thread to_dbM_bar_p5 not auto-started.
[prod:prod:INFO/0:    proc5_cmd:10/12/2015 12:21:58] Thread to_dbM_vitals_adt_p5 not auto-started.
[prod:prod:INFO/0:    proc5_cmd:10/12/2015 12:21:58] Thread to_dbM_dev_bar_p5 not auto-started.
[prod:prod:INFO/0:    proc5_cmd:10/12/2015 12:21:58] Thread to_dbM_dev_vitals_adt_p5 not auto-started.
[tcl :out :INFO/0:  proc5_xlate:10/12/2015 12:21:59] XLT is loaded from local site, read e:cloverleafcis6.1integrator__Flagler_Master/formats/hl7/2.5.1/Allscripts_SCM_Vitals/fields from master
[tcl :out :INFO/0:  proc5_xlate:10/12/2015 12:21:59] XLT is loaded from local site, loading e:cloverleafcis6.1integrator__Flagler_Master/Tables/Normalized_GenderCode_v2.tbl from master site
[pti :sign:WARN/0:  proc5_xlate:10/12/2015 12:21:59] Thread 1 ( proc5_xlate ) received signal EXCEPTION_ACCESS_VIOLATION:
[pti :sign:WARN/0:  proc5_xlate:–/–/—- –:–:–]   The thread attempted to read from or write to a virtual address for which it does not have the appropriate access.
[pti :sign:WARN/0:  proc5_xlate:10/12/2015 12:21:59] PC = 0xffffffff
PANIC: “0”
PANIC: Calling “pti” for thread proc5_cmd
—– Scheduler State —–
Thread Events     State      Priority Runnable  PT Msgs
  0      0   SCHED_IDLE         0       0       0,0,0
  1      0   SCHED_RUNNING      0       0       1,0,0

————– Thread 0 (proc5_cmd)————–
ti: 0x00DFAB90
   tid           :    0
   HostPthreadId : 0x00000000
   EventList     : 0x00DDF648
   PolledEvents  : 0x00DDF660
   PthreadEvent  : 0x00DFBDB0
   ReadyEvents   : 0x00DFD238
   CtrlMsgs      : 0x00DFD250
   UserCtrlMsgs  : 0x00DFD268
   UserDataMsgs  : 0x00DFD280
   StartArgs     : 0x00000000
   SchedState    : SCHED_IDLE
   SchedPriority : 0
   Killed        : 0
—– Registered Events —–
el: 0x00DDF648
   elCount : 2
   elHead: 0x00DFD2B0
   elTail: 0x02CBB750
ele: 0x00DFD2B0
   event: 0x00DFBDB0
   prev : 0x0
   next : 0x2cbb750
ev: 0xdfbdb0
    evType     : PTHREADS
    evStrDesc    :
    evSocket     : 0
    evHandle     : 0
    evMsgQue     : 0
    evTid        : 0
    evState      : 0
    evPtMsg      : 0x0
    evUserData   : 0x0
    evCallBack   : 0x0
    evCbShutdown : 0x0
    evRecurFreq  :
ele: 0x02CBB750
   event: 0x02C02E08
   prev : 0xdfd2b0
   next : 0x0
ev: 0x2c02e08
    evType     : SOCKET
    evStrDesc    : Command port listen
    evSocket     : 1156
    evHandle     : 0
    evMsgQue     : 0
    evTid        : 0
    evState      : 0
    evPtMsg      : 0x0
    evUserData   : 0x2cb4910
    evCallBack   : 0x40cb10
    evCbShutdown : 0x40d290
    evRecurFreq  :
—– Polled Events —–
el: 0x00DDF660
   elCount : 0
   elHead: 0x00000000
   elTail: 0x00000000
—– Ready Events —–
el: 0x00DFD238
   elCount : 0
   elHead: 0x00000000
   elTail: 0x00000000
—– Outstanding Pthread Ctrl Msgs —–
pmq: 0x00DFD250
Count   : 0
Head    : 0x00000000
Tail    : 0x00000000
—– Outstanding Pthread User Ctrl Msgs —–
pmq: 0x00DFD268
Count   : 0
Head    : 0x00000000
Tail    : 0x00000000
—– Outstanding Pthread User Data Msgs —–
pmq: 0x00DFD280
Count   : 0
Head    : 0x00000000
Tail    : 0x00000000

————– Thread 1 (proc5_xlate)————–
ti: 0x02F9BA18
   tid           :    1
   HostPthreadId : 0x000004A4
   EventList     : 0x0304B7A0
   PolledEvents  : 0x0304B5A8
   PthreadEvent  : 0x02DAC1D0
   ReadyEvents   : 0x0304B1B8
   CtrlMsgs      : 0x0304B5D8
   UserCtrlMsgs  : 0x0304B290
   UserDataMsgs  : 0x0304B2A8
   StartArgs     : 0x030660F8
   SchedState    : SCHED_RUNNING
   SchedPriority : 0
   Killed        : 1
—– Registered Events —–
el: 0x0304B7A0
   elCount : 5
   elHead: 0x0304B500
   elTail: 0x034364B0
ele: 0x0304B500
   event: 0x02DAC1D0
   prev : 0x0
   next : 0x304b2d8
ev: 0x2dac1d0
    evType     : PTHREADS
    evStrDesc    :
    evSocket     : 0
    evHandle     : 0
    evMsgQue     : 0
    evTid        : 1
    evState      : 0
    evPtMsg      : 0x0
    evUserData   : 0x3066438
    evCallBack   : 0x50d040
    evCbShutdown : 0x50d1e0
    evRecurFreq  :
ele: 0x0304B2D8
   event: 0x02DAC270
   prev : 0x304b500
   next : 0x304b518
ev: 0x2dac270
    evType     : SOCKET
    evStrDesc    : ICL Server Listen
    evSocket     : 1432
    evHandle     : 0
    evMsgQue     : 0
    evTid        : 1
    evState      : 0
    evPtMsg      : 0x0
    evUserData   : 0x3064878
    evCallBack   : 0x50cf20
    evCbShutdown : 0x50d1e0
    evRecurFreq  :
ele: 0x0304B518
   event: 0x02DAC3B0
   prev : 0x304b2d8
   next : 0x3436480
ev: 0x2dac3b0
    evType     : POLLED
    evStrDesc    :
    evSocket     : 0
    evHandle     : 0
    evMsgQue     : 0
    evTid        : 1
    evState      : 2
    evPtMsg      : 0x0
    evUserData   : 0x2fd1210
    evCallBack   : 0x521f40
    evCbShutdown : 0x0
    evRecurFreq  :
ele: 0x03436480
   event: 0x030E9408
   prev : 0x304b518
   next : 0x34364b0
ev: 0x30e9408
    evType     : NT_EVENT
    evStrDesc    : New Thread
    evSocket     : 0
    evHandle     : 1444
    evMsgQue     : 0
    evTid        : 1
    evState      : 0
    evPtMsg      : 0x0
    evUserData   : 0x3442000
    evCallBack   : 0x5259a0
    evCbShutdown : 0x0
    evRecurFreq  :
ele: 0x034364B0
   event: 0x030E8558
   prev : 0x3436480
   next : 0x0
ev: 0x30e8558
    evType     : NT_EVENT
    evStrDesc    : Xlate thread Eng Event
    evSocket     : 0
    evHandle     : 1504
    evMsgQue     : 0
    evTid        : 1
    evState      : 0
    evPtMsg      : 0x0
    evUserData   : 0x2fd1210
    evCallBack   : 0x5212c0
    evCbShutdown : 0x0
    evRecurFreq  :
—– Polled Events —–
el: 0x0304B5A8
   elCount : 1
   elHead: 0x0304B260
   elTail: 0x0304B260
ele: 0x0304B260 — POLLED event: 0x02DAC3B0
—– Ready Events —–
el: 0x0304B1B8
   elCount : 0
   elHead: 0x00000000
   elTail: 0x00000000
—– Outstanding Pthread Ctrl Msgs —–
pmq: 0x0304B5D8
Count   : 1
Head    : 0x03470018
Tail    : 0x03470018
PthreadMsg: 0x03470018
   ptmType   : 1
   ptmSender : 1
   ptmCtrl   : 3358
   ptmNext   : 0x00000000
   ptmDataPtr: 0x00000000
   ptmDataInt: 0
—– Outstanding Pthread User Ctrl Msgs —–
pmq: 0x0304B290
Count   : 0
Head    : 0x00000000
Tail    : 0x00000000
—– Outstanding Pthread User Data Msgs —–
pmq: 0x0304B2A8
Count   : 0
Head    : 0x00000000
Tail    : 0x00000000

PANIC: Calling “dbi shutdown” for thread proc5_cmd
PANIC: Calling “dbi shutdown” for thread proc5_xlate
PANIC: Process panic—engine going down
PANIC: assertion ‘0’ failed at PthreadInterface.cpp/766

Topic

[Daniel Lee]

I’ve figured out the problem but have no idea why it’s a problem.  Seems like a bug to me but I have found a workaround.

The problem is with my variant.  I’m trying to use one variant for all message types so I do not have to write and maintain multiple Xlates.  The problem is that with an A01, A08, and A04 the OBX segments are before the DG1 and for A03’s the OBX segments are after the DG1.  To avoid having to create multiple Xlates I built my variants as follows:

Code:

MSH
[{SFT}]]
EVN
PID
[
 PV1
 [PV2]
 [{OBX}]
]
[
 [{DG1}]
 [{OBX}]
]

I’m also not copying the DG1 segments to my outbound variant.

So, I’m not sure why the IF @vitalsInd ne =0 causes a problem when trying to copy the OBX segments to the second group but when I changed my code to write them to the first group it fixed the problem.

I do understand why the variant would get confused but what I don’t understand is what is the difference between a “ne” and “eq”.  Why would a “ne” cause problems but an “eq” did not?

Anyways, this works now so I’m ok.

[Author]

Replies