From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.devel Subject: Re: Errors building from master with a clean repository Date: Sun, 21 Apr 2019 23:22:19 -0700 Organization: UCLA Computer Science Department Message-ID: <58b59f1d-94ee-cffc-f711-b4fdcdb0b471@cs.ucla.edu> References: <87ef5z9l23.fsf@gmail.com> <7db3cae7-794c-83d6-b8f4-f0ec000d1674@cs.ucla.edu> <83o951b29x.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="------------309F79B3CDDCEC41F3D0AB62" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="114816"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 Cc: agrambot@gmail.com, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Apr 22 08:33:47 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hISWM-000Tdk-FN for ged-emacs-devel@m.gmane.org; Mon, 22 Apr 2019 08:33:42 +0200 Original-Received: from localhost ([127.0.0.1]:33090 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hISWL-000653-BY for ged-emacs-devel@m.gmane.org; Mon, 22 Apr 2019 02:33:41 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:51962) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hISVO-00060a-N0 for emacs-devel@gnu.org; Mon, 22 Apr 2019 02:32:45 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hISLT-0003o0-7l for emacs-devel@gnu.org; Mon, 22 Apr 2019 02:22:29 -0400 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:53090) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hISLQ-0003ln-Id; Mon, 22 Apr 2019 02:22:24 -0400 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 48C811617C4; Sun, 21 Apr 2019 23:22:23 -0700 (PDT) Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id LHzWKgx0f6nw; Sun, 21 Apr 2019 23:22:20 -0700 (PDT) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 6C6F61617C5; Sun, 21 Apr 2019 23:22:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id RS0_GrFvqPer; Sun, 21 Apr 2019 23:22:20 -0700 (PDT) Original-Received: from [192.168.1.9] (cpe-23-242-74-103.socal.res.rr.com [23.242.74.103]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 2F7F916176E; Sun, 21 Apr 2019 23:22:20 -0700 (PDT) In-Reply-To: <83o951b29x.fsf@gnu.org> Content-Language: en-US X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 131.179.128.68 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:235752 Archived-At: This is a multi-part message in MIME format. --------------309F79B3CDDCEC41F3D0AB62 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Eli Zaretskii wrote: > Can we please at least mention > specific compiler options and any other tools that could be used > instead of the built-in facilities we are removing? Bonus points for > adding to etc/DEBUG a section with more details about the compiler > options, tools, and techniques of using them for debugging specific > Emacs problems for which these configure options were introduced. OK, I tried to earn bonus points by installing the attached patch into master, on top of the two other patches I mentioned earlier. --------------309F79B3CDDCEC41F3D0AB62 Content-Type: text/x-patch; name="0001-Mention-AddressSanitizer-etc.-in-etc-DEBUG.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="0001-Mention-AddressSanitizer-etc.-in-etc-DEBUG.patch" >From b20d8a932240d5332b4f44b95b2bc1d6fc74c7b0 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Sun, 21 Apr 2019 23:15:42 -0700 Subject: [PATCH] Mention AddressSanitizer etc. in etc/DEBUG * etc/DEBUG: Modernize for AddressSanitizer etc. * etc/NEWS: Defer to etc/DEBUG for this. --- etc/DEBUG | 126 ++++++++++++++++++++++++++++++++++-------------------- etc/NEWS | 3 +- 2 files changed, 82 insertions(+), 47 deletions(-) diff --git a/etc/DEBUG b/etc/DEBUG index d401d0be90..717553871a 100644 --- a/etc/DEBUG +++ b/etc/DEBUG @@ -12,24 +12,21 @@ debugging techniques. *** Configuring Emacs for debugging It is best to configure and build Emacs with special options that will -make the debugging easier. Here's the configure-time options we +make the debugging easier. Here are the configure-time options we recommend (they are in addition to any other options you might need, such as --prefix): ./configure --enable-checking='yes,glyphs' --enable-check-lisp-object-type \ CFLAGS='-O0 -g3' -The CFLAGS value is important: debugging optimized code can be very -hard. (If the problem only happens with optimized code, you may need -to enable optimizations. If that happens, try using -Og first, -instead of -O2, as the former will disable some optimizations that -make debugging some code exceptionally hard.) +The -O0 flag is important, as debugging optimized code can be hard. +If the problem happens only with optimized code, you may need to +enable optimizations. If that happens, try using -Og first instead of +-O2, as -Og disables some optimizations that make debugging some code +exceptionally hard. -Modern versions of GCC support more elaborate debug info that is -available by just using the -g3 compiler switch. Try using -gdwarf-4 -in addition to -g3, and if that fails, try -gdwarf-3. This is -especially important if you have to debug optimized code. More info -about this is available below; search for "analyze failed assertions". +Older versions of GCC may need more than just the -g3 flag. For more, +search for "analyze failed assertions" below. The 2 --enable-* switches are optional. They don't have any effect on debugging with GDB, but will compile additional code that might catch @@ -184,20 +181,15 @@ Good luck! ** When you are trying to analyze failed assertions or backtraces, it is essential to compile Emacs with flags suitable for debugging. -With GCC 4.8 or later, you can invoke 'make' with CFLAGS="-Og -g3". -With older GCC or non-GCC compilers, you can use CFLAGS="-O0 -g3". +With GCC 4.8 or later, you can invoke 'make' with CFLAGS="-O0 -g3". +With older GCC, you can use CFLAGS="-O0 -g3 -gdwarf-4", replacing "4" +by the highest version of DWARF that your compiler supports; +with non-GCC compilers, "-O0 -g3" may be the best you can do. With GCC and higher optimization levels such as -O2, the -fno-omit-frame-pointer and -fno-crossjumping options are often essential. The latter prevents GCC from using the same abort call for all assertions in a given function, rendering the stack backtrace useless for identifying the specific failed assertion. -Some versions of GCC support recent versions of the DWARF standard for -debugging info, but default to older versions; for example, they could -support -gdwarf-4 compiler option (for DWARF v4), but default to -version 2 of the DWARF standard. For best results in debugging -abilities, find out the highest version of DWARF your GCC can support, -and use the corresponding -gdwarf-N switch instead of just -g (you -will still need -g3, as in "-gdwarf-4 -g3"). ** It is a good idea to run Emacs under GDB (or some other suitable debugger) *all the time*. Then, when Emacs crashes, you will be able @@ -923,41 +915,83 @@ setting the new-console option before running Emacs under GDB: (gdb) set new-console 1 (gdb) run -** Running Emacs built with malloc debugging packages +** Running Emacs with undefined-behavior sanitization -If Emacs exhibits bugs that seem to be related to use of memory -allocated off the heap, it might be useful to link Emacs with a -special debugging library, such as Electric Fence (a.k.a. efence) or -GNU Checker, which helps find such problems. +Building Emacs with undefined-behavior sanitization can help debug +integer overflow and other undefined behavior in C code. To use +UndefinedBehaviorSanitizer with GCC and similar compilers, append +'-fsanitize=undefined' to CFLAGS, either when running 'configure' or +running 'make'. For example: -Emacs compiled with such packages might not run without some hacking, -because Emacs replaces the system's memory allocation functions with -its own versions, and because the dumping process might be -incompatible with the way these packages use to track allocated -memory. Here are some of the changes you might find necessary: + ./configure CFLAGS='-O0 -g3 -fsanitize=undefined' - - Make sure unexec is disabled, e.g., './configure --without-unexec'. +You may need to append '-static-libubsan' to CFLAGS if your version of +GCC is installed in an unusual location. - - Configure with a different --prefix= option. If you use GCC, - version 2.7.2 is preferred, as some malloc debugging packages - work a lot better with it than with 2.95 or later versions. +When using GDB to debug an executable with undefined-behavior +sanitization, the GDB command: - - Type "make" then "make -k install". + (gdb) rbreak ^__ubsan_handle_ - - If required, invoke the package-specific command to prepare - src/temacs for execution. +will let you gain control when an error is detected and before +UndefinedBehaviorSanitizer outputs to stderr or terminates the +program. - - cd ..; src/temacs +** Running Emacs with address sanitization -(Note that this runs 'temacs' instead of the usual 'emacs' executable. -This avoids problems with dumping Emacs mentioned above.) +Building Emacs with address sanitization can help debug memory-use +problems. To use AddressSanitizer with GCC and similar compilers, +append '-fsanitize=address' to CFLAGS, either when running 'configure' +or running 'make'. Configure, build and run Emacs with +ASAN_OPTIONS='detect_leaks=0' in the environment to suppress +diagnostics of minor memory leaks in Emacs. For example: -Some malloc debugging libraries might print lots of false alarms for -bitfields used by Emacs in some data structures. If you want to get -rid of the false alarms, you will have to hack the definitions of -these data structures on the respective headers to remove the ':N' -bitfield definitions (which will cause each such field to use a full -int). + export ASAN_OPTIONS='detect_leaks=0' + ./configure CFLAGS='-O0 -g3 -fsanitize=address' + make + src/emacs + +You may need to append '-static-libasan' to CFLAGS if your version of +GCC is installed in an unusual location. + +When using GDB to debug an executable with address sanitization, the +GDB command: + + (gdb) rbreak ^__asan_report_ + +will let you gain control when an error is detected and before +AddressSanitizer outputs to stderr or terminates the program. + +Address sanitization is incompatible with undefined-behavior +sanitization, unfortunately. Address sanitization is also +incompatible with the --with-dumping=unexec option of 'configure'. + +** Running Emacs under Valgrind + +Valgrind is free software that can be useful +when debugging low-level Emacs problems. Unlike GCC sanitizers, +Valgrind does not need you to compile Emacs with special debugging +flags, so it can be helpful in investigating problems that vanish when +Emacs is recompiled with debugging enabled. However, by default +Valgrind generates many false alarms with Emacs, and you will need to +maintain a suppressions file to suppress these false alarms and use +Valgrind effectively. For example, you might invoke Valgrind this +way: + + valgrind --suppressions=valgrind.supp ./emacs + +where valgrind.supp contains groups of lines like the following, which +suppresses some Valgrind false alarms during Emacs garbage collection: + + { + Fgarbage_collect Cond - conservative garbage collection + Memcheck:Cond + ... + fun:Fgarbage_collect + } + +Unfortunately Valgrind suppression files tend to be system-dependent, +so you will need to keep one around that matches your system. ** How to recover buffer contents from an Emacs core dump file diff --git a/etc/NEWS b/etc/NEWS index 051063171e..b444fc5967 100644 --- a/etc/NEWS +++ b/etc/NEWS @@ -93,7 +93,8 @@ change to one of the data structures that it relies on. ** The configure options '--enable-checking=conslist' and '--enable-checking=xmallocoverrun' have been withdrawn. The former made Emacs irredeemably slow, and the latter made it crash. Neither -option was useful with modern debugging tools. +option was useful with modern debugging tools such as AddressSanitizer +(see etc/DEBUG). --- ** Emacs now requires GTK 2.24 and GTK 3.10 for the GTK 2 and GTK 3 -- 2.17.1 --------------309F79B3CDDCEC41F3D0AB62--