X-Git-Url: https://code.delx.au/gnu-emacs/blobdiff_plain/5a44bfea9d4a6e6fbc8c74aa7e8691b47397927a..30989a0ae1923b4466cf4902a5ac009fc1d2fdad:/etc/PROBLEMS diff --git a/etc/PROBLEMS b/etc/PROBLEMS index d531367711..31f38e3980 100644 --- a/etc/PROBLEMS +++ b/etc/PROBLEMS @@ -459,11 +459,9 @@ smart. It sees that the Shell uses terminal type 'unknown' and turns on the flag to output ^M at the end of each line. You can fix the problem by adding this to your .cshrc file: - if ($?EMACS) then - if ("$EMACS" =~ /*) then - unset edit - stty -icrnl -onlcr -echo susp ^Z - endif + if ($?INSIDE_EMACS && $?tcsh) + unset edit + stty -icrnl -onlcr -echo susp ^Z endif *** Emacs startup on GNU/Linux systems (and possibly other systems) is slow. @@ -942,6 +940,21 @@ into Meta. This is because of the great importance of Meta in Emacs. ** Window-manager and toolkit-related problems +*** Emacs built with GTK+ toolkit produces corrupted display on HiDPI screen + +This can happen if you set GDK_SCALE=2 in the environment or in your +'.xinitrc' file. (This setting is usually accompanied by +GDK_DPI_SCALE=0.5.) Emacs can not support these settings correctly, +as it doesn't use GTK+ exclusively. The result is that sometimes +widgets like the scroll bar are displayed incorrectly, and frames +could be displayed "cropped" to only part of the stuff that should be +displayed. + +The workaround is to explicitly disable these settings when invoking +Emacs, for example (from a Posix shell prompt): + + $ GDK_SCALE=1 GDK_DPI_SCALE=1 emacs + *** Metacity: Resizing Emacs or ALT-Tab causes X to be unresponsive. This happens sometimes when using Metacity. Resizing Emacs or ALT-Tab:bing @@ -1657,7 +1670,7 @@ which combination produces "M-x" in the echo area. You can also use the 'xmodmap' utility to show all the keys which produce a Meta modifier: - xmodmap -pk | egrep -i "meta|alt" + xmodmap -pk | grep -Ei "meta|alt" A more convenient way of finding out which keys produce a Meta modifier is to use the 'xkbprint' utility, if it's available on your system: @@ -2222,11 +2235,11 @@ month names with consistent widths for some locales on some versions of Windows. This is caused by a deficiency in the underlying system library function. -** Problems with set-time-zone-rule function +** Non-US time zones. -The function set-time-zone-rule gives incorrect results for many -non-US timezones. This is due to over-simplistic handling of -daylight savings switchovers by the Windows libraries. +Many non-US time zones are implemented incorrectly. This is due to +over-simplistic handling of daylight savings switchovers by the +Windows libraries. ** Files larger than 4GB report wrong size in a 32-bit Windows build @@ -2602,51 +2615,70 @@ See , . ** Dumping -*** Segfault during 'make bootstrap' under the Linux kernel. +*** Segfault during 'make' -In Red Hat Linux kernels, "Exec-shield" functionality is enabled by -default, which creates a different memory layout that can break the -emacs dumper. Emacs tries to handle this at build time, but if this -fails, the following instructions may be useful. +If Emacs segfaults when 'make' executes one of these commands: -Exec-shield is enabled on your system if + LC_ALL=C ./temacs -batch -l loadup bootstrap + LC_ALL=C ./temacs -batch -l loadup dump - cat /proc/sys/kernel/exec-shield +the problem may be due to inadequate workarounds for address space +layout randomization (ASLR), an operating system feature that +randomizes the virtual address space of a process. ASLR is commonly +enabled in Linux and NetBSD kernels, and is intended to deter exploits +of pointer-related bugs in applications. If ASLR is enabled, the +command: -prints a value other than 0. (Please read your system documentation -for more details on Exec-shield and associated commands.) + cat /proc/sys/kernel/randomize_va_space # GNU/Linux + sysctl security.pax.aslr.global # NetBSD -Additionally, Linux kernel versions since 2.6.12 randomize the virtual -address space of a process by default. If this feature is enabled on -your system, then +outputs a nonzero value. - cat /proc/sys/kernel/randomize_va_space +These segfaults should not occur on most modern systems, because the +Emacs build procedure uses the command 'setfattr' or 'paxctl' to mark +the Emacs executable as requiring non-randomized address space, and +Emacs uses the 'personality' system call to disable address space +randomization when dumping. However, older kernels may not support +'setfattr', 'paxctl', or 'personality', and newer Linux kernels have a +secure computing mode (seccomp) that can be configured to disable the +'personality' call. -prints a value other than 0. +It may be possible to work around the 'personality' problem in a newer +Linux kernel by configuring seccomp to allow the 'personality' call. +For example, if you are building Emacs under Docker, you can run the +Docker container with a security profile that allows 'personality' by +using Docker's --security-opt option with an appropriate profile; see +. -When these features are enabled, building Emacs may segfault during -the execution of this command: +To work around the ASLR problem in either an older or a newer kernel, +you can temporarily disable the feature while building Emacs. On +GNU/Linux you can do so using the following command (as root). - ./temacs --batch --load loadup [dump|bootstrap] + echo 0 > /proc/sys/kernel/randomize_va_space -To work around this problem, you can temporarily disable these -features while building Emacs. You can do so using the following -commands (as root). Remember to re-enable them when you are done, -by echoing the original values back to the files. +You can re-enable the feature when you are done, by echoing the +original value back to the file. NetBSD uses a different command, +e.g., 'sysctl -w security.pax.aslr.global=0'. - echo 0 > /proc/sys/kernel/exec-shield - echo 0 > /proc/sys/kernel/randomize_va_space +Alternatively, you can try using the 'setarch' command when building +temacs like this, where -R disables address space randomization: -Or, on x86, you can try using the 'setarch' command when running -temacs, like this: + setarch $(uname -m) -R make - setarch i386 -R ./temacs --batch --load loadup [dump|bootstrap] +ASLR is not the only problem that can break Emacs dumping. Another +issue is that in Red Hat Linux kernels, Exec-shield is enabled by +default, and this creates a different memory layout. Emacs should +handle this at build time, but if this fails the following +instructions may be useful. Exec-shield is enabled on your system if -or + cat /proc/sys/kernel/exec-shield - setarch i386 -R make +prints a nonzero value. You can temporarily disable it as follows: + + echo 0 > /proc/sys/kernel/exec-shield -(The -R option disables address space randomization.) +As with randomize_va_space, you can re-enable Exec-shield when you are +done, by echoing the original value back to the file. *** temacs prints "Pure Lisp storage exhausted".