Assert Failed errno 271 ISAM ERR -12803

Hi all, I had some assert failed errors for about 15 minutes and inserting from iib server stopped with following error: Database selected. 271: Could not insert new row into the table. 12803: Error in executing an access_method routine execution sequence. Error in line 2Near character position 210 Database closed. I remember there was a similar issue that was a bug solved in 12.10xC3 same error were given when inserting into virtual table Online.log shows lots if assert failures: 01:38:42 Logical Log 334512 Complete, timestamp: 0x2a0800d9. 01:39:17 Verbose error trapping set, errno = 271, session_id = -1 01:39:17 Assert Failed: found errno 271 in session 17850 01:39:17 Assert Failed: found errno 271 in session 17846 01:39:17 Assert Failed: found errno 271 in session 17867 01:39:17 IBM Informix Dynamic Server Version 12.10.FC7X9 01:39:17 IBM Informix Dynamic Server Version 12.10.FC7X9 01:39:17 IBM Informix Dynamic Server Version 12.10.FC7X9 01:39:17 Who: Session(17846, iib@iib-server, 16585, 0x4c434d38) Thread(65389, sqlexec, 4c3fe8c8, 9) File: rsdebug.c Line: 3398 01:39:17 Who: Session(17867, iib@iib-server, 16585, 0x4c433898) Thread(65410, sqlexec, 4c3fb418, 8) File: rsdebug.c Line: 3398 01:39:17 Who: Session(17850, iib@iib-server, 16585, 0x4c43a698) Thread(65393, sqlexec, 4c40cd18, 12) File: rsdebug.c Line: 3398 01:39:17 Assert Failed: found errno 271 in session 17844 01:39:17 Assert Failed: found errno 271 in session 17817 01:39:17 Assert Failed: found errno 271 in session 17856 01:39:17 Assert Failed: found errno 271 in session 17868 01:39:17 Action: Use onmode -I to stop verbose error trapping. 01:39:17 Action: Use onmode -I to stop verbose error trapping. 01:39:17 Assert Failed: found errno 271 in session 17852 01:39:17 Assert Failed: found errno 271 in session 17848 01:39:17 IBM Informix Dynamic Server Version 12.10.FC7X9 01:39:17 Assert Failed: found errno 271 in session 17865 01:39:17 Who: Session(17856, iib@iib-server, 16585, 0x4c43bea8) Thread(65399, sqlexec, 4c410a90, 1) File: rsdebug.c Line: 3398 01:39:17 Assert Failed: found errno 271 in session 17840 01:39:17 stack trace for pid 1026 written to /opt/IBM/informix_FC7/tmp/af.36ad5a5 01:39:17 IBM Informix Dynamic Server Version 12.10.FC7X9 01:39:17 IBM Informix Dynamic Server Version 12.10.FC7X9 01:39:17 Who: Session(17865, iib@iib-server, 16585, 0x4c43c588) Thread(65408, sqlexec, 4c411c20, 17) File: rsdebug.c Line: 3398 01:39:17 Who: Session(17852, iib@iib-server, 16585, 0x4c4349c8) Thread(65395, sqlexec, 4c3fe000, 16) File: rsdebug.c Line: 3398 01:39:17 Action: Use onmode -I to stop verbose error trapping. I uploaded some onstats here: http://m.uploadedit.com/ba3s/1484561471501.txt did anyone encountered this ?

