Geany starts glitch if open a very large text file
File for demonstration: https://drive.google.com/open?id=1xHtXdYx-cUYV0e4yS8PLPILVCcRzfmbG (63.5MB packed size / 2.6 GB unpacked size)
In sublime editor the file opened correctly.
ikhail@localhost ~]$ geany --version geany 1.34.1 (built on 2019-01-05 with GTK 3.24.1, GLib 2.59.0) [mikhail@localhost ~]$ rpm -q geany geany-1.34.1-2.fc30.x86_64
OS: Linux Fedora Rawhide.
What operating system are you on? how much memory does your computer have?
What operating system are you on?
Linux Fedora
how much memory does your computer have?
32GB
Linux Fedora
Would have expected Geany to be built 64 bit on that.
32GB
Ok, Scintilla uses at least double the file size since it has to store styling, so a 2.6GB file won't fit in a 4GB memory but I doubt it would expand to fill 32GB Assume you have no process limits `ulimit -m`
Looks like the same problem, if not a duplicate of #2026, ie not size related, nor Fedora related nor latest version of Geany related.
Nor GTK version related, #2066 is 3.22.30 you are 3.24.1
PS thanks for the test file, can't try it since I'm on a 4GB laptop ATM, but as I said above I doubt thats the problem.
Would have expected Geany to be built 64 bit on that.
I am already sitting on 64 bit Geany.
Ok, Scintilla uses at least double the file size since it has to store styling, so a 2.6GB file won't fit in a 4GB memory but I doubt it would expand to fill 32GB Assume you have no process limits `ulimit -m`
$ ulimit -m unlimited
I'll try to test later today with a more robust computer, but what is the detected encoding? The contents looks oddly correct line-wise, and only line contents seem plain wrong; which could indicate some odd character incorrect character conversion where only a few (including newline) character were correct. Or it might indeed be a Scintilla glitch of some kind.
@b4n, all those NULs showing are unlikely to actually be in the buffer since we won't load NULs, it kind of looks like Scintilla getting itself confused somewhere. Maybe its a glitch in the assistive technology :grin:
``` [mikhail@localhost 15]$ cat gfx.txt | grep freedesktop [mikhail@localhost 15]$ ```
I’m more worried about Geany displaying something that’s not in the file. As if it reading someone else's memory.
Or a GTK bug in 3.22.30 which is still there in 3.24.1.
As if it reading someone else's memory.
or the gap, which Scintilla doesn't initialise IIRC, although the OS should clear it when handing it out, BAD Linus!!!
or an equally likely possibility is when Scintilla sends line segments to Pango either Pango or Scintilla reads parts of the stack beyond or prior to the actual text
Looking at the size and doing a few tests suggests it might be due to us still using signed 32 bits integers for holding positions and alike. Maybe even in Scintilla, that might require a specific define to use 64bits positions. This would mean trouble when the file size is greater than `(1 << 31) - 1`, which your file definitely is. I'll try and dig a little more, but it might be far from trivial to fix ATM :confused:
Scintilla 4.0.5 (10 May 2018) added`SC_DOCUMENTOPTION_TEXT_LARGE` https://www.scintilla.org/ScintillaDoc.html#SCI_CREATEDOCUMENT
addedSC_DOCUMENTOPTION_TEXT_LARGE
Thats an option to `SCI_CREATEDOCUMENT` which Geany does not use since it does not use views.
@b4n, why would it matter to the display in Scintilla what Geany uses? Scintilla uses counters the size of pointers, so that would suggest a 64 bit counter on a 64 bit system.
by default 31-bit is used internally, 63-bit (only on 64-bit system) must explicit enabled with `SC_DOCUMENTOPTION_TEXT_LARGE`. please grep `largeDocument` inside scintilla\src folder. all index are signed (ptrdiff_t) so are only 31-bit and 63-bit.
Sorry I should have said the Scintilla _interface_ uses counters the size of a pointer. This is static at compile time and matches the Sci::Position thats used in most of the Scintilla code. On almost every system nowadays thats 64 bits.
The option you mention is dynamic, at runtime, and sets the size of the integers used to store values in the line data, so it can be a mismatch between Sci::Position (matches the static API) and the stored value.
Its a *bad thing* if Scintilla then silently truncates numbers from the API or other calculated Sci::Position to 32 bits internally without giving an error. :frowning_face:
github-comments@lists.geany.org