Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Geany starts glitch if open a very large text file #2076

Open
NTMan opened this issue Feb 2, 2019 · 17 comments

Comments

Projects
None yet
4 participants
@NTMan
Copy link

commented Feb 2, 2019

Geany starts glitch if open a very large text file

screenshot from 2019-02-03 02-49-19

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.

$ geany --version
geany 1.34.1 (built on 2019-01-05 with GTK 3.24.1, GLib 2.59.0)
$ rpm -q geany
geany-1.34.1-2.fc30.x86_64

OS: Linux Fedora Rawhide.

@elextr

This comment has been minimized.

Copy link
Member

commented Feb 2, 2019

What operating system are you on? how much memory does your computer have?

@NTMan

This comment has been minimized.

Copy link
Author

commented Feb 3, 2019

What operating system are you on?

Linux Fedora

how much memory does your computer have?

32GB

@elextr

This comment has been minimized.

Copy link
Member

commented Feb 3, 2019

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 #2066, ie not size related, nor Fedora related nor latest version of Geany related.

@elextr

This comment has been minimized.

Copy link
Member

commented Feb 3, 2019

Nor GTK version related, #2066 is 3.22.30 you are 3.24.1

@elextr

This comment has been minimized.

Copy link
Member

commented Feb 3, 2019

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.

@NTMan

This comment has been minimized.

Copy link
Author

commented Feb 3, 2019

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

@b4n

This comment has been minimized.

Copy link
Member

commented Feb 4, 2019

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.

@elextr

This comment has been minimized.

Copy link
Member

commented Feb 4, 2019

@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 😁

@NTMan

This comment has been minimized.

Copy link
Author

commented Feb 4, 2019

52169728-0f163200-275f-11e9-9183-6e0488553826

[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.

@elextr

This comment has been minimized.

Copy link
Member

commented Feb 4, 2019

Or a GTK bug in 3.22.30 which is still there in 3.24.1.

@elextr

This comment has been minimized.

Copy link
Member

commented Feb 4, 2019

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!!!

@elextr

This comment has been minimized.

Copy link
Member

commented Feb 4, 2019

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

@b4n

This comment has been minimized.

Copy link
Member

commented Feb 4, 2019

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 😕

@zufuliu

This comment has been minimized.

Copy link

commented Apr 13, 2019

Scintilla 4.0.5 (10 May 2018) addedSC_DOCUMENTOPTION_TEXT_LARGE
https://www.scintilla.org/ScintillaDoc.html#SCI_CREATEDOCUMENT

@elextr

This comment has been minimized.

Copy link
Member

commented Apr 13, 2019

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.

@zufuliu

This comment has been minimized.

Copy link

commented Apr 13, 2019

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.

@elextr

This comment has been minimized.

Copy link
Member

commented Apr 13, 2019

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. ☹️

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.