__intel_avx_rep_memcpy()

The execution of an application query was failing with ORA-07445: exception encountered: core dump [__intel_avx_rep_memcpy()+867] [SIGSEGV] in Oracle 19.15.

The function __intel_avx_rep_memcpy is too generic for narrowing down the problem. Accordingly, there are many unresolved bugs where this function is failing. The call stack, however, doesn’t match any known bugs.

Dynamic Sampling

The incident file revealed that the error was raised during dynamic sampling (DS):

----- Current SQL Statement for this session (sql_id=9pg2198r7avwv) -----
SELECT /* DS_SVC */ /*+ dynamic_sampling(0) no_sql_tune no_monitoring optimizer_features_enable(default) no_parallel  */ NVL(SUM(C1),0) FROM (SELECT /*+ qb_name("innerQuery")  */ 1 AS C1 FROM (SELECT DISTINCT TO_CHAR(...

We immediately switched off DS with the query hint: /*+ dynamic_sampling(0) */. In this case, this was acceptable, because there wasn’t a significant difference in performance of the execution plans with and without DS. However, that might not always be the case. Besides that, the same bug could also affect user queries. This uncertainty prompted me to look for alternative workarounds.

Rowset

Looking closer at the call stack is always a good option for getting the context in which the error was raised. The first place to focus on is around the function where the error was thrown, that is __intel_avx_rep_mem:

...
__intel_avx_rep_mem  signal   __sighandler()       0000001E8 7FEB2B3B0FFB
cpy()+867                                          000000001 000000001 ?
                                                   0179B4D8C ? 006ECE256 ?
ksxb1buf()+715       call     __intel_avx_rep_mem  0000001E8 ? 7FEB2B3B0FFB ?
                              cpy()                000000001 ? 000000001 ?
                                                   0179B4D8C ? 006ECE256 ?
rworupo()+689        call     ksxb1buf()           0000001E8 ? 7FFC7694E4A0
                                                   0000001E8 ? 000000001 ?
                                                   0179B4D8C ? 006ECE256 ?
qerhnWalkMM()+462    call     rworupo()            0000001E8 ? 7FFC7694E4A0 ?
                                                   0000001E8 ? 000000001 ?
                                                   0179B4D8C ? 006ECE256 ?
qerhnProbeRowsetFin  call     qerhnWalkMM()        7FFC7694FD10 000007FFE
ishMMInner()+2180                                  7FEB2CB048F0 7FEB2D50FF48
                                                   7FEB340B3140 006ECE256 ?
qerhnProbeRowsetInn  call     qerhnProbeRowsetFin  7FFC7694FD10 000007FFE
erOnekey()+2231               ishMMInner()         000030000 360DB6920
                                                   7FEB340B3140 ? 7FEB2C329100
qerstRowP()+737      call     qerhnProbeRowsetInn  7FFC00000006 7FEB2C328D08
                              erOnekey()           000030000 ? 360DB6920
                                                   7FEB340B3140 ? 7FFC7694FD10
qerstRowP()+737      call     qerstRowP()          7FFC00000008 7FEB2C449E50
                                                   000030000 ? 360DB6A08
                                                   7FEB340B3140 ? 7FFC7694FD10 ?
kdstf11001010000100  call     qerstRowP()          7FFC00000008 7FEB2C449CD8
0km()+9980                                         000030000 ? 360DB6B40
                                                   7FEB340B3140 ? 7FFC7694FD10 ?
kdsttgr()+2239       call     kdstf11001010000100  7FEB2C449000 000000000
                              0km()                00917E4F0 7FFC7694FB30
                                                   000007FFE 7FFC7694EEA0
qertbFetch()+1090    call     kdsttgr()            7FEB2C449000 ? 000000000 ?
                                                   000000000 ? 7FFC7694FB30 ?
                                                   000007FFE ? 000007FFE
qerstFetch()+449     call     qertbFetch()         7FEB2C449000 ? 000000000 ?
                                                   00917E4F0 7FFC7694FB30 ?
                                                   000007FFE ? 000007FFE ?
...

According the the support note “ORA-600: [qesrLoopOverSetRowP:rows] From Query In Job That Used To Work In 11g (Doc ID 2596180.1)”, the function qerhnProbeRowsetInnishMMInner participates in rowset handling. The rowset feature passes a set of rows from one operation in the execution plan to another during query execution. Switching off the rowset feature also resolved this issue:

alter session set "_rowsets_enabled"=FALSE 

Without the rowset feature, rows are passed one row at a time, which is less efficient and less tested. Therefore, remember to set the parameter to TRUE again after the query execution to avoid side effects on other queries.

alter session set "_rowsets_enabled"=TRUE

Update on October 2nd, 2022

Stefan Koehler suggested an even more granular workaround: to disable rowset functionality only for full table scan (FTS) (as in this case FTS was affected) – by setting the event 10055 to 0x00000001.

Also here, the recommendation is to set it temporarily on the session level just for the affected query.