Hi, those many assertions obviously were due to an error trap active for errno = 271 and multiple sessions hitting this condition (-271/-12803)=20 simultaneously, all for inserts into api=5Fjson=5Fvt table. That old defect was for primary key columns following after timeseries=20 columns in table schema and should be fixed since 12.10.xC3, what we're=20 seeing here is 12.10.FC7... I'd suggest opening a PMR and dumping shared memory as long as the problem = still persists, to have some good diagnostic materiel just in case the=20 problem goes away when restarting the server or redefining the VT. In case DUMPSHMEM wasn't 0, some of these assertions might even have=20 created shared memory dumps already, but then you'd have to make sure at=20 least one of them is complete. Quickest way to dump shmem (including buffers): onstat -g out full | gzip = > shmem.gz|=20 HTH, Andreas From: "R MICHAEL" <mboncalo@gmail.com> To: ids@iiug.org Date: 16.01.2017 11:17 Subject: Assert Failed errno 271 ISAM ERR -12803 [38512] Sent by: ids-bounces@iiug.org Hi all,=20 I had some assert failed errors for about 15 minutes and inserting from=20 iib=20 server stopped with following error:=20 Database selected.=20 271: Could not insert new row into the table.=20 12803: Error in executing an access=5Fmethod routine execution sequence.=20 Error in line 2=20Near character position 210=20 Database closed.=20 I remember there was a similar issue that was a bug solved in 12.10xC3=20 same=20 error were given when inserting into virtual table=20 Online.log shows lots if assert failures:=20 01:38:42 Logical Log 334512 Complete, timestamp: 0x2a0800d9.=20 01:39:17 Verbose error trapping set, errno =3D 271, session=5Fid =3D -1=20 01:39:17 Assert Failed: found errno 271 in session 17850=20 01:39:17 Assert Failed: found errno 271 in session 17846=20 01:39:17 Assert Failed: found errno 271 in session 17867=20 01:39:17 IBM Informix Dynamic Server Version 12.10.FC7X9=20 01:39:17 IBM Informix Dynamic Server Version 12.10.FC7X9=20 01:39:17 IBM Informix Dynamic Server Version 12.10.FC7X9=20 01:39:17 Who: Session(17846, iib@iib-server, 16585, 0x4c434d38)=20 Thread(65389, sqlexec, 4c3fe8c8, 9)=20 File: rsdebug.c Line: 3398=20 01:39:17 Who: Session(17867, iib@iib-server, 16585, 0x4c433898)=20 Thread(65410, sqlexec, 4c3fb418, 8)=20 File: rsdebug.c Line: 3398=20 01:39:17 Who: Session(17850, iib@iib-server, 16585, 0x4c43a698)=20 Thread(65393, sqlexec, 4c40cd18, 12)=20 File: rsdebug.c Line: 3398=20 01:39:17 Assert Failed: found errno 271 in session 17844=20 01:39:17 Assert Failed: found errno 271 in session 17817=20 01:39:17 Assert Failed: found errno 271 in session 17856=20 01:39:17 Assert Failed: found errno 271 in session 17868=20 01:39:17 Action: Use onmode -I to stop verbose error trapping.=20 01:39:17 Action: Use onmode -I to stop verbose error trapping.=20 01:39:17 Assert Failed: found errno 271 in session 17852=20 01:39:17 Assert Failed: found errno 271 in session 17848=20 01:39:17 IBM Informix Dynamic Server Version 12.10.FC7X9=20 01:39:17 Assert Failed: found errno 271 in session 17865=20 01:39:17 Who: Session(17856, iib@iib-server, 16585, 0x4c43bea8)=20 Thread(65399, sqlexec, 4c410a90, 1)=20 File: rsdebug.c Line: 3398=20 01:39:17 Assert Failed: found errno 271 in session 17840=20 01:39:17 stack trace for pid 1026 written to=20 /opt/IBM/informix=5FFC7/tmp/af.36ad5a5=20 01:39:17 IBM Informix Dynamic Server Version 12.10.FC7X9=20 01:39:17 IBM Informix Dynamic Server Version 12.10.FC7X9=20 01:39:17 Who: Session(17865, iib@iib-server, 16585, 0x4c43c588)=20 Thread(65408, sqlexec, 4c411c20, 17)=20 File: rsdebug.c Line: 3398=20 01:39:17 Who: Session(17852, iib@iib-server, 16585, 0x4c4349c8)=20 Thread(65395, sqlexec, 4c3fe000, 16)=20 File: rsdebug.c Line: 3398=20 01:39:17 Action: Use onmode -I to stop verbose error trapping.=20 I uploaded some onstats here:=20 http://m.uploadedit.com/ba3s/1484561471501.txt=20 did anyone encountered this ?=20 ***************************************************************************= ****=20 Forum Note: Use "Reply" to post a response in the discussion forum.=20

Hi, (resending to test alternate MIME encoding ... hopefully mail will remain=20 more readable by this.) those many assertions obviously were due to an error trap active for errno = 271 and multiple sessions hitting this condition (-271/-12803)=20 simultaneously, all for inserts into api=5Fjson=5Fvt table. That old defect was for primary key columns following after timeseries=20 columns in table schema and should be fixed since 12.10.xC3, what we're=20 seeing here is 12.10.FC7... I'd suggest opening a PMR and dumping shared memory as long as the problem = still persists, to have some good diagnostic materiel just in case the=20 problem goes away when restarting the server or redefining the VT. In case DUMPSHMEM wasn't 0, some of these assertions might even have=20 created shared memory dumps already, but then you'd have to make sure at=20 least one of them is complete. Quickest way to dump shmem (including buffers): onstat -g out full | gzip = > shmem.gz|=20 HTH, Andreas