It looks like this particular T2 driver test involves multiple connections. With the multiple Cmp context per CLI context, we might be deleting the same CmpContext again and again. This issue have a different stack trace in debug mode. The debug mode asserts while deleting the CmpContext.
#0 0x0000003ce9e328a5 in raise () from /lib64/libc.so.6
#1 0x0000003ce9e34085 in abort () from /lib64/libc.so.6
#2 0x0000003ce9e2ba1e in __assert_fail_base () from /lib64/libc.so.6
#3 0x0000003ce9e2bae0 in __assert_fail () from /lib64/libc.so.6
#4 0x00007fffafd78c94 in NAHeap::doCheckAnyFragment (this=0x7fffa3b88f48,
p=0x7fff9da12bf8) at ../common/NAMemory.cpp:3916
#5 0x00007fffafd78f0d in NAHeap::doCheckInuseFragment (this=0x7fffa3b88f48,
p=0x7fff9da12bf8) at ../common/NAMemory.cpp:3945
#6 0x00007fffafd774c5 in NAHeap::deallocateHeapMemory (this=0x7fffa3b88f48,
addr=0x7fff9da12c08) at ../common/NAMemory.cpp:3495
#7 0x00007fffafd72df3 in NAMemory::deallocateMemory (this=0x7fffa3b88f48,
addr=0x7fff9da12c08) at ../common/NAMemory.cpp:1391
#8 0x00007fffb014df57 in CmpContext::deleteInstance (
parentHeap=0x7fffa3b88f48) at ../arkcmp/CmpContext.cpp:364
#9 0x00007fffaed172f4 in ContextCli::deleteMe (this=0x7fffa3b88f38)
at ../cli/Context.cpp:427
#10 0x00007fffaed4274b in CliGlobals::dropContext (this=0x1bbba90,
context=0x7fffa3b88f38) at ../cli/Globals.cpp:611
#11 0x00007fffaece94be in SQLCLI_DropContext (cliGlobals=0x1bbba90,
context_handle=2004) at ../cli/Cli.cpp:1818
#12 0x00007fffaece8924 in SQLCLI_DeleteContext (cliGlobals=0x1bbba90,
context_handle=2004) at ../cli/Cli.cpp:1406
#13 0x00007fffaed79d03 in SQL_EXEC_DeleteContext (contextHandle=2004)
#14 0x00007fffb10ff425 in DISCONNECT (pSrvrConnect=0x2acd4e0)
at native/SqlInterface.cpp:2844
#15 0x00007fffb10edf40 in SRVR_CONNECT_HDL::sqlClose (this=0x2acd4e0)
at native/CSrvrConnect.cpp:156
#16 0x00007fffb110c60b in Java_org_trafodion_jdbc_t2_SQLMXConnection_close (
jenv=0x6259e8, jcls=0x7ffff6b3e390, server=0x0, dialogueId=44881120)
at native/SQLMXConnection.cpp:252
#17 0x00007ffff31cb7f8 in ?? ()
#18 0x00007ffff6b3e340 in ?? ()
#19 0x00007ffff6b3e398 in ?? ()
#20 0x00007ffff6b3e398 in ?? ()
#21 0x00007ffff31bf350 in ?? ()
#22 0x00007ffff6b3e340 in ?? ()
#23 0x0000000000000000 in ?? ()
In release mode, this assert is ignored due to the infamous change in NAAbort and hence we get into different stack trace confusing the whole issue. Assigning this issue back to Aruna to assign it to compiler team.
It looks like this particular T2 driver test involves multiple connections. With the multiple Cmp context per CLI context, we might be deleting the same CmpContext again and again. This issue have a different stack trace in debug mode. The debug mode asserts while deleting the CmpContext.
#0 0x0000003ce9e328a5 in raise () from /lib64/libc.so.6 :doCheckAnyFrag ment (this=0x7fffa3b 88f48, 12bf8) at ../common/ NAMemory. cpp:3916 :doCheckInuseFr agment (this=0x7fffa3b 88f48, 12bf8) at ../common/ NAMemory. cpp:3945 :deallocateHeap Memory (this=0x7fffa3b 88f48, 0x7fff9da12c08) at ../common/ NAMemory. cpp:3495 :deallocateMemo ry (this=0x7fffa3b 88f48, 0x7fff9da12c08) at ../common/ NAMemory. cpp:1391 :deleteInstance ( 0x7fffa3b88f48) at ../arkcmp/ CmpContext. cpp:364 :deleteMe (this=0x7fffa3b 88f38) Context. cpp:427 :dropContext (this=0x1bbba90, 0x7fffa3b88f38) at ../cli/ Globals. cpp:611 0x1bbba90, handle= 2004) at ../cli/Cli.cpp:1818 DeleteContext (cliGlobals= 0x1bbba90, handle= 2004) at ../cli/Cli.cpp:1406 DeleteContext (contextHandle= 2004) 0x2acd4e0) SqlInterface. cpp:2844 HDL::sqlClose (this=0x2acd4e0) CSrvrConnect. cpp:156 trafodion_ jdbc_t2_ SQLMXConnection _close ( e390, server=0x0, dialogueId= 44881120) SQLMXConnection .cpp:252
#1 0x0000003ce9e34085 in abort () from /lib64/libc.so.6
#2 0x0000003ce9e2ba1e in __assert_fail_base () from /lib64/libc.so.6
#3 0x0000003ce9e2bae0 in __assert_fail () from /lib64/libc.so.6
#4 0x00007fffafd78c94 in NAHeap:
p=0x7fff9da
#5 0x00007fffafd78f0d in NAHeap:
p=0x7fff9da
#6 0x00007fffafd774c5 in NAHeap:
addr=
#7 0x00007fffafd72df3 in NAMemory:
addr=
#8 0x00007fffb014df57 in CmpContext:
parentHeap=
#9 0x00007fffaed172f4 in ContextCli:
at ../cli/
#10 0x00007fffaed4274b in CliGlobals:
context=
#11 0x00007fffaece94be in SQLCLI_DropContext (cliGlobals=
context_
#12 0x00007fffaece8924 in SQLCLI_
context_
#13 0x00007fffaed79d03 in SQL_EXEC_
#14 0x00007fffb10ff425 in DISCONNECT (pSrvrConnect=
at native/
#15 0x00007fffb10edf40 in SRVR_CONNECT_
at native/
#16 0x00007fffb110c60b in Java_org_
jenv=0x6259e8, jcls=0x7ffff6b3
at native/
#17 0x00007ffff31cb7f8 in ?? ()
#18 0x00007ffff6b3e340 in ?? ()
#19 0x00007ffff6b3e398 in ?? ()
#20 0x00007ffff6b3e398 in ?? ()
#21 0x00007ffff31bf350 in ?? ()
#22 0x00007ffff6b3e340 in ?? ()
#23 0x0000000000000000 in ?? ()
In release mode, this assert is ignored due to the infamous change in NAAbort and hence we get into different stack trace confusing the whole issue. Assigning this issue back to Aruna to assign it to compiler team.