signal 11 on outbound process panicked a process

[Jay Yeiser]

A signal 11 message on an outbound thread panicked the process.  Anyone know what signal 11 means and why that would have panicked the process?

Topic

[Jim Kosloskey]

Jay,

Can you share any more information?

What release of CL, what is the state of the engine at the time the panic occurs, is there anything in the log prior to the panic?

Do all of the OB threads have proper reply handling setup (there are posts herein indicating Signal 11 related to improper reply handling).

Has anything changed in the process recently?

Is there any Tcl involved and has any of that changed recently?

Signal 11 generally means a memory segment fault and there can be many reasons the signal is thrown, like referencing memory out of bounds, referencing non-existent memory, etc.

email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.

[Carl Tosi]

We also got a signal 11, which made the process drop, along with all of the associated threads.

We just migrated from 6.0 to 6.2.0 running on Linux.

I looked at other responses in clovertech on this issue. Some users stated that in previous versions of cloverleaf, to check the Timeout Handling and make sure it was set to the default of ‘resend OB message’. I’ve checked that and everything is ok.

Support suggested that I replace check_ack in the TPS inbound reply. Has anyone tried this? I’m leery on doing this.

Thanks,

Carl Tosi

[Carl Tosi]

In reference to previous post, support suggested I replace the check_ack with hcitpsmsgkill.

Thanks again,

Carl Tosi  8)

[Jim Kosloskey]

What if the receiving system sends a negative acknowledgment?

Just saying…

Were it me, I would fix my reply handling proc rather than just unilaterally throw away all replies.

email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.

[Steve Herber]

We upgraded to

hciversion version: 6.2.2.0P, built: Thu May 17 2018

last week.  We have had the signal 11 error in two different sites, one yesterday, and another today.  Both occurred while in our resend logic.

I wonder if this problem is solved by the 6.2.3.0 version I just discovered?

[prod:prod:INFO/1:to_scca_raw_siu:11/14/2018 12:40:33] Got signal 11, stacktrace: 10065dac 300080a8 100337

88 100339ec 10048158 10048400 100474e8 10045414 1053684c 10058090 d052ad08 00000000

[prod:prod:INFO/0:to_scca_raw_siu:11/14/2018 12:40:33] Stack backtrace have been written to crashInfo file

[pti :sign:WARN/0:to_scca_raw_siu:11/14/2018 12:40:33] Thread 2 ( to_scca_raw_siu ) received signal 11

[pti :sign:WARN/0:to_scca_raw_siu:11/14/2018 12:40:33] PC = 0x10065dac

PANIC: “0”

PANIC: Calling “pti” for thread p_raw_01_cmd

---

Scheduler State

---

Thread Events     State      Priority Runnable  PT Msgs

  0      0   SCHED_IDLE         0       0       0,0,0

  1      0   SCHED_IDLE         0       0       0,0,0

  2      0   SCHED_RUNNING      0       0       1,0,0

  3      0   SCHED_IDLE         0       0       0,0,0

  4      0   SCHED_IDLE         0       0       0,0,0

  5      0   SCHED_IDLE         0       0       0,0,0

  6      0   SCHED_IDLE         0       0       0,0,0

Steve Herber
University of Washington

[Author]

Replies