Sometimes getting the error message slotIdx < slots.size() in function 'getData'

[sfe-SparkFro]

I periodically get the following error message, typically following a soft reset (Ctrl+D):

Exception: OpenCV(4.11.0) /home/dryw/micropython-opencv/src/opencv/modules/core/src/system.cpp:1982: error: (-215:Assertion failed) slotIdx < slots.size() in function 'getData'

This can be resolved by doing a hard reset, but should try to address this so soft resets are safe. Not yet sure what the root problem is.

Will follow up with replication code if I can find something that easily replicates the problem.

[sfe-SparkFro]

Replication code:

import cv2
from ulab import numpy as np
from st7789_spi import ST7789_SPI

display = ST7789_SPI(width=240,
                    height=320,
                    spi_id=0,
                    pin_cs=17,
                    pin_dc=16,
                    rotation=1)

img = np.zeros((240, 320, 3), dtype=np.uint8)

cv2.imshow(display, img)

Run the code above by pasting into the REPL. Then press Ctrl+D to perform a soft reset, and run the code again. The following error message is printed after calling cv2.imshow():

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/lib/st7789_spi.py", line 345, in imshow
  File "/lib/st7789_spi.py", line 327, in _write_image_to_buffer_bgr565
Exception: OpenCV(4.11.0) /home/dryw/micropython-opencv/src/opencv/modules/core/src/system.cpp:1982: error: (-215:Assertion failed) slotIdx < slots.size() in function 'getData'

This happens regardless of whether pasting normally, or in paste mode (Ctrl+E).

[sfe-SparkFro]

File "/lib/st7789_spi.py", line 327, in _write_image_to_buffer_bgr565

This is a call to cv2.cvtColor():

micropython-opencv/drivers/display/st7789_spi.py

Lines 322 to 329 in 4202cb9

	if ch == 1: # Grayscale
	buffer_roi = cv2.cvtColor(image_roi, cv2.COLOR_GRAY2BGR565, buffer_roi)
	elif ch == 2: # Already in BGR565 format
	buffer_roi[:] = image_roi
	elif ch == 3: # BGR
	buffer_roi = cv2.cvtColor(image_roi, cv2.COLOR_BGR2BGR565, buffer_roi)
	else:
	raise ValueError("Image must be 1, 2 or 3 channels (grayscale, BGR565, or BGR)")

Poking around with a debugger shows the exception is being thrown by the underlying C++ call cvtColor():

micropython-opencv/src/imgproc.cpp

Lines 370 to 375 in 4202cb9

	// Call the corresponding OpenCV function
	try {
	cvtColor(src, dst, code);
	} catch(Exception& e) {
	mp_raise_msg(&mp_type_Exception, MP_ERROR_TEXT(e.what()));
	}

Will continue to poke around.

[sfe-SparkFro]

Here's the backtrace when cv::error() is called:

(gdb) bt
#0  0x101f7408 in cv::error (_code=_code@entry=-215, _err=..., _func=<optimized out>, 
    _file=0x1030a374 "/home/dryw/micropython-opencv/src/opencv/modules/core/src/system.cpp", _line=_line@entry=1982)
    at /home/dryw/micropython-opencv/src/opencv/modules/core/src/system.cpp:1287
#1  0x101f9108 in cv::details::TlsStorage::getData (slotIdx=<optimized out>, 
    this=0x2000fab0 <cv::details::getTlsStorage()::g_storage>)
    at /home/dryw/micropython-opencv/src/opencv/modules/core/src/system.cpp:1982
#2  cv::TLSDataContainer::getData (this=<optimized out>)
    at /home/dryw/micropython-opencv/src/opencv/modules/core/src/system.cpp:2078
#3  cv::TLSData<cv::CoreTLSData>::getRef (this=<optimized out>)
    at /home/dryw/micropython-opencv/src/opencv/modules/core/include/opencv2/core/utils/tls.hpp:70
#4  cv::getCoreTlsData ()
    at /home/dryw/micropython-opencv/src/opencv/modules/core/src/system.cpp:2103
#5  0x101ee3c6 in cv::theRNG ()
    at /home/dryw/micropython-opencv/src/opencv/modules/core/src/rand.cpp:656
