Multi-threading bug on GTK

瀏覽次數:9 次
跳到第一則未讀訊息

Neil Hodgson

未讀,
2022年7月5日 清晨7:47:112022/7/5
收件者:Scintilla mailing list、scite-i...@googlegroups.com
Today I found a bug with multi-threaded text measurement for encodings other than UTF-8. Converter objects could be called by multiple threads without synchronization. This could lead to bad text placement and potentially writing to out-of-bounds memory. The problem has only been seen so far with binary files - not text files and occurred when I ran "SciTE scite/gtk/*” which opened a whole lot of files, ending up with “Widget.o” selected. There may be other requirements for the bug to occur such as text that isn’t valid in the selected encoding but I haven’t been able to narrow the problem down too far.

There is a potential fix committed but I’m not completely certain it is correct as it has changed conversion APIs and the new APIs could have different failure modes. There may also be performance differences - another thing not examined yet.
https://sourceforge.net/p/scintilla/code/ci/c845c79e6d3b9bc5afb1e72b52dc04525fa426da/

For now, GTK applications should disable multi-threaded layout. For Scintilla don’t call SCI_SETLAYOUTTHREADS or set it with the argument 1. For SciTE:
threads.layout=1

https://scintilla.org/ScintillaDoc.html#SCI_SETLAYOUTTHREADS

Neil
回覆所有人
回覆作者
轉寄
0 則新訊息