Note that no public API is changed by this PR, so if similar checks are desired
inside of plugins (core or otherwise) it should be done as a separate PR.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Now it's showing like this:
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
The debug message is fixed in last commit, was using 64-bit instead of 32-bit
placeholders in printf string. Also changed it to use a literal for the format
string.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@codebrainz pushed 1 commit.
13d8d94 Fix message formatting string
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/geany/geany/pull/1572/files/c88bbc8e9cf491833341dc19b1d34ab7f71ee89b..13d8d942263f5ef4df97045b0e58051f9c228b0f
codebrainz commented on this pull request.
> @@ -42,7 +42,51 @@
#include
-#define SSM(s, m, w, l) scintilla_send_message(s, m, w, l)
+#ifndef NDEBUG
+
FIXME: spurious line break
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it
I'm not sure why it doesn't output ": memory is exhausted" at the end of the
debug message. Maybe because it's freaking out due to no memory?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
A quick test built with msys2 32-bit gives this kind of output:
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on
I don't have much time - but if anyone wants to take a crack at finding
sensible settings for a healthy memory reserve threshold, to preclude freezes
and data loss. I took a quick look via strace, and a strace output parser I
found (https://github.com/gmarcais/memtrace), here is what my system
@codebrainz nice.
This is going to need people with 32 bit systems to test, 64 bit systems will
start swapping and get unusabley slow waaay before they fail allocation (found
that when trying #1540 :)
--
You are receiving this because you are subscribed to this thread.
Reply to this email
Partially resolves, or improves debugging for #1569.
In the future we could give better feedback to the user by showing a dialog or
something.
You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany/pull/1572
-- Commit Summary --
* Remove redundant
@AdamDanischewski well, you can provide a PR that shows it working, but its not
the point of this issue.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/1569#issuecomment-320145070
@elextr You can profile the application for average use cases. Then choose a
sensible default setting that can be adjusted by the user if they know their
needs better.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@AdamDanischewski ok, but there is still no obvious amount to keep in reserve,
how much memory is used for things like saving files depends on the size of the
file. And since there is an unknown amount of memory allocated in libraries
the "reserve" memory would have to be de-allocated to make
> To be clear Scintilla does keep a "healthy" amount of memory allocated, but
> it decreases as you add characters to it until its full then reallocates, and
> if you do a big copy and paste you can exceed ANY pre-allocation, so there is
> no point of trying to guess, you always have to handle
@codebrainz yeah, something like thats a good start.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/1569#issuecomment-320140490
Until this issue is properly solved, at a bare minimum we could do like in this
branch:
https://github.com/geany/geany/compare/master...codebrainz:check-sci-status
If anyone in the future cares to make it handle the results/status on a
case-by-case basis and make it able to throw up a dialog
@codebrainz the concern is that the `on_notify` will not be called by Scintilla
if the insert failed because it couldn't allocate.
And as I said above, non-Scintilla allocates are not this issue.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly
@AdamDanischewski
> if it fails to grab more then warn the user.
Thats what this issue is for.
To be clear Scintilla does keep a "healthy" amount of memory allocated, but it
decreases as you add characters to it until its full then reallocates, and if
you do a big copy and paste you can
> I wonder if Scintilla has set the status when it calls notifications, and if
> it still notifys when allocation fails, would be nice if most cases could be
> captured by a a test in on_notify but I somehow doubt it.
I expect all Scintilla calls set the status when non-zero, whether through
I wonder if Scintilla has set the status when it calls notifications, and if it
still notifys when allocation fails, would be nice if most cases could be
captured by a a test in `on_notify` but I somehow doubt it.
--
You are receiving this because you are subscribed to this thread.
Reply to
> Its not even possible to report if a program is running out of address space
> (which is actually what the 32bit windows problem is) because many library
> functions use memory that Geany has no idea about.
@elextr I realize that Geany/Scintilla won't know what the rest of the machine
will
Geany on windows uses the GTK2 GUI library which I don't think is hidpi aware.
You could try setting it in your .gtkrc file maybe.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
> This issue is however intended to be solely about Scintilla status returns,
> but I'm sure more issues could be raised for other places return checks are
> missed.
Yeah, at least there's a chance with Scintilla, and inside GLib, it at least
prints a message to the console before crashing.
I
@AdamDanischewski as was said on #1540, Geany's use-case is for editing human
program source files, it assumes they are reasonably sized and loads the whole
file and keeps style information for the whole file so it doesn't have to be
regenerated all the time (hence twice the size). If Geany's
> the main problem has to do with dynamic line sizes
Naw, Scintilla uses a contiguous (gap) buffer to store the data. I believe this
is what Emacs and other editors do, as it's a fair trade-off for typical text
file operations.
> Geany/Scintilla doesn't know where the next line will end so it
This may be beyond the scope of Geany, but it looks like `vi` was designed to
be efficient for use on a 300 baud modem, so it loads lines on demand. It may
be worth looking into the source code, yet is a bit hackish.
> "Author of Scintilla here. Scintilla does not use a list of lines. The
FWIW, when GLib aborts the process on malloc fail, it writes this to the debug
messages (if `-v` is used):
> GLib: .../gmem.c:165: failed to allocate XXX bytes
I just tested opening an 18GB file on my Win7 machine that has 16GB of RAM.
This is when opening a file, so presumably when Geany is
On a slightly more serious note, getting a memory exhausted status from
Scintilla doesn't mean its out of memory, just that it failed to allocate a new
300MB buffer, there still may be 299MB left that would allow Geany to save the
small files you have changed but not saved, if only Geany gave
I've got a win10 machine with 3 monitors, the primary is a 4k laptop display
scaled by 200%. The mouse pointer is unscaled in the text edit window when
geany is on the 200%-scaled desktop, making it very hard to see.
--
You are receiving this because you are subscribed to this thread.
Reply to
How do you know? It might just be another bug :)
(and crashes are mostly plugins :)
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/1569#issuecomment-320125007
It's OOM when it freezes or crashes :)
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/1569#issuecomment-320124822
To clarify, a search of Geany source shows that SCI_GETSTATUS is never used, so
we have no way of knowing if its OOM, thats what this bug is about, #1540 is
just the report that caused the search :)
--
You are receiving this because you are subscribed to this thread.
Reply to this email
I just upgraded from 1.28 -> 1.31 and Geany has started popping a "No Disk"
dialog on startup (Cancel/Continue 3 times gets past this):
I grepped through the config files under
It's not entirely clear that #1540 is indeed an OOM, or that Geany didn't
report anything. I would expect at least a pile of `CRITICAL` debug messages
coming from the `g_*_if_fail()` asserts. I doubt Geany could do much else than
that since it's OOM. It would have to keep a parachute buffer to
See #1540 Scite gives an error message that Scintilla runs out of memory but
Geany just hangs.
All operations should have a
[SCI_GETSTATUS](http://www.scintilla.org/ScintillaDoc.html#SCI_GETSTATUS) after
them.
--
You are receiving this because you are subscribed to this thread.
Reply to this
35 matches
Mail list logo
