starred/tview

Fork 0

mirror of https://github.com/rivo/tview.git synced 2026-04-26 21:35:54 +03:00

[GH-ISSUE #636] panic in long textview #463

New issue

Closed

opened 2026-03-04 01:05:13 +03:00 by kerem · 8 comments

kerem commented

2026-03-04 01:05:13 +03:00

Owner

Originally created by @SamWhited on GitHub (Aug 19, 2021).
Original GitHub issue: https://github.com/rivo/tview/issues/636

I'm frequently getting the following (trimmed to relevant parts) panic starting in the textview's draw function at line 1017:

$ go run .
panic: runtime error: index out of range [100] with length 0 [recovered]
        panic: runtime error: index out of range [100] with length 0

goroutine 1 [running]:
github.com/rivo/tview.(*Application).Run.func1()
        /home/sam/go/pkg/mod/github.com/rivo/tview@v0.0.0-20210624165335-29d673af0ce2/application.go:243 +0x4d
panic({0x946f80, 0xc00059b200})
        /home/sam/gotip/src/runtime/panic.go:1038 +0x215
github.com/rivo/tview.(*TextView).Draw(0xc0000bc100, {0xa43700, 0xc000568000})
        /home/sam/go/pkg/mod/github.com/rivo/tview@v0.0.0-20210624165335-29d673af0ce2/textview.go:1017 +0xdf4

EDIT: actually, it appears to happen when I write a lot of text to the text view regardless of whether I'm scrolling. I'm normally at the top of the text view around position 0, then clearing it, then writing a bunch of new things.

Originally created by @SamWhited on GitHub (Aug 19, 2021). Original GitHub issue: https://github.com/rivo/tview/issues/636 I'm frequently getting the following (trimmed to relevant parts) panic starting in the textview's draw function at line 1017: ``` $ go run . panic: runtime error: index out of range [100] with length 0 [recovered] panic: runtime error: index out of range [100] with length 0 goroutine 1 [running]: github.com/rivo/tview.(*Application).Run.func1() /home/sam/go/pkg/mod/github.com/rivo/tview@v0.0.0-20210624165335-29d673af0ce2/application.go:243 +0x4d panic({0x946f80, 0xc00059b200}) /home/sam/gotip/src/runtime/panic.go:1038 +0x215 github.com/rivo/tview.(*TextView).Draw(0xc0000bc100, {0xa43700, 0xc000568000}) /home/sam/go/pkg/mod/github.com/rivo/tview@v0.0.0-20210624165335-29d673af0ce2/textview.go:1017 +0xdf4 ``` **EDIT:** actually, it appears to happen when I write a lot of text to the text view regardless of whether I'm scrolling. I'm normally at the top of the text view around position 0, then clearing it, then writing a bunch of new things.

kerem closed this issue

2026-03-04 01:05:13 +03:00

kerem commented

2026-03-04 01:05:14 +03:00

Author

Owner

@rivo commented on GitHub (Sep 12, 2021):

Please see https://github.com/rivo/tview/wiki/Concurrency. Most of the functions are not thread-safe. You need to take care of that yourself. (The Write() function is an exception and I'm not sure if, for consistency reasons, it should've been like the other functions.)

@rivo commented on GitHub (Sep 12, 2021): Please see https://github.com/rivo/tview/wiki/Concurrency. Most of the functions are not thread-safe. You need to take care of that yourself. (The `Write()` function is an exception and I'm not sure if, for consistency reasons, it should've been like the other functions.)

kerem commented

2026-03-04 01:05:14 +03:00

Author

Owner

@SamWhited commented on GitHub (Sep 12, 2021):

This is all happening synchronously and there should be no race possible here.

EDIT: unless something else is triggering a redraw maybe? I don't think I can reasonably control when redraws happen though, nor can I wrap them in a mutex or anything so I'm not sure what to do if that were the culprit.

@SamWhited commented on GitHub (Sep 12, 2021): This is all happening synchronously and there should be no race possible here. **EDIT:** unless something else is triggering a redraw maybe? I don't think I can reasonably control when redraws happen though, nor can I wrap them in a mutex or anything so I'm not sure what to do if that were the culprit.

kerem commented

2026-03-04 01:05:14 +03:00

Author

Owner

@rivo commented on GitHub (Sep 12, 2021):

I don't see your code so it's hard to say. Do you write to the TextView using the io.Writer interface, calling Clear() periodically? And other parts of the program could cause a non-main-thread redraw. Is this a correct assumption?

@rivo commented on GitHub (Sep 12, 2021): I don't see your code so it's hard to say. Do you write to the `TextView` using the `io.Writer` interface, calling `Clear()` periodically? And other parts of the program could cause a non-main-thread redraw. Is this a correct assumption?

kerem commented

2026-03-04 01:05:14 +03:00

Author

Owner

@SamWhited commented on GitHub (Sep 12, 2021):

I think so, I haven't managed to get this into an easily reproducible form, and it's been long enough that I don't really remember what was happening now. It is possible (though unlikely, I think?) that other areas of the code could be calling app.Redraw() which could be trickling down to this.

I'm not really calling Clear periodically, just calling Clear then writing some new text with the writer interface.

@SamWhited commented on GitHub (Sep 12, 2021): I think so, I haven't managed to get this into an easily reproducible form, and it's been long enough that I don't really remember what was happening now. It is possible (though unlikely, I think?) that other areas of the code could be calling `app.Redraw()` which could be trickling down to this. I'm not really calling Clear periodically, just calling Clear then writing some new text with the writer interface.

kerem commented

2026-03-04 01:05:14 +03:00

Author

Owner

@SamWhited commented on GitHub (Sep 17, 2021):

I have tested this, I still get the panic even with locking around the scrolling. I am also certain that nothing is being cleared during the scroll (it is possible that it is being redrawn though).

@SamWhited commented on GitHub (Sep 17, 2021): I have tested this, I still get the panic even with locking around the scrolling. I am also certain that nothing is being cleared during the scroll (it is possible that it is being redrawn though).

kerem commented

2026-03-04 01:05:14 +03:00

Author

Owner

@rivo commented on GitHub (Sep 23, 2021):

Responding to https://github.com/rivo/tview/pull/641#issuecomment-925438772 here: This is actually what I would like to suggest. In fact, if it weren't for backwards compatibility, I'd probably even remove the lock from the Write() function and leave everything up to the user.

When I implemented this, I was under the impression that implementing the io.Writer interface required thread safety so I introduced a mutex. Now it's a bit inconsistent, leading to the confusion outlined in this issue. That's my bad.

But removing the lock completely might break existing implementations. I'm very reluctant to do this.

@rivo commented on GitHub (Sep 23, 2021): Responding to https://github.com/rivo/tview/pull/641#issuecomment-925438772 here: This is actually what I would like to suggest. In fact, if it weren't for backwards compatibility, I'd probably even remove the lock from the `Write()` function and leave everything up to the user. When I implemented this, I was under the impression that implementing the `io.Writer` interface required thread safety so I introduced a mutex. Now it's a bit inconsistent, leading to the confusion outlined in this issue. That's my bad. But removing the lock completely might break existing implementations. I'm very reluctant to do this.

kerem commented

2026-03-04 01:05:14 +03:00

Author

Owner

@SamWhited commented on GitHub (Sep 23, 2021):

As much as it clutters the API, I wonder if for backwards compatibility purposes we could use two constructors for this? eg. the existing NewTextView would continue to work as sis, but NewTextViewUnsafe or something would create one with an internal property set that skips over the locking?

EDIT: I have a better idea (I think); I will flush it out and then open a PR to suggest it if it works.

@SamWhited commented on GitHub (Sep 23, 2021): As much as it clutters the API, I wonder if for backwards compatibility purposes we could use two constructors for this? eg. the existing `NewTextView` would continue to work as sis, but `NewTextViewUnsafe` or something would create one with an internal property set that skips over the locking? *EDIT:* I have a better idea (I think); I will flush it out and then open a PR to suggest it if it works.

kerem commented

2026-03-04 01:05:14 +03:00

Author

Owner

@SamWhited commented on GitHub (Oct 22, 2021):

Closing as this specific issue is "fixed" in so far as I know why it's happening and can work around it (I think). Please consider #652 as a follow up that would remove the need for my hacky work arounds. Thanks!

@SamWhited commented on GitHub (Oct 22, 2021): Closing as this specific issue is "fixed" in so far as I know why it's happening and can work around it (I think). Please consider #652 as a follow up that would remove the need for my hacky work arounds. Thanks!