I’m running into the same thing in our non-prd env, following an upgrade from 6.2.2 to 6.2.6. Even with verbosity turned up, there doesn’t appear to be any other related logging.
I have a ticket open with cloverleaf and they couldn’t find the source of the problem either and have been unable to reproduce. I have found that if I stop the thread, the process won’t die until a new message comes in.
The process will stay up until a message comes in. Below is the error I’m getting. It looks like it’s trying to write a null value to the recovery DB. If I turn off the recovery DB I’m able to stop/start the threads without issue. I tried this with both tcpip and pdl-tcpip to rule out the PDL.
[pdl :PDL :DBUG/0: adt_mt:05/13/2020 08:31:52] IDLE and 4581 bytes but no error: starting READ
[pdl :PDL :DBUG/2: adt_mt:05/13/2020 08:31:52] PDL changed states: old 0, new 1
[pdl :PDL :DBUG/0: adt_mt:05/13/2020 08:31:52] Calling Tcl procedure: hci_pd.read
[pdl :PDL :DBUG/0: adt_mt:05/13/2020 08:31:52] with args: {}
[pdl :PDL :DBUG/0: adt_mt:05/13/2020 08:31:52] Tcl procedure hci_pd.read returns ‘RECEIVE’
[pdl :PDL :DBUG/0: adt_mt:05/13/2020 08:31:52] trying to match phrase: basic-msg
[pdl :PDL :DBUG/0: adt_mt:05/13/2020 08:31:52] multi_phrase_2: status = ok
[pdl :PDL :DBUG/0: adt_mt:05/13/2020 08:31:52] Calling Tcl procedure: read.done
[pdl :PDL :DBUG/0: adt_mt:05/13/2020 08:31:52] with args: {{status ok} {end {4581 0}} {data {1 4578}}}
[dbi :rlog:DBUG/3: adt_mt:05/13/2020 08:31:52] [0.0.19891] Looking for mid in recovery db
[dbi :dbi :DBUG/1: adt_mt:05/13/2020 08:31:52] (0) ‘cl_keyfindlock: About to do d_keylock’
[dbi :dbi :DBUG/1: adt_mt:05/13/2020 08:31:52] (1000) ‘cl_keyfindlock: About to do d_keyfind, keyval:’
[msg :Mid :DBUG/3: adt_mt:05/13/2020 08:31:52] Assigned mid [0.0.19891] to msg 0x7f0970018950
[msg :Msg :DBUG/0: adt_mt:05/13/2020 08:31:52] msg_Alloc new message 0x0x7f0970018950
[pdl :PDL :DBUG/0: adt_mt:05/13/2020 08:31:52] Tcl procedure read.done returns ”
[pdl :PDL :DBUG/2: adt_mt:05/13/2020 08:31:52] PDL changed states: old 1, new 0
[pdl :read:DBUG/1: adt_mt:05/13/2020 08:31:52] PDL did read msg: code = 0
[pd :pdtd:INFO/0: adt_mt:05/13/2020 08:31:52] [0.0.19885] Received msg from driver
[pd :thrd:INFO/0: adt_mt:05/13/2020 08:31:52] [0.0.19885] Placing msg on IB pre-SMS queue.
[pd :pdtd:INFO/3: adt_mt:05/13/2020 08:31:52] [0.0.19885] IB pre-SMS message details
[the msg is here]
[msg :Msg :INFO/0: adt_mt:05/13/2020 08:31:52] [0.0.19885] Writing to recovery database
[dbi :rlog:INFO/1: adt_mt:05/13/2020 08:31:52] [0.0.19885] Write msg to recovery db w/state IB pre-SMS
[dbi :log :DBUG/2: adt_mt:05/13/2020 08:31:52] log context: type 1, dbn 1, msgRec 10001, mdRec 10002, bodyRec 10003
[dbi :log :DBUG/2: adt_mt:05/13/2020 08:31:52] state 1, mode 0
terminate called after throwing an instance of ‘std::logic_error’
what(): basic_string::_S_construct NULL not valid
I was seeing the same, also with both tcpip and pdl-tcpip/mlp_tcp.pdl. Opened a ticket this morning, if only so Infor is aware this affects more than one customer.
I think I have spoken to both people experiencing this, one by phone and other on a webex. If anyone else encounters and creates an incident please mention my name in first event note. I want to stay on top of this.
We also recently migrated from Cloverleaf 6.2.3 to 6.2.6, and having the same issue as mentioned in the original ticket. As a workaround we switch the thread autostart mode off, and then stop specific threads for any testing or validations.
We have encountered this issue as well after installing 6.2.6.0.
I have opened a support ticket.
The last message that we get in the process log before it dies is
WARNING: Message [0.0.149720326] is in the RDB and was left bound into Tcl
terminate called after throwing an instance of ‘std::logic_error’
what(): basic_string::_S_construct null not valid
Anyone find a work around or is the solution to load the 6.2.6.1 patch
Not sure what OS version you are on but for us it is RHEL 6.5 which is no longer supported. There are libraries missing from this version that are required. I found that the process would stay up until a message came in and then the process died.
It’s a BUG – Solution is HOT FIX – 6.2.6.1 per support – to bad I missed the critical fix notification before I loaded 6.2.6.0 into our production environment – now to get another downtime to load the fix.. just is life of an interface engineer I guess..
.
.