Thanks for tackling this. I have recorded a few of those errors also in #653.
There already is a section in the code that initializes the slice and I think it's a race on the table.rawRows field.
Sometimes it is using locking but sometimes it doesn't.

@edlerd I have created #807 to track the progress. Do you want to look into it? Please also check my comment above.

@edlerd I have created #807 to track the progress. Do you want to look into it? Please also check my comment above.

Sure I opened this to fix it :)

There already is a section in the code that initializes the slice and I think it's a race on the table.rawRows field.

Looking at the context of the change, I can't see how this would get initialized in another code path. The allRows object is defined within the function, and we need to allocate memory for the items that are copied in. I think this only ever passes without panic in case the passed in i.table.rawRows has no nested arrays. See below for full context of the function.

Looking at the context of the change, I can't see how this would get initialized

I am talking about the struct's rawRows, not the function local allRows. Almost the same name though :)

There are the the two handleRemoveEvent and handleInsertEvent which both update the struct's rawRows without obtaining the tableMu lock. So I have the suspicion that one of those two funcs is called whilst the getAllRows is called which is causing the panic.

There are the the two handleRemoveEvent and handleInsertEvent which both update the struct's rawRows without obtaining the tableMu lock. So I have the suspicion that one of those two funcs is called whilst the getAllRows is called which is causing the panic.

Thanks for clarifying, I see what you mean. Both event handlers could mess up the length of the raw rows when changing them under the hood without locking.

@roosterfish unfortunately we don't have access to the table mutex in the event handlers. But I think there is an easy way out. We only ever interest the number of the table rows, so we can avoid the copy all together and just return the count in our helper function.

Good catch that we don't even require the data from getAllRows but instead we just need the number.

Now I think we don't even need to obtain the tableMu lock. Also the only other user is the Render func which isn't called concurrently as we only ever render one table at a time.
So we can get rid of tableMu sync.Mutex completely on the handler.

Instead we should have a mutex on the selectableTable whenever we add/delete rows to the table. And then we can have another func on selectableTable which obtains the lock and gets the len of the rows. This func can then be called by countAllRows of the handler.
This way we always have the right information about len.

Now I think we don't even need to obtain the tableMu lock. Also the only other user is the Render func which isn't called concurrently as we only ever render one table at a time. So we can get rid of tableMu sync.Mutex completely on the handler.

Instead we should have a mutex on the selectableTable whenever we add/delete rows to the table. And then we can have another func on selectableTable which obtains the lock and gets the len of the rows. This func can then be called by countAllRows of the handler. This way we always have the right information about len.

Right, adjusted the PR to the new mutex inside of the selectable table.