#6  0x101e8100 in cv::(anonymous namespace)::ParallelLoopBodyWrapperContext::ParallelLoopBodyWrapperContext (_nstripes=<optimized out>, _r=..., _body=..., this=0x20081908) at /home/dryw/micropython-opencv/src/opencv/modules/core/src/parallel.cpp:214
#7  cv::parallel_for_impl (nstripes=<optimized out>, body=..., range=...) at /home/dryw/micropython-opencv/src/opencv/modules/core/src/parallel.cpp:557
#8  cv::parallel_for_ (range=..., body=..., nstripes=<optimized out>) at /home/dryw/micropython-opencv/src/opencv/modules/core/src/parallel.cpp:528
#9  0x1011e6ce in cv::impl::(anonymous namespace)::CvtColorLoop<cv::hal::cpu_baseline::(anonymous namespace)::RGB2RGB5x5> (cvt=..., height=240, width=320, dst_step=640, dst_data=0x20040ee0 "", src_step=960, src_data=0x1102eec0 "") at /home/dryw/micropython-opencv/src/opencv/modules/imgproc/src/color.simd_helpers.hpp:171
#10 cv::hal::cpu_baseline::cvtBGRtoBGR5x5 (src_data=0x1102eec0 "", src_step=960, dst_data=0x20040ee0 "", dst_step=640, width=320, height=240, scn=3, swapBlue=false, greenBits=6) at /home/dryw/micropython-opencv/src/opencv/modules/imgproc/src/color_rgb.simd.hpp:1125
#11 0x1011f208 in cv::hal::cvtBGRtoBGR5x5 (greenBits=6, swapBlue=false, scn=3, height=240, width=320, dst_step=640, dst_data=0x20040ee0 "", src_step=960, src_data=0x1102eec0 "") at /home/dryw/micropython-opencv/src/opencv/modules/imgproc/src/color_rgb.dispatch.cpp:250
#12 cv::cvtColorBGR25x5 (_src=..., _dst=..., swapb=<optimized out>, gbits=6) at /home/dryw/micropython-opencv/src/opencv/modules/imgproc/src/color_rgb.dispatch.cpp:562
#13 0x10111846 in cv::cvtColor (_src=..., _dst=..., code=code@entry=12, dcn=dcn@entry=0, hint=cv::ALGO_HINT_ACCURATE, hint@entry=cv::ALGO_HINT_DEFAULT) at /home/dryw/micropython-opencv/src/opencv/modules/imgproc/src/color.cpp:220
#14 0x10088608 in cv2_imgproc_cvtColor (n_args=<optimized out>, pos_args=<optimized out>, kw_args=<optimized out>) at /home/dryw/micropython-opencv/src/opencv/modules/core/include/opencv2/core/mat.inl.hpp:92
#15 0x100115f6 in fun_builtin_var_call (args=0x20081cdc, n_kw=0, n_args=3, self_in=0x102c94a0 <cv2_imgproc_cvtColor_obj>) at /home/dryw/micropython-opencv/micropython/py/objfun.c:118
#16 fun_builtin_var_call (self_in=0x102c94a0 <cv2_imgproc_cvtColor_obj>, n_args=3, n_kw=0, args=0x20081cdc) at /home/dryw/micropython-opencv/micropython/py/objfun.c:102
#17 0x1001bf16 in mp_execute_bytecode (code_state=code_state@entry=0x20081cc0, inject_exc=inject_exc@entry=0x0) at /home/dryw/micropython-opencv/micropython/py/vm.c:1042
#18 0x10011716 in fun_bc_call (self_in=0x2003ae30, n_args=<optimized out>, n_kw=<optimized out>, args=0x2003efb8) at /home/dryw/micropython-opencv/micropython/py/objfun.c:295
#19 0x1001bf16 in mp_execute_bytecode (code_state=code_state@entry=0x2003efa0, inject_exc=inject_exc@entry=0x0) at /home/dryw/micropython-opencv/micropython/py/vm.c:1042
#20 0x10011716 in fun_bc_call (self_in=0x2003ae40, n_args=<optimized out>, n_kw=<optimized out>, args=0x20081df8) at /home/dryw/micropython-opencv/micropython/py/objfun.c:295
#21 0x1006e674 in cv2_highgui_imshow (n_args=<optimized out>, pos_args=<optimized out>, kw_args=<optimized out>) at /home/dryw/micropython-opencv/src/highgui.cpp:45
#22 0x100115f6 in fun_builtin_var_call (args=0x20081ed8, n_kw=0, n_args=2, self_in=0x102c93c8 <cv2_highgui_imshow_obj>) at /home/dryw/micropython-opencv/micropython/py/objfun.c:118
#23 fun_builtin_var_call (self_in=0x102c93c8 <cv2_highgui_imshow_obj>, n_args=2, n_kw=0, args=0x20081ed8) at /home/dryw/micropython-opencv/micropython/py/objfun.c:102
#24 0x1001bf16 in mp_execute_bytecode (code_state=code_state@entry=0x20081eb8, inject_exc=inject_exc@entry=0x0) at /home/dryw/micropython-opencv/micropython/py/vm.c:1042
#25 0x10011716 in fun_bc_call (self_in=0x2003e9c0, n_args=<optimized out>, n_kw=<optimized out>, args=0x0) at /home/dryw/micropython-opencv/micropython/py/objfun.c:295
#26 0x100316e6 in parse_compile_execute (source=source@entry=0x20081f88, input_kind=<optimized out>, exec_flags=exec_flags@entry=22) at /home/dryw/micropython-opencv/micropython/shared/runtime/pyexec.c:119
#27 0x100319ae in pyexec_friendly_repl () at /home/dryw/micropython-opencv/micropython/shared/runtime/pyexec.c:671
#28 0x10034006 in main (argc=<optimized out>, argv=<optimized out>) at /home/dryw/micropython-opencv/micropython/ports/rp2/main.c:236

[sfe-SparkFro]

The failing assertion appears to be here in system.cpp, within cv::details::TlsStorage::getData(), when CV_Assert(slotIdx < slots.size()) is called

https://github.com/sfe-SparkFro/opencv/blob/8eb737f902be3e0606b865b3e7ef58dcd213609f/modules/core/src/system.cpp#L1979-L1982

---

Looking at the backtrace, cvtColor() eventually creates a ParallelLoopBodyWrapperContext in parallel_for_impl() here:

https://github.com/sfe-SparkFro/opencv/blob/8eb737f902be3e0606b865b3e7ef58dcd213609f/modules/core/src/parallel.cpp#L552-L557

That constructor gets a reference to cv::theRNG() (random number generator), even if is_rng_used = false:

https://github.com/sfe-SparkFro/opencv/blob/8eb737f902be3e0606b865b3e7ef58dcd213609f/modules/core/src/parallel.cpp#L204-L214

Which comes from the CoreTLSData:

https://github.com/sfe-SparkFro/opencv/blob/8eb737f902be3e0606b865b3e7ef58dcd213609f/modules/core/src/rand.cpp#L654-L657

When it attempts to get a reference with getCoreTlsDataTLS().getRef():

https://github.com/sfe-SparkFro/opencv/blob/8eb737f902be3e0606b865b3e7ef58dcd213609f/modules/core/src/system.cpp#L2101-L2104

It calls getTlsStorage().getData(key_):

https://github.com/sfe-SparkFro/opencv/blob/8eb737f902be3e0606b865b3e7ef58dcd213609f/modules/core/src/system.cpp#L2075-L2078

Which then has the failing CV_Assert(slotIdx < slots.size()) (where slotIdx is the key_ from the previous call):

https://github.com/sfe-SparkFro/opencv/blob/8eb737f902be3e0606b865b3e7ef58dcd213609f/modules/core/src/system.cpp#L1980-L1982

With my debugger, slots.size() = 1 in all situations I tested. After a hard reset, key_ = 0, meaning CV_Assert(slotIdx < slots.size()) passes, including on all subsequent calls to cvtColor(). After a soft reset, key_ appears to be set to a bogus value, I've seen both 537118640 and 537122944.

---

My guess right now is that something in OpenCV is getting allocated once in the garbage collector heap, and the pointer persists through soft resets. But when a soft reset occurs, the garbage collector hear is reset, and that pointer is no longer valid.

[sfe-SparkFro]

I think the culprit is getCoreTlsDataTLS():

https://github.com/sfe-SparkFro/opencv/blob/8eb737f902be3e0606b865b3e7ef58dcd213609f/modules/core/src/system.cpp#L2096-L2099

CV_SINGLETON_LAZY_INIT_REF(TLSData<CoreTLSData>, new TLSData<CoreTLSData>())

Expands to:

static TLSData<CoreTLSData>* const instance = new TLSData<CoreTLSData>();
return *instance;

I believe this means that when getCoreTlsDataTLS() is called the first time, it calls malloc(), and all subsequent calls to getCoreTlsDataTLS() just return the same pointer without calling malloc() again, even after a soft reset. However it appears that after a soft reset, that memory location gets overwritten with other data.

---

Testing with a debugger, before performing the soft reset, the TLSDataContainer is at memory address 0x2003c718, and printing the contents shows:

(gdb) p *container
$82 = {_vptr.TLSDataContainer = 0x2000d838 <vtable for cv::TLSDataContainer+8>, 
  key_ = 0}

After a hard reset, the memory address is the same, but the contents are different:

(gdb) p *this
$86 = {<cv::TLSDataContainer> = {_vptr.TLSDataContainer = 0x5, 
    key_ = 537122944}, <No data fields>}

[sfe-SparkFro]

Fixed in a2bf9f2