-
-
Notifications
You must be signed in to change notification settings - Fork 3k
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
Emacs: Fatal error 11: Segmentation fault #2599
Comments
Same here, arm, Android 6. |
I have experienced the same issue. Nvidia shield tablet. Android 7 now, consistent segfaults since 6. |
I am getting a lot of emacs seg faults especially with touch-scrolling. (Android 7) |
@Factavi Hm, I mostly use a hardware keyboard so haven't noticed if it happens often when touch-scrolling. For me it seem to happen more or less randomly. |
This happens frequently to me. I'm using the ARM architecture, bluetooth keyboard, most current version of emacs in termux's repository, as of 15:00 MST, OCT 6th. Emacs is primarily what I use termux for, this is an ongoing, massive source of frustration. |
This happens for me too: HP Chromebook 13 G1 Normally I live inside Emacs all the time (including shell window). But this is a deal-breaker. I've resorted to learning Vim, and you know how horrifying that is. Been happening since I first installed Termux, approx. May, 2017. I can't say how often, because this has caused me to mostly abandon Emacs. |
Sorry, the HP Chromebook 13 G1 uses an Intel Core m7, so I guess I should not have piled on to this ARM bug report. |
I've been running an nvidia shield tablet - mostly as a portable emacs
machine. This has been happening since Marshmallow.
I'm on Nougat now, latest official NVIDIA stock rom.
FWIW, I've been able to run stable emacs through termux through Arch Linux
(https://github.com/sdrausty/termux-archlinux) running in a PRoot ...
Its not elegant, but it's stable ....
…On Thu, Nov 22, 2018 at 4:34 PM kanreki ***@***.***> wrote:
Sorry, the HP Chromebook 13 G1 uses an Intel Core m7, so I guess I should
not have piled on to this ARM bug report.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#2599 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AE1OehtBt7rhOUB39-8olzZnQXVIUgxqks5ux0J_gaJpZM4U-cl8>
.
|
Happens to me frequently as well, on a Samsung Tab A (2016). Really annoying, as I pretty much got the tablet for Termux and Emacs. If there is any way I can help, please let me know! |
I think that Emacs on termux was built with |
Same problem here with a Samsung Tab A (2016). If I start emacs with "emacs -q" it seems to be stable. But if I load the init.el file, it gives a segmentation fault after a few seconds of use. Trying to reduce de init.el file... But I'm loosing so much of Emacs that I would prefer to use nano. |
For me it segfaults with -Q too. With or without init file, in my experience the time it takes to segfault varies: from a few seconds to 20 minutes or more. |
You're right @oscarfv, it segfaults with 'emacs -q' too. It took a bit longer but it gave me the error after scrolling down and up about 20 times the '.emacs' file. I tested emacs with the new Android 7 branch (in alpha testing) but it gave me the same error. |
Tried emacs 27 with the new portable dumper. Same crash. |
A fast method for triggering the crash here is to visit some file with a few hundred lines and keep pressed the cursor-down key. Usually it will crash on reaching the bottom edge of the window after scrolling a few screenfulls of text. |
So, I've tried the following since last year (without solving the problem):
Since gdb cannot tell where the crash comes from, even if emacs and all dependencies are built with debug symbols, I am guessing the problem arises in a /system/lib library. This does not mean that the bug is not solvable, just that it is harder to pinpoint the actual problem and solve it. I also do not think I have encountered the segfault when using emacs --daemon + emacsclient, but I am not using the daemon a lot |
What environment do you use for Termux development?
I'd kind of like to do more debugging, but as I mentioned earlier, I'm a little afraid my Chromebook may melt.... I'm curious if other people are using standard devices for compiling large packages.
[I have a Samsung Chromebook Pro, with 4GB RAM and maybe 5GB of free flash storage.]
|
@snogglethorpe : If Emacs qualifies as a large package for you, on April I compiled Emacs 27 on a cheap, generic quad-core tablet without problems. |
@snogglethorpe your device will (most likely) shut down if the cpu reaches a too high temperature, it's not really anything you need to be afraid of |
Ok, I've built Emacs master on my CB, and it seems to work properly (with a little futzing around to update the Termux patches), dumping and all, and I can run "emacs -fg-daemon" in gdb... Unfortunately, it's so far stubbornly refused to crash...! ^^; [Which doesn't mean much, sometimes the distro emacs runs for many many hours before crashing...] |
Ok, now it's crashing as expected, in the same maddeningly hard to debug way the emacs package does. BTW, one thing is much better about using this build than the current Termux emacs package: it's dumped, so restarting emacs after a crash is much faster, essentially instantaneous, whereas the non-dumped emacs in the Termux package takes 3-4 seconds to start. Would it be possible to use dumping for the Termux emacs package? |
No. See https://github.com/termux/termux-packages/blob/master/packages/emacs/build.sh#L62. |
@snogglethorpe : dumping Emacs 27 works thanks to the new portable dumper. Termux packages the latest Emacs stable release, i. e. 26. |
@oscarfv omg, finally a dumped emacs in termux, thanks for the tip! And I haven't been able to make it crash in my initial testing (scrolling ~10k lines), I'll leave this issue open until emacs-27 is packaged, and will close it if I haven't been able to reproduce a crash by then! |
I've been using dumping in my local build (built in Termux) of the emacs trunk (so version 27.x), and it works fine—and starts up much faster than an un-dumped emacs. However it does still exhibit the random hard-to-debug crashiness of the current Termux emacs package (which doesn't use dumping). As with that version of emacs, it's pretty random—sometimes it goes for ages without crashing, sometimes it crashed almost immediately after startup. |
@Grimler91 : even if it works for you the bug should remain open because, first, Emacs 27 is not the current release and, second, the crash also happens with Emacs 27. When I tried Emacs 27 my experience matched what @snogglethorpe describes. |
I tried it on my old tablet, but could not reproduce the result you
describe.
…On Sun, Feb 9, 2020, 7:01 AM zettelmuseum ***@***.***> wrote:
I can reproduce "Fatal error 11:segmentation fault" reliably on my (old)
tablet.
This is vanilla emacs installed in termux via apt, empty .emacs, no
packages.
Steps:
1. open latest org-manual.org
(
https://raw.githubusercontent.com/bzg/org-mode/master/doc/org-manual.org
)
2)do the following *immediately* after file has loaded and *as quick as
possible*
shift-tab
shift-tab (status should display "CONTENTS...done"
now press DOWN (I'm using Hacker's Keyboard) and KEEP IT PRESSED
...will crash 9 out of 10 times.
Can anyone reproduce this also?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#2599?email_source=notifications&email_token=AHXQWYLLUC5QCXUC3B4M5Y3RCALEVA5CNFSM4FHZZF6KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOELGOV6I#issuecomment-583854841>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AHXQWYIYCTR6OMQ746DQC3LRCALEVANCNFSM4FHZZF6A>
.
|
Here is a way to reliably reproduce this crash. Step 1 (create our test file, may take a few seconds)
Now; it is important to do Step 2 very quickly, especially holding the down key after the return key. If it doesn't crash the first time, just repeat Step 2 a few more times. Always crashes for me after a few tries. Step 2
Can anyone also reproduce it this way? |
@kanreki |
@zettelmuseum , no it's not crashes |
@krishna-arch |
Crash seem to only happen on arm, and mostly (only?) on samsung devices. Maybe @krishna-arch has another type of device. @zettelmuseum I can reproduce the crash with your testfile. Can't tell if it crashes faster compared to just scrolling in a "normal" file, but it crashes nonetheless. |
also it seems to crash faster if you zoom termux display (max. 20 rows) |
@Grimler91 by the way, not a Samsung device here, just a generic arm phablet |
Good to know, thanks for the info! On another note: I've noticed that compiling emacs with
Might be related to this bug, or maybe it's just a problem on the emacs-27 branch. I'll ask for advice on the emacs mailing list. |
Here's another interesting observation. Too early to tell what this means.., but I'm going to run emacs inside tmux from now on :-) EDIT: this is using the exact same termux package, not proot or anything.
|
I have merged a potential fix for this: 996c569, it should be available in a few minutes. |
That change only addresses arm, but the same crash happens on x86 .... |
@snogglethorpe thanks, fixed in c6fe679. 26.3-6 should be available in a couple of minutes |
So far, so good! Thanks!! I will certainly continue using this, and will report back if anything is amiss. |
This happens on arm, android 7. At least 3 other people experienced the same according to a google+ post. The crashes aren't very frequent and I haven't found an easy way to reproduce them.
I have experienced this since around 4cba233 but building the previous version (25c6980) doesn't change anything.
I've build a debug version and investigated with gdb and valgrind though.
The debug deb for emacs and all dependencies are available from https://grimler.se/dists/testing/debug.
gdb shows:
While valgrind reports lots and lots of
Conditional jump or move depends on uninitialised value(s)
andUse of uninitialised value of size 4
, a snippet from runningvalgrind --leak-check=full --track-origins=yes -v
might look like:Exact lines and functions varies though, another log had
Two example full valgrind logs are available at https://grimler.se/emacs_segfault2 and https://grimler.se/emacs_segfault3.
Running emacs under valgrind on my aarch64 give similar problems but I haven't experienced a segfault. I assume therefore that we have a problem in our emacs on all arches.
I'm not sure how to debug this further.
The text was updated successfully, but these errors were encountered: