From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Lockywolf Laptop Newsgroups: gmane.emacs.help Subject: Re: Emacs on Android OOMs with pdf-tools. (And an Android howto.) Date: Thu, 22 Aug 2024 14:06:53 +0800 Message-ID: <87le0pvzzj.fsf@laptop.lockywolf.net> References: <8734mxxtwd.fsf@laptop.lockywolf.net> <87a5h5f97k.fsf@yahoo.com> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="19651"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: mu4e 1.10.7; emacs 30.0.50 Cc: help-gnu-emacs@gnu.org, monnier@iro.umontreal.ca To: Po Lu Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Thu Aug 22 08:23:33 2024 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1sh1EK-00050T-Tj for geh-help-gnu-emacs@m.gmane-mx.org; Thu, 22 Aug 2024 08:23:33 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sh1DZ-0001Mc-KU; Thu, 22 Aug 2024 02:22:45 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sh1DX-0001M1-QP for help-gnu-emacs@gnu.org; Thu, 22 Aug 2024 02:22:43 -0400 Original-Received: from mail-oi1-x235.google.com ([2607:f8b0:4864:20::235]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1sh1DV-000252-IY for help-gnu-emacs@gnu.org; Thu, 22 Aug 2024 02:22:43 -0400 Original-Received: by mail-oi1-x235.google.com with SMTP id 5614622812f47-3db16129143so228581b6e.0 for ; Wed, 21 Aug 2024 23:22:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1724307760; x=1724912560; darn=gnu.org; h=mime-version:message-id:in-reply-to:date:subject:cc:to:from :user-agent:references:from:to:cc:subject:date:message-id:reply-to; bh=v2PqTkDtZdsrsmIJphaCYsVWyYLG64WY6eG6ohEZNps=; b=dyIxocq0z0rNRf1GnxDvz0ac94Oc8GeUFysS/po0UhExg5huXENgp5T4mO23I2zUrJ 1hpMBSYtN8+Ce9K31xspoX+Z6CuRMDz+wwkDnvRU9rIV+xhHUJbT6fNRXaCuk0beCGm8 x3drvS9iF2Byo75ntsIVQgLXRGdnsxp6ATIjgUTRvclyQPWtVouECegYQqRB0YMHGBeA 1DPwxCx4Ndbm/prKHfPjBCvmL+rOyi6ATruyCaCqlFn8dqFJOyTdpu4nZX9yyCLkHcvb /LnEKKLEIUrfgxHW5J+9DA6GmSidjp32mi4+xjdcGP0bJRTGaS5QhMyyax1WuOWkyjY/ 9LOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724307760; x=1724912560; h=mime-version:message-id:in-reply-to:date:subject:cc:to:from :user-agent:references:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=v2PqTkDtZdsrsmIJphaCYsVWyYLG64WY6eG6ohEZNps=; b=ppXyVd22A0HvF6GzKjOY6ff+SH2InLqULXmhdpvDPlA9QbsgbGkmUKWOuH+ruUKI3F tL8ioztkWds93jsEM189HIVp6g+CECFBFLK+7vb8+2ChrinB/QZ6/iJdazhxzVYXt1Sf M1qsbR7mc7AvtZQszsoeIo3rwNA46NQ7jZFkFHF8Z8xXk+rjP/NI1YpWB9hqp5XbPwTr WFaWrEim/gKXOIP23eb2QUDQQEn6zCDpiBNfd7+bTWIJgJUUNaHW8F84eT0O9BkB3bu2 IWLJGuyZ0RjdMlc4GWb/WwrQdiieJvfWVkiCW1cPE7DCB0Rs/Jo8YMIjwsPbHNiisacf utAA== X-Gm-Message-State: AOJu0YzDqXnXN7hCL7+nohueKSQH8zqeUAYH9B2ST4azt4QktNxcJYcD mB83sEPwdjANl8Ofsf6Z35xmJra/qM1oreNo7GdieE7jbqz0yFP+ X-Google-Smtp-Source: AGHT+IGvgf5RKFUaHmEJGhNlHt4WWNtne7IkPOTTgDCkT5sN5cCfnt1T93SMCDBTJFNzRs4BP/07NA== X-Received: by 2002:a05:6870:9708:b0:260:f058:48eb with SMTP id 586e51a60fabf-2737ef041cemr5456732fac.20.1724307759723; Wed, 21 Aug 2024 23:22:39 -0700 (PDT) Original-Received: from laptop.lockywolf.net ([2001:470:24:315::102]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-7143431052bsm653560b3a.181.2024.08.21.23.22.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 21 Aug 2024 23:22:39 -0700 (PDT) In-reply-to: <87a5h5f97k.fsf@yahoo.com> Received-SPF: pass client-ip=2607:f8b0:4864:20::235; envelope-from=lockywolf@gmail.com; helo=mail-oi1-x235.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.help:147754 Archived-At: --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable (my answer to Po Lu is below) To Eli: >if the OOM mechanism of the OS kicks in while Emacs >still thinks it has more memory to use, it means something is wrong >with how the available memory is being reported to Emacs. Emacs >should have sensed that it is approaching the limit and signaled the >memory-full signal before that happens. I think this warrants a bug >report, with a reproducer. Emacs doesn't actually crash or doesn't get killed because of OOM. Rather it produces a message of something like "Memory exhausted, run C-x C-s, and restart Emacs". Something does get broken at this point, as, for example, not all faces get rendered, but overall Emacs works. I am not sure how how bad this is. >Try playing with the value of image-cache-eviction-delay. I ended up doing like this in init.el: #+begin_src elisp (setf pdf-cache-image-limit 0) (setq-default pdf-view-display-size 'fit-height) (setq-default pdf-view-max-image-width 2000) (setq-default pdf-cache-image-inihibit t) (advice-add 'pdf-view-redisplay :before #'clear-image-cache) (advice-add 'pdf-view-redisplay :after #'clear-image-cache) #+end_src This works. It's a bit slow, but I can read a whole book of 400 pages with no issues. Each page generates about 100 Mb of cache, but since it's evicted after rendering, overall the memory consumption is not that high, about 16 Mb of image cache. >But how did you get to so many images? what images are they and what >did you do in Emacs to have them all loaded? Emacs is not meant to be >used with so many images on a device that has such severe memory >limitations. Well, this thread is titled "using pdf-tools on Android 6" :). This is an eBook reader Onyx Boox Max 2, with an eInk display. I am using it because it has a reflective display that is so-so-so much better for my strained eyes that I am ready to suffer quite some hardships to make it applicable to many of my daily tasks. So I was trying to use pdf-tools to read pdfs on it, with Emacs. Its native PDF reader works quite okay, the problem is that it's Android software, and not aimed at power users, so its integration options are limited. I have written quite a lot about this tool in the howto. pdf-tools is somehow smarter than doc-view-mode. Doc-view-mode, as far as I understand, generates a png file with ghostscript out of each page of the pdf file, whereas pdf-tools uses poppler, and renders much more than just an image. In particular, it allows for pdf annotations, and can be integrated with auctex, et cetera. I have not managed to make pdf-annotating features of pdf-tools work on this eBook, Emacs just hangs if I try to touch the screen with a pen, and can be unfrozen with C-g. But so far I didn't really need it, as I seldom annotate PDFs using PDF built-in annotation features. I prefer to pass a pdf through mathpix (or some other de-texifying OCR, or even better, just ask the author to send me the source), and write my annotations right into the resulting TeX code. Po Lu writes: > Lockywolf writes: > >> Date: Thu, 22 Aug 2024 08:12:44 +0800 >> >> Thanks everyone for the memory-report command, I hadn't known about it >> before this case. >> >>>How much memory does your device provide? >> >> The device has 2 Gb of RAM, of which about 1.5 Gb are ordinarily used by >> the system and built-in annoyances. >> I am trying to _only_ use Emacs on this device, so it should have about >> 500 Mb left. >> >> But I am pretty sure it is not actually the problem of not enough >> memory, as memory-report is clearly showing that something is wrong. >> >> The two reports, before and after the OOM message, are below. >> The concerning bit seems to be: "256 MiB Total Image Cache Size" >> 256 Mb is a significant number for this device. Below I am also >> pasting memory-report with doc-view-mode, which seems to "only" generate >> 160 Mb of image-cache. >> >> Is it possible to tell Emacs to not generate so much cache? > > Please try Eli's advice, but also please run `adb logcat' (from a PC) > after Emacs signals that memory has been exhausted, and verify that no > line reading "Possible out of memory error" exists which does not > immediately precede a java.lang.OutOfMemoryError, since Emacs assumes by > default that any unknown Java exception is an out-of-memory error. To Po Lu: Adb logcat produces the following message: 08-22 14:05:09.144 20974 20987 I art : Starting a blocking GC Alloc 08-22 14:05:09.144 20974 20987 I art : Starting a blocking GC Alloc 08-22 14:05:09.149 20974 20987 I art : Starting a blocking GC Alloc 08-22 14:05:09.160 20974 20987 I art : Alloc partial concurrent mark sw= eep GC freed 383(124KB) AllocSpace objects, 21(336KB) LOS objects, 8% free,= 175MB/191MB, paused 219us total 11.322ms 08-22 14:05:09.160 20974 20987 I art : Starting a blocking GC Alloc 08-22 14:05:09.171 20974 20987 I art : Alloc concurrent mark sweep GC f= reed 141(6KB) AllocSpace objects, 0(0B) LOS objects, 8% free, 175MB/191MB, = paused 205us total 10.038ms 08-22 14:05:09.171 20974 20987 I art : Forcing collection of SoftRefere= nces for 23MB allocation 08-22 14:05:09.171 20974 20987 I art : Starting a blocking GC Alloc 08-22 14:05:09.181 20974 20987 I art : Alloc concurrent mark sweep GC f= reed 5(176B) AllocSpace objects, 0(0B) LOS objects, 8% free, 175MB/191MB, p= aused 214us total 9.850ms 08-22 14:05:09.181 20974 20987 W art : Throwing OutOfMemoryError "Faile= d to allocate a 24687948 byte allocation with 16777056 free bytes and 16MB = until OOM" 08-22 14:05:09.181 20974 20987 I art : Starting a blocking GC Alloc 08-22 14:05:09.181 20974 20987 I art : Starting a blocking GC Alloc 08-22 14:05:09.184 20974 20987 I art : Starting a blocking GC Alloc 08-22 14:05:09.194 20974 20987 I art : Alloc partial concurrent mark sw= eep GC freed 6(192B) AllocSpace objects, 0(0B) LOS objects, 8% free, 175MB/= 191MB, paused 207us total 10.227ms 08-22 14:05:09.194 20974 20987 I art : Starting a blocking GC Alloc 08-22 14:05:09.204 20974 20987 I art : Alloc concurrent mark sweep GC f= reed 3(96B) AllocSpace objects, 0(0B) LOS objects, 8% free, 175MB/191MB, pa= used 198us total 9.826ms 08-22 14:05:09.204 20974 20987 I art : Forcing collection of SoftRefere= nces for 23MB allocation 08-22 14:05:09.204 20974 20987 I art : Starting a blocking GC Alloc 08-22 14:05:09.214 20974 20987 I art : Alloc concurrent mark sweep GC f= reed 3(96B) AllocSpace objects, 0(0B) LOS objects, 8% free, 175MB/191MB, pa= used 207us total 9.940ms 08-22 14:05:09.214 20974 20987 W art : Throwing OutOfMemoryError "Faile= d to allocate a 24687948 byte allocation with 16777056 free bytes and 16MB = until OOM" 08-22 14:05:10.767 20974 20987 I art : Starting a blocking GC Alloc 08-22 14:05:10.767 20974 20987 I art : Starting a blocking GC Alloc 08-22 14:05:10.771 20974 20987 I art : Starting a blocking GC Alloc 08-22 14:05:10.781 20974 20987 I art : Alloc partial concurrent mark sw= eep GC freed 43(1712B) AllocSpace objects, 0(0B) LOS objects, 8% free, 175M= B/191MB, paused 214us total 10.370ms 08-22 14:05:10.781 20974 20987 I art : Starting a blocking GC Alloc 08-22 14:05:10.791 20974 20987 I art : Alloc concurrent mark sweep GC f= reed 2(64B) AllocSpace objects, 0(0B) LOS objects, 8% free, 175MB/191MB, pa= used 195us total 9.755ms 08-22 14:05:10.791 20974 20987 I art : Forcing collection of SoftRefere= nces for 23MB allocation 08-22 14:05:10.791 20974 20987 I art : Starting a blocking GC Alloc 08-22 14:05:10.801 20974 20987 I art : Alloc concurrent mark sweep GC f= reed 3(96B) AllocSpace objects, 0(0B) LOS objects, 8% free, 175MB/191MB, pa= used 199us total 9.804ms 08-22 14:05:10.801 20974 20987 W art : Throwing OutOfMemoryError "Faile= d to allocate a 24687948 byte allocation with 16777056 free bytes and 16MB = until OOM" 08-22 14:05:10.801 20974 20987 I art : Starting a blocking GC Alloc 08-22 14:05:10.801 20974 20987 I art : Starting a blocking GC Alloc 08-22 14:05:10.804 20974 20987 I art : Starting a blocking GC Alloc 08-22 14:05:10.814 20974 20987 I art : Alloc partial concurrent mark sw= eep GC freed 6(192B) AllocSpace objects, 0(0B) LOS objects, 8% free, 175MB/= 191MB, paused 206us total 10.249ms 08-22 14:05:10.814 20974 20987 I art : Starting a blocking GC Alloc 08-22 14:05:10.825 20974 20987 I art : Alloc concurrent mark sweep GC f= reed 3(96B) AllocSpace objects, 0(0B) LOS objects, 8% free, 175MB/191MB, pa= used 200us total 9.893ms 08-22 14:05:10.825 20974 20987 I art : Forcing collection of SoftRefere= nces for 23MB allocation 08-22 14:05:10.825 20974 20987 I art : Starting a blocking GC Alloc 08-22 14:05:10.835 20974 20987 I art : Alloc concurrent mark sweep GC f= reed 3(96B) AllocSpace objects, 0(0B) LOS objects, 8% free, 175MB/191MB, pa= used 196us total 9.771ms 08-22 14:05:10.835 20974 20987 W art : Throwing OutOfMemoryError "Faile= d to allocate a 24687948 byte allocation with 16777056 free bytes and 16MB = until OOM" I do not know whether this is helpful. =2D-=20 Your sincerely, Vladimir Nikishkin (MiEr, lockywolf) (Laptop) --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEfMqSqJw3lBxgO9kyaxrT226M5zsFAmbG2ScACgkQaxrT226M 5zvC1g/+NCMxHd1+Wak2Y8x9k5upPK00SBNAuBZhe9ERw9a7lk7Y3YRnMkGlK5nh 3/XjBtiixM0fQ3T/NOZE2lru/2oBg2FuULWXJWmCKa5xLjVok/CeBYVeo8ttcy1t OppzsFer7h7rcQ2y2Z+Kuf8Ez2JXC1JjeEDBx0EeAdPyzYU8WFOgDs78nI60Wau+ c0wqFpjN7EjI0RJHR4wzq1V/I9s8IAxsz+l6E9vGtrap63gxxDYcr2sRiLJGZvbv rUkhrJ/BcHHv0OA3tNUhl1QwUvp8Q54yKNZTuiMXuyCRSFRPFg2St1ZOzhY4CSlm SGtL1JuUt7CNzjELBXe7qtrlbVa9KkVhNjjmrAa9FATubRnoiKheZUg3RGd38CiO OfJ1JWfZ/qJtLvp5H0ftxeH21EiISGEUSnCv6bDGhL5wlRhmlyiZl0ABdC8NF9CG nrePuyIdwpSIHzk2gYnSkKIkIEqOuss6fQfKH0I30RPuBQ9tY97Kb5F4/INYj2b2 xmVD3fIgXyluq88FzEyV9mXvaJexzLW+WyMlS08yBwFdJF/ntx+PfSthx+Uzts06 A5ni4HGKXQDQv34INrZ6lnOg1otf3IheOzlqMMrmSOODSBygx8JIMPLmRe5VWV2+ uD+JDXJnQLc1vbFo/7qE/fF8eXVsFqgHuIFk5AdiNAV+cPJzMt8= =uDBL -----END PGP SIGNATURE----- --=-=-=--