From debbugs-submit-bounces@debbugs.gnu.org Mon Aug 20 15:57:39 2012 Received: (at submit) by debbugs.gnu.org; 20 Aug 2012 19:57:39 +0000 Received: from localhost ([127.0.0.1]:40428 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1T3Y6U-0002LJ-Iu for submit@debbugs.gnu.org; Mon, 20 Aug 2012 15:57:39 -0400 Received: from eggs.gnu.org ([208.118.235.92]:47798) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1T3Y2y-0002Fh-SA for submit@debbugs.gnu.org; Mon, 20 Aug 2012 15:54:02 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1T3Y2i-0000S4-4s for submit@debbugs.gnu.org; Mon, 20 Aug 2012 15:53:45 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_HI autolearn=unavailable version=3.3.2 Received: from lists.gnu.org ([208.118.235.17]:35558) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T3Y2h-0000Ry-SE for submit@debbugs.gnu.org; Mon, 20 Aug 2012 15:53:44 -0400 Received: from eggs.gnu.org ([208.118.235.92]:51303) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T3Y2g-0006QR-7u for bug-gnu-emacs@gnu.org; Mon, 20 Aug 2012 15:53:43 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1T3Y2e-0000RC-4P for bug-gnu-emacs@gnu.org; Mon, 20 Aug 2012 15:53:42 -0400 Received: from chomsky.autogeree.net ([91.216.110.36]:49818) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T3Y2d-0000Pc-NP for bug-gnu-emacs@gnu.org; Mon, 20 Aug 2012 15:53:40 -0400 From: jca@wxcvbn.org (=?utf-8?Q?J=C3=A9r=C3=A9mie_Courr=C3=A8ges-Anglas?=) To: bug-gnu-emacs@gnu.org Subject: Emacs 24.2 RC1 build fails on OpenBSD Date: Mon, 20 Aug 2012 21:53:16 +0200 Message-ID: <877gstuyqb.fsf@moo.wxcvbn.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 208.118.235.17 X-Spam-Score: -6.9 (------) X-Debbugs-Envelope-To: submit X-Mailman-Approved-At: Mon, 20 Aug 2012 15:57:37 -0400 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.9 (------) --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi. Sorry for being late. The RC1 archive fails to build on OpenBSD/i386 -current (post 5.2) and OpenBSD/macppc -stable (5.1). Emacs 24.1 was building and running properly. I use $ ./configure --without-x && gmake [snip] EMACSLOADPATH=3D/home/jca/src/emacs-24.2/leim/../lisp LC_ALL=3DC ../src/ema= cs -batch --no-site-file --no-site-lisp -l /home/jca/src/emacs-24.2/leim/.= ./lisp/international/qua il \ -f batch-byte-compile-if-not-done quail/CCDOSPY.el quail/Punct.el quail/Q= J.el quail/SW.el quail/TONEPY.el quail/4Corner.el quail/ARRAY30.el quail/EC= DICT.el quail/ETZY.e l quail/Punct-b5.el quail/PY-b5.el quail/QJ-b5.el quail/ZOZY.el quail/tsang= -b5.el quail/quick-b5.el quail/tsang-cns.el quail/quick-cns.el quail/PY.el = quail/ZIRANMA.el qua il/CTLau.el quail/CTLau-b5.el if [ x`(cd /home/jca/src/emacs-24.2/leim && /bin/pwd)` =3D x`(/bin/pwd)` ] = ; then \ EMACSLOADPATH=3D/home/jca/src/emacs-24.2/leim/../lisp LC_ALL=3DC ../src/e= macs -batch --no-site-file --no-site-lisp -l /home/jca/src/emacs-24.2/leim/= ../lisp/international/qu ail \ --eval "(update-leim-list-file \".\")" ; \ else \ EMACSLOADPATH=3D/home/jca/src/emacs-24.2/leim/../lisp LC_ALL=3DC ../src/e= macs -batch --no-site-file --no-site-lisp -l /home/jca/src/emacs-24.2/leim/= ../lisp/international/qu ail \ --eval "(update-leim-list-file \".\" \"/home/jca/src/emacs-24.2/leim\")= " ; \ fi Updating /home/jca/src/emacs-24.2/leim/leim-list.el ... Checking /home/jca/src/emacs-24.2/leim/quail/PY.el ... Checking /home/jca/src/emacs-24.2/leim/quail/quick-cns.el ... Checking /home/jca/src/emacs-24.2/leim/quail/tsang-cns.el ... Checking /home/jca/src/emacs-24.2/leim/quail/ZIRANMA.el ... Checking /home/jca/src/emacs-24.2/leim/quail/CTLau-b5.el ... Checking /home/jca/src/emacs-24.2/leim/quail/CTLau.el ... Checking /home/jca/src/emacs-24.2/leim/quail/quick-b5.el ... Checking /home/jca/src/emacs-24.2/leim/quail/tsang-b5.el ... Checking /home/jca/src/emacs-24.2/leim/quail/ZOZY.el ... Checking /home/jca/src/emacs-24.2/leim/quail/TONEPY.el ... Checking /home/jca/src/emacs-24.2/leim/quail/SW.el ... Checking /home/jca/src/emacs-24.2/leim/quail/QJ.el ... Checking /home/jca/src/emacs-24.2/leim/quail/QJ-b5.el ... Checking /home/jca/src/emacs-24.2/leim/quail/Punct.el ... Checking /home/jca/src/emacs-24.2/leim/quail/Punct-b5.el ... Checking /home/jca/src/emacs-24.2/leim/quail/PY-b5.el ... Checking /home/jca/src/emacs-24.2/leim/quail/ETZY.el ... Checking /home/jca/src/emacs-24.2/leim/quail/ECDICT.el ... Checking /home/jca/src/emacs-24.2/leim/quail/CCDOSPY.el ... Checking /home/jca/src/emacs-24.2/leim/quail/ARRAY30.el ... Checking /home/jca/src/emacs-24.2/leim/quail/4Corner.el ... Checking /home/jca/src/emacs-24.2/leim/quail/indian.el ... Checking /home/jca/src/emacs-24.2/leim/quail/ipa.el ... Checking /home/jca/src/emacs-24.2/leim/quail/latin-post.el ... Checking /home/jca/src/emacs-24.2/leim/quail/czech.el ... Checking /home/jca/src/emacs-24.2/leim/quail/japanese.el ... Checking /home/jca/src/emacs-24.2/leim/quail/thai.el ... Checking /home/jca/src/emacs-24.2/leim/quail/arabic.el ... Checking /home/jca/src/emacs-24.2/leim/quail/hanja3.el ... Checking /home/jca/src/emacs-24.2/leim/quail/latin-ltx.el ... Checking /home/jca/src/emacs-24.2/leim/quail/hanja-jis.el ... Checking /home/jca/src/emacs-24.2/leim/quail/hebrew.el ... Checking /home/jca/src/emacs-24.2/leim/quail/symbol-ksc.el ... Checking /home/jca/src/emacs-24.2/leim/quail/hangul.el ... Checking /home/jca/src/emacs-24.2/leim/quail/lao.el ... Checking /home/jca/src/emacs-24.2/leim/quail/georgian.el ... Checking /home/jca/src/emacs-24.2/leim/quail/croatian.el ... Checking /home/jca/src/emacs-24.2/leim/quail/persian.el ... Checking /home/jca/src/emacs-24.2/leim/quail/hanja.el ... Checking /home/jca/src/emacs-24.2/leim/quail/slovak.el ... Checking /home/jca/src/emacs-24.2/leim/quail/lrt.el ... Checking /home/jca/src/emacs-24.2/leim/quail/tibetan.el ... Checking /home/jca/src/emacs-24.2/leim/quail/pypunct-b5.el ... Checking /home/jca/src/emacs-24.2/leim/quail/sgml-input.el ... Checking /home/jca/src/emacs-24.2/leim/quail/cyril-jis.el ... Fatal error (11)Segmentation fault (core dumped)=20 gmake[1]: *** [leim-list.el] Error 139 gmake[1]: Leaving directory `/home/jca/src/emacs-24.2/leim' gmake: *** [leim] Error 2 $=20 The backtrace looks like this (slightly mangled by copy/paste), using the default `-g -O2' CFLAGS on OpenBSD/powerpc: opyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain condition= s. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "powerpc-unknown-openbsd5.1"... Core was generated by `emacs'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/lib/libossaudio.so.3.1...done. Loaded symbols for /usr/lib/libossaudio.so.3.1 Reading symbols from /usr/local/lib/libdbus-1.so.9.1...done. Loaded symbols for /usr/local/lib/libdbus-1.so.9.1 Reading symbols from /usr/lib/libncurses.so.12.1...done. Loaded symbols for /usr/lib/libncurses.so.12.1 Reading symbols from /usr/lib/libpthread.so.13.3...done. Loaded symbols for /usr/lib/libpthread.so.13.3 Reading symbols from /usr/lib/libm.so.7.0...done. Loaded symbols for /usr/lib/libm.so.7.0 Reading symbols from /usr/lib/libc.so.62.0...done. Loaded symbols for /usr/lib/libc.so.62.0 Reading symbols from /usr/libexec/ld.so...done. Loaded symbols for /usr/libexec/ld.so #0 free_bloc (bloc=3D0x1b8fa80) at ralloc.c:719 719 if (heap->first_bloc =3D=3D bloc) (gdb) bt #0 free_bloc (bloc=3D0x1b8fa80) at ralloc.c:719 #1 0x01968d5c in r_alloc_free (ptr=3D0x2381608) at ralloc.c:939 #2 0x018baf1c in Fkill_buffer (buffer_or_name=3DVariable "buffer_or_name" = is not available. ) at buffer.c:4845 #3 0x0190a630 in Ffuncall (nargs=3D2, args=3DVariable "args" is not availa= ble. ) at eval.c:3001 #4 0x01945070 in exec_byte_code (bytestr=3DVariable "bytestr" is not avail= able. ) at bytecode.c:785 #5 0x019099c8 in eval_sub (form=3DVariable "form" is not available. ) at eval.c:2355 #6 0x01909ccc in Fprogn (args=3DVariable "args" is not available. ) at eval.c:364 #7 0x0190852c in unbind_to (count=3DVariable "count" is not available. ) at eval.c:3433 #8 0x01944fdc in exec_byte_code (bytestr=3DVariable "bytestr" is not avail= able. ) at bytecode.c:807 #9 0x01909fb8 in funcall_lambda (fun=3D31484933, nargs=3D1, arg_vector=3D0= xffff90c8) at eval.c:3232 #10 0x0190a3b4 in Ffuncall (nargs=3D2, args=3DVariable "args" is not availa= ble. ) at eval.c:3062 #11 0x0190acc8 in Fapply (nargs=3D2, args=3D0xffff90c4) at eval.c:2453 #12 0x0190a6d0 in Ffuncall (nargs=3D3, args=3DVariable "args" is not availa= ble. ) at eval.c:2983 #13 0x01945070 in exec_byte_code (bytestr=3DVariable "bytestr" is not avail= able. ) at bytecode.c:785 #14 0x01909fb8 in funcall_lambda (fun=3D27442485, nargs=3D1, arg_vector=3D0= xffff91d0) at eval.c:3232 #15 0x0190b878 in apply_lambda (fun=3D27442485, args=3DVariable "args" is n= ot available. ) at eval.c:3109 #16 0x01909788 in eval_sub (form=3DVariable "form" is not available. ) at eval.c:2413 #17 0x0190c438 in Feval (form=3D29386182, lexical=3DVariable "lexical" is n= ot available. ) at eval.c:2203 #18 0x0190a61c in Ffuncall (nargs=3D2, args=3DVariable "args" is not availa= ble. ) at eval.c:3004 #19 0x01945070 in exec_byte_code (bytestr=3DVariable "bytestr" is not avail= able. ) at bytecode.c:785 #20 0x01909dd4 in funcall_lambda (fun=3D27219261, nargs=3D1, arg_vector=3D0= xffff9564) at eval.c:3166 #21 0x0190a3b4 in Ffuncall (nargs=3D2, args=3DVariable "args" is not availa= ble. ) at eval.c:3062 #22 0x01945070 in exec_byte_code (bytestr=3DVariable "bytestr" is not avail= able. ) at bytecode.c:785 #23 0x01909dd4 in funcall_lambda (fun=3D27206509, nargs=3D0, arg_vector=3D0= xffff9738) at eval.c:3166 #24 0x0190a3b4 in Ffuncall (nargs=3D1, args=3DVariable "args" is not availa= ble. ) at eval.c:3062 #25 0x01945070 in exec_byte_code (bytestr=3DVariable "bytestr" is not avail= able. ) at bytecode.c:785 #26 0x01909dd4 in funcall_lambda (fun=3D27203701, nargs=3D0, arg_vector=3D0= xffff9850) at eval.c:3166 #27 0x0190b878 in apply_lambda (fun=3D27203701, args=3DVariable "args" is n= ot available. ) at eval.c:3109 #28 0x01909788 in eval_sub (form=3DVariable "form" is not available. ) at eval.c:2413 #29 0x0190c438 in Feval (form=3D29389358, lexical=3DVariable "lexical" is n= ot available. ) at eval.c:2203 #30 0x0189cbe8 in top_level_2 () at keyboard.c:1169 #31 0x0190d6fc in internal_condition_case (bfun=3D0x189cbc8 , handlers=3D29186386, hfun=3D0x18a0f74 ) at eval.c:1514 #32 0x018a1430 in top_level_1 (ignore=3DVariable "ignore" is not available. ) at keyboard.c:1177 #33 0x0190d804 in internal_catch (tag=3DVariable "tag" is not available. ) at eval.c:1271 #34 0x018a1260 in recursive_edit_1 () at keyboard.c:1132 #35 0x018a13d0 in Frecursive_edit () at keyboard.c:823 #36 0x01895718 in main (argc=3D8, argv=3D0x0) at emacs.c:1715 The same error happens consistently on both architectures (whether I use `--without-x' or not). $ ./configure --without-x REL_ALLOC=3Dno and $ ./configure --without-x CFLAGS=3D-g both seem to `fix' the problem, but I've only done light testing so far. Using git bisect, I was able to track the build error up to the 573c8f870aa68b8c5937524e1a4db645026a3240 git commit id: Backport: Really fix bug #11519, by fixing the last change in ralloc.c. src/ralloc.c (r_alloc_inhibit_buffer_relocation): Fix stupid thinko in the logic of incrementing and decrementing the value of use_relocatable_buffers. Sorry for not providing the hg commit id. Reverting that commit actually makes rc1 build again, but I have not tried to find a proper fix. On the other hand, rc1 builds and seems to work fine so far on Debian Squeeze (powerpc). :) Please don't hesitate if you need further action on my part. Regards, =2D-=20 J=C3=A9r=C3=A9mie Courr=C3=A8ges-Anglas GPG fingerprint: 61DB D9A0 00A4 67CF 2A90 8961 6191 8FBF 06A1 1494 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (OpenBSD) iQIcBAEBCgAGBQJQMpWtAAoJEGGRj78GoRSUpggQAJ9PrSYX1rXdUChnFWvVvtA9 3bhIMLttr+uZOrYftmk+ncmMyMuOvj1gMkWzrMfsOG3BIOEK/IoD70zKzHEqYySd pYa1CBHcM0go1dzqOcFMymFqbiCjYofTo59/t86pQdqSDfUodb5AU80nYjgsSUH0 8ylGvNhARSQGyfm9nYU29fqm8DaXZ9b8z7Zsu/5igsu5a4wasLyOfVGxQJhoOir8 GOliBGmJ2ic0F/KxsbIHltDbK3vpWa7Cd7hrMPqLHHt5WqRMYCH2ExoHjAwO1oLD cV73aY0zhtYNNBYp1T3O/2Y+GTcV43LZq5sZQ2wJg73Dg1PrS94GcMs+q6WPmAun 6YQtcpqeTkJeNX9GnEHbaDYAaF04n/xiuKDisvz9RsmFhhuLdAto8JZF5ymyra1G JC3zyVMFbEU8DS3WpJV/9E7BsI/r8szxObqQxrO1/JfOu4c24Wxvn641d1e43Uuf x0LCiZ4KgZe6sIaylfkwliIalTWMoi3yNhibBzUQJkwoo2qPsLBmQymfcbIwhY0T trqW3nY7zs81Lnsc0j8H5doLd7BlEXHBG+wIR7f5c/h3fTe2J9fIBiFDhcqGVcDm 3zrseuwnZBUuPRTINN2W/e9DseC6x2CNVj6fLJyVrCC0WG2zroQH1FB8sPm7F8fL ClWsycosI3mZpFtAjrlz =7kgD -----END PGP SIGNATURE----- --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Mon Aug 20 23:03:55 2012 Received: (at 12242) by debbugs.gnu.org; 21 Aug 2012 03:03:55 +0000 Received: from localhost ([127.0.0.1]:40745 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1T3el1-0003Sm-CY for submit@debbugs.gnu.org; Mon, 20 Aug 2012 23:03:55 -0400 Received: from mtaout23.012.net.il ([80.179.55.175]:48896) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1T3eky-0003Sb-IQ for 12242@debbugs.gnu.org; Mon, 20 Aug 2012 23:03:53 -0400 Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0M9300D0049V5Q00@a-mtaout23.012.net.il> for 12242@debbugs.gnu.org; Tue, 21 Aug 2012 06:03:34 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0M9300CQ64HYX990@a-mtaout23.012.net.il>; Tue, 21 Aug 2012 06:03:34 +0300 (IDT) Date: Tue, 21 Aug 2012 06:03:37 +0300 From: Eli Zaretskii Subject: Re: bug#12242: Emacs 24.2 RC1 build fails on OpenBSD In-reply-to: <877gstuyqb.fsf@moo.wxcvbn.org> To: jca@wxcvbn.org (=?utf-8?Q?J=C3=A9r=C3=A9mie_Courr=C3=A8ges-Anglas?=) Message-id: <83txvxaquu.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: QUOTED-PRINTABLE X-012-Sender: halo1@inter.net.il References: <877gstuyqb.fsf@moo.wxcvbn.org> X-Spam-Score: -1.2 (-) X-Debbugs-Envelope-To: 12242 Cc: 12242@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.2 (-) > From: jca@wxcvbn.org (J=C3=A9r=C3=A9mie Courr=C3=A8ges-Anglas) > Date: Mon, 20 Aug 2012 21:53:16 +0200 >=20 > Checking /home/jca/src/emacs-24.2/leim/quail/cyril-jis.el ... > Fatal error (11)Segmentation fault (core dumped)=20 > gmake[1]: *** [leim-list.el] Error 139 > gmake[1]: Leaving directory `/home/jca/src/emacs-24.2/leim' > gmake: *** [leim] Error 2 > $=20 > [...] > #0 free_bloc (bloc=3D0x1b8fa80) at ralloc.c:719 > 719 if (heap->first_bloc =3D=3D bloc) > (gdb) bt > #0 free_bloc (bloc=3D0x1b8fa80) at ralloc.c:719 > [...] > Using git bisect, I was able to track the build error up to the > 573c8f870aa68b8c5937524e1a4db645026a3240 git commit id: >=20 > Backport: Really fix bug #11519, by fixing the last change in = ralloc.c. >=20 > src/ralloc.c (r_alloc_inhibit_buffer_relocation): Fix stupid > thinko > in the logic of incrementing and decrementing the value of > use_relocatable_buffers. >=20 > Sorry for not providing the hg commit id. > Reverting that commit actually makes rc1 build again, but I have no= t > tried to find a proper fix. I think I see the problem and will fix it later today. From debbugs-submit-bounces@debbugs.gnu.org Tue Aug 21 12:50:13 2012 Received: (at 12242) by debbugs.gnu.org; 21 Aug 2012 16:50:13 +0000 Received: from localhost ([127.0.0.1]:41774 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1T3ref-00061d-Hg for submit@debbugs.gnu.org; Tue, 21 Aug 2012 12:50:13 -0400 Received: from mtaout20.012.net.il ([80.179.55.166]:43295) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1T3reb-00061T-Q7 for 12242@debbugs.gnu.org; Tue, 21 Aug 2012 12:50:11 -0400 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0M94003006KLYZ00@a-mtaout20.012.net.il> for 12242@debbugs.gnu.org; Tue, 21 Aug 2012 19:49:48 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0M94003E36R0U840@a-mtaout20.012.net.il>; Tue, 21 Aug 2012 19:49:48 +0300 (IDT) Date: Tue, 21 Aug 2012 19:49:52 +0300 From: Eli Zaretskii Subject: Re: bug#12242: Emacs 24.2 RC1 build fails on OpenBSD In-reply-to: <83txvxaquu.fsf@gnu.org> X-012-Sender: halo1@inter.net.il To: jca@wxcvbn.org Message-id: <83obm4b367.fsf@gnu.org> References: <877gstuyqb.fsf@moo.wxcvbn.org> <83txvxaquu.fsf@gnu.org> X-Spam-Score: -1.2 (-) X-Debbugs-Envelope-To: 12242 Cc: 12242@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.2 (-) > Date: Tue, 21 Aug 2012 06:03:37 +0300 > From: Eli Zaretskii > Cc: 12242@debbugs.gnu.org > > I think I see the problem and will fix it later today. Actually, no, I don't think I see the problem. What does the following GDB command print in frame #0? (gdb) p *heap Also, could you please run Emacs under GDB, and when it crashes, type the following commands, which define a new command "heaps", and then run it? Like this: (gdb) define heaps Type commands for definition of "heaps". End with a line saying just "end". >set $a = first_heap >while $a >p *$a >set $a = $a->next >end >end (gdb) heaps Please post here everything that GDB prints as result. Thanks. From debbugs-submit-bounces@debbugs.gnu.org Tue Aug 21 15:24:08 2012 Received: (at 12242) by debbugs.gnu.org; 21 Aug 2012 19:24:08 +0000 Received: from localhost ([127.0.0.1]:41935 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1T3u3b-0003ck-D7 for submit@debbugs.gnu.org; Tue, 21 Aug 2012 15:24:08 -0400 Received: from chomsky.autogeree.net ([91.216.110.36]:40983) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1T3u3X-0003cb-Ns for 12242@debbugs.gnu.org; Tue, 21 Aug 2012 15:24:05 -0400 From: jca@wxcvbn.org (=?utf-8?Q?J=C3=A9r=C3=A9mie_Courr=C3=A8ges-Anglas?=) To: Eli Zaretskii Subject: Re: bug#12242: Emacs 24.2 RC1 build fails on OpenBSD References: <877gstuyqb.fsf@moo.wxcvbn.org> <83txvxaquu.fsf@gnu.org> <83obm4b367.fsf@gnu.org> Date: Tue, 21 Aug 2012 21:23:38 +0200 In-Reply-To: <83obm4b367.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 21 Aug 2012 19:49:52 +0300") Message-ID: <87wr0sqcat.fsf@moo.wxcvbn.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 12242 Cc: 12242@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Eli Zaretskii writes: >> Date: Tue, 21 Aug 2012 06:03:37 +0300 >> From: Eli Zaretskii >> Cc: 12242@debbugs.gnu.org >>=20 >> I think I see the problem and will fix it later today. > > Actually, no, I don't think I see the problem. What does the > following GDB command print in frame #0? > > (gdb) p *heap > > Also, could you please run Emacs under GDB, and when it crashes, type > the following commands, which define a new command "heaps", and then > run it? Like this: > > (gdb) define heaps > Type commands for definition of "heaps". > End with a line saying just "end". > >set $a =3D first_heap > >while $a > >p *$a > >set $a =3D $a->next > >end > >end > (gdb) heaps > > Please post here everything that GDB prints as result. if [ x`(cd /home/emacs24/src/emacs-24.2/leim && /bin/pwd)` =3D x`(/bin/pwd)= ` ] ; then \ env EMACSLOADPATH=3D/home/emacs24/src/emacs-24.2/leim/../lisp LC_ALL=3DC = gdb --args ../src/emacs --batch --no-site-file --no-site-lisp -l /home/emac= s24/src/emacs-24.2/leim/ ../lisp/international/quail \ --eval "(update-leim-list-file \".\")" ; \ else \ env EMACSLOADPATH=3D/home/emacs24/src/emacs-24.2/leim/../lisp LC_ALL=3DC = gdb --args ../src/emacs --batch --no-site-file --no-site-lisp -l /home/emac= s24/src/emacs-24.2/leim/ ../lisp/international/quail \ --eval "(update-leim-list-file \".\" \"/home/emacs24/src/emacs-24.2/lei= m\")" ; \ fi GNU gdb 6.3 Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain condition= s. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-unknown-openbsd5.2"... (gdb) run=20=20=20=20=20=20=20=20=20=20=20=20=20 Starting program: /home/emacs24/src/emacs-24.2/src/emacs --batch --no-site-= file --no-site-lisp -l /home/emacs24/src/emacs-24.2/leim/../lisp/internatio= nal/quail --eval \(u pdate-leim-list-file\ \".\"\) Updating /home/emacs24/src/emacs-24.2/leim/leim-list.el ... Checking /home/emacs24/src/emacs-24.2/leim/quail/PY.el ... Checking /home/emacs24/src/emacs-24.2/leim/quail/quick-cns.el ... Checking /home/emacs24/src/emacs-24.2/leim/quail/tsang-cns.el ... Checking /home/emacs24/src/emacs-24.2/leim/quail/ZIRANMA.el ... Checking /home/emacs24/src/emacs-24.2/leim/quail/CTLau-b5.el ... Checking /home/emacs24/src/emacs-24.2/leim/quail/CTLau.el ... Checking /home/emacs24/src/emacs-24.2/leim/quail/quick-b5.el ... Checking /home/emacs24/src/emacs-24.2/leim/quail/tsang-b5.el ... Checking /home/emacs24/src/emacs-24.2/leim/quail/ZOZY.el ... Checking /home/emacs24/src/emacs-24.2/leim/quail/TONEPY.el ... Checking /home/emacs24/src/emacs-24.2/leim/quail/SW.el ... Checking /home/emacs24/src/emacs-24.2/leim/quail/QJ.el ... Checking /home/emacs24/src/emacs-24.2/leim/quail/QJ-b5.el ... Checking /home/emacs24/src/emacs-24.2/leim/quail/Punct.el ... Checking /home/emacs24/src/emacs-24.2/leim/quail/Punct-b5.el ... Checking /home/emacs24/src/emacs-24.2/leim/quail/PY-b5.el ... Checking /home/emacs24/src/emacs-24.2/leim/quail/ETZY.el ... Checking /home/emacs24/src/emacs-24.2/leim/quail/ECDICT.el ... Checking /home/emacs24/src/emacs-24.2/leim/quail/CCDOSPY.el ... Checking /home/emacs24/src/emacs-24.2/leim/quail/ARRAY30.el ... Checking /home/emacs24/src/emacs-24.2/leim/quail/4Corner.el ... Checking /home/emacs24/src/emacs-24.2/leim/quail/indian.el ... Checking /home/emacs24/src/emacs-24.2/leim/quail/ipa.el ... Checking /home/emacs24/src/emacs-24.2/leim/quail/latin-post.el ... Checking /home/emacs24/src/emacs-24.2/leim/quail/czech.el ... Checking /home/emacs24/src/emacs-24.2/leim/quail/japanese.el ... Checking /home/emacs24/src/emacs-24.2/leim/quail/thai.el ... Checking /home/emacs24/src/emacs-24.2/leim/quail/arabic.el ... Checking /home/emacs24/src/emacs-24.2/leim/quail/hanja3.el ... Checking /home/emacs24/src/emacs-24.2/leim/quail/latin-ltx.el ... Checking /home/emacs24/src/emacs-24.2/leim/quail/hanja-jis.el ... Checking /home/emacs24/src/emacs-24.2/leim/quail/hebrew.el ... Checking /home/emacs24/src/emacs-24.2/leim/quail/symbol-ksc.el ... Checking /home/emacs24/src/emacs-24.2/leim/quail/hangul.el ... Checking /home/emacs24/src/emacs-24.2/leim/quail/lao.el ... Checking /home/emacs24/src/emacs-24.2/leim/quail/georgian.el ... Checking /home/emacs24/src/emacs-24.2/leim/quail/croatian.el ... Checking /home/emacs24/src/emacs-24.2/leim/quail/persian.el ... Checking /home/emacs24/src/emacs-24.2/leim/quail/hanja.el ... Checking /home/emacs24/src/emacs-24.2/leim/quail/slovak.el ... Checking /home/emacs24/src/emacs-24.2/leim/quail/lrt.el ... Checking /home/emacs24/src/emacs-24.2/leim/quail/tibetan.el ... Checking /home/emacs24/src/emacs-24.2/leim/quail/pypunct-b5.el ... Checking /home/emacs24/src/emacs-24.2/leim/quail/sgml-input.el ... Checking /home/emacs24/src/emacs-24.2/leim/quail/cyril-jis.el ... Program received signal SIGSEGV, Segmentation fault. free_bloc (bloc=3D0x85eb8a0) at ralloc.c:719 719 if (heap->first_bloc =3D=3D bloc) (gdb) p heap $1 =3D 0x8f12000 (gdb) p *heap Cannot access memory at address 0x8f12000 (gdb) define heaps Type commands for definition of "heaps". End with a line saying just "end". >set $a =3D first_heap >while $a >p *$a >set $a =3D $a->next >end >end (gdb) heaps $2 =3D {next =3D 0x0, prev =3D 0x0, start =3D 0x8edf000, end =3D 0x8f02000,= bloc_start =3D 0x8eec000, free =3D 0x8ef2a58, first_bloc =3D 0x85eb8a0, la= st_bloc =3D 0x85eb8a0} (gdb) Again, please don't hesitate if you need further input. =2D-=20 J=C3=A9r=C3=A9mie Courr=C3=A8ges-Anglas Empreinte GPG : 61DB D9A0 00A4 67CF 2A90 8961 6191 8FBF 06A1 1494 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (OpenBSD) iQIcBAEBCgAGBQJQM+A7AAoJEGGRj78GoRSU0KQP/3UCNkulAIDO75eMRDn/26pY 3KbfogASS19DauzAjigCaTU+CY4CBU3KCDeZldhsxTlqXScoWwpEL//iWHakmlJk o5nJBbIlXfj3CelxZWP4uqRVQERPufWk+kGSP2DUnxDXaU+USG4gU+uwwNJQZuiR ZkFlLUq8L6WF82vZvqAvuNYePJ2sDfn2LpmDaTQm8nEknQuVwZLcPrr3coHRg7JU cvVW4/M+2BUVFOevXH2rollibJtCZtXzFwYE7O2hEHIJbxPA+5i6RPy94oVqi+Wz 9LDeVDuln4IB8JCCg52FMKmCDg78+eRkHHeOleGQaA3+pyHPzTrJnWppWdcvdvpJ ftHz4L92faUW6I2XKNIoKcJoMxm30zrXHIZ/mJIXvrLAL2bN/GysQ7GmkoTdnOGd w1j9v1IqhGVIywyCFsLoBGFgYNe863t2Vdsz82NtbYDFwdRWawSXW3IT2a6C7RQ2 w3fHj/8SbSZ4MBsoMWFVk/n6Uwpb9XGFYyD2OgWnncwk8ve4LJKkrWcEC8FITGZn TITuccskt9YmCuoV1b4D19Gn+t5ai4KkRsBokGim8adeB0e9GhcwYjPAjljl62az JBc5bh9m57Y9tZ82n70Q+m4a2mUEmYcJRjEiFcQshTa/XKBUCtc2hrzo3KMrMe51 1ERKet59QEdCRCqW2prZ =EO/3 -----END PGP SIGNATURE----- --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Tue Aug 21 22:35:59 2012 Received: (at 12242) by debbugs.gnu.org; 22 Aug 2012 02:35:59 +0000 Received: from localhost ([127.0.0.1]:42260 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1T40nW-0005mu-5v for submit@debbugs.gnu.org; Tue, 21 Aug 2012 22:35:58 -0400 Received: from mathmail.math.s.chiba-u.ac.jp ([133.82.132.2]:64614) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1T40nQ-0005mg-JU for 12242@debbugs.gnu.org; Tue, 21 Aug 2012 22:35:54 -0400 Received: from church.math.s.chiba-u.ac.jp (church [133.82.132.36]) by mathmail.math.s.chiba-u.ac.jp (Postfix) with ESMTP id 85DF2C055D; Wed, 22 Aug 2012 11:35:26 +0900 (JST) Date: Wed, 22 Aug 2012 11:35:26 +0900 Message-ID: From: YAMAMOTO Mitsuharu To: Eli Zaretskii Subject: Re: bug#12242: Emacs 24.2 RC1 build fails on OpenBSD In-Reply-To: <83obm4b367.fsf@gnu.org> References: <877gstuyqb.fsf@moo.wxcvbn.org> <83txvxaquu.fsf@gnu.org> <83obm4b367.fsf@gnu.org> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.6 Emacs/22.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) Organization: Faculty of Science, Chiba University MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: -2.1 (--) X-Debbugs-Envelope-To: 12242 Cc: 12242@debbugs.gnu.org, jca@wxcvbn.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.1 (--) >>>>> On Tue, 21 Aug 2012 19:49:52 +0300, Eli Zaretskii said: >> Date: Tue, 21 Aug 2012 06:03:37 +0300 From: Eli Zaretskii >> Cc: 12242@debbugs.gnu.org >> >> I think I see the problem and will fix it later today. > Actually, no, I don't think I see the problem. I took a look at ralloc.c a bit, and I thought that the variable `use_relocatable_buffers' is not designed to be changed temporarily in the first place. I think we should use r_alloc_freeze/r_alloc_thaw instead of r_alloc_inhibit_buffer_relocation calls. In that case, we have to estimate how much memory can be malloc'ed while the relocation is frozen, so that we can pass an appropriate number to r_alloc_freeze. YAMAMOTO Mitsuharu mituharu@math.s.chiba-u.ac.jp From debbugs-submit-bounces@debbugs.gnu.org Tue Aug 21 23:02:48 2012 Received: (at 12242) by debbugs.gnu.org; 22 Aug 2012 03:02:48 +0000 Received: from localhost ([127.0.0.1]:42279 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1T41DU-0006Px-EU for submit@debbugs.gnu.org; Tue, 21 Aug 2012 23:02:48 -0400 Received: from mtaout20.012.net.il ([80.179.55.166]:60895) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1T41DS-0006Pp-WF for 12242@debbugs.gnu.org; Tue, 21 Aug 2012 23:02:48 -0400 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0M9400900Z0ZKN00@a-mtaout20.012.net.il> for 12242@debbugs.gnu.org; Wed, 22 Aug 2012 06:02:01 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0M940098JZ3DBU50@a-mtaout20.012.net.il>; Wed, 22 Aug 2012 06:02:01 +0300 (IDT) Date: Wed, 22 Aug 2012 06:02:06 +0300 From: Eli Zaretskii Subject: Re: bug#12242: Emacs 24.2 RC1 build fails on OpenBSD In-reply-to: X-012-Sender: halo1@inter.net.il To: YAMAMOTO Mitsuharu Message-id: <837gsrbpe9.fsf@gnu.org> References: <877gstuyqb.fsf@moo.wxcvbn.org> <83txvxaquu.fsf@gnu.org> <83obm4b367.fsf@gnu.org> X-Spam-Score: -1.2 (-) X-Debbugs-Envelope-To: 12242 Cc: 12242@debbugs.gnu.org, jca@wxcvbn.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.2 (-) > Date: Wed, 22 Aug 2012 11:35:26 +0900 > From: YAMAMOTO Mitsuharu > Cc: jca@wxcvbn.org, > 12242@debbugs.gnu.org > > I took a look at ralloc.c a bit, and I thought that the variable > `use_relocatable_buffers' is not designed to be changed temporarily in > the first place. Why not? Can you tell what led you to that conclusion? My reading of the code is that inhibiting relocation just means that ralloc.c always asks for more memory when it cannot find a large enough block in the existing heaps. From debbugs-submit-bounces@debbugs.gnu.org Tue Aug 21 23:13:53 2012 Received: (at 12242) by debbugs.gnu.org; 22 Aug 2012 03:13:53 +0000 Received: from localhost ([127.0.0.1]:42291 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1T41OC-0006f4-Rx for submit@debbugs.gnu.org; Tue, 21 Aug 2012 23:13:53 -0400 Received: from mathmail.math.s.chiba-u.ac.jp ([133.82.132.2]:64592) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1T41OB-0006ex-8X for 12242@debbugs.gnu.org; Tue, 21 Aug 2012 23:13:52 -0400 Received: from church.math.s.chiba-u.ac.jp (church [133.82.132.36]) by mathmail.math.s.chiba-u.ac.jp (Postfix) with ESMTP id 664B1C055D; Wed, 22 Aug 2012 12:13:27 +0900 (JST) Date: Wed, 22 Aug 2012 12:13:27 +0900 Message-ID: From: YAMAMOTO Mitsuharu To: Eli Zaretskii Subject: Re: bug#12242: Emacs 24.2 RC1 build fails on OpenBSD In-Reply-To: <837gsrbpe9.fsf@gnu.org> References: <877gstuyqb.fsf@moo.wxcvbn.org> <83txvxaquu.fsf@gnu.org> <83obm4b367.fsf@gnu.org> <837gsrbpe9.fsf@gnu.org> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.6 Emacs/22.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) Organization: Faculty of Science, Chiba University MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: -2.1 (--) X-Debbugs-Envelope-To: 12242 Cc: 12242@debbugs.gnu.org, jca@wxcvbn.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.1 (--) >>>>> On Wed, 22 Aug 2012 06:02:06 +0300, Eli Zaretskii said: >> Date: Wed, 22 Aug 2012 11:35:26 +0900 From: YAMAMOTO Mitsuharu >> Cc: jca@wxcvbn.org, >> 12242@debbugs.gnu.org >> >> I took a look at ralloc.c a bit, and I thought that the variable >> `use_relocatable_buffers' is not designed to be changed temporarily >> in the first place. > Why not? Can you tell what led you to that conclusion? > My reading of the code is that inhibiting relocation just means that > ralloc.c always asks for more memory when it cannot find a large > enough block in the existing heaps. For example, `virtual_break_value' is not updated in that case. It can lead to an inconsistent state as reported if r_alloc_sbrk is called with a positive argument via malloc when use_relocatable_buffers <= 0, and then it is called with a negative argument via free when use_relocatable_buffers > 0. YAMAMOTO Mitsuharu mituharu@math.s.chiba-u.ac.jp From debbugs-submit-bounces@debbugs.gnu.org Wed Aug 22 12:58:36 2012 Received: (at 12242) by debbugs.gnu.org; 22 Aug 2012 16:58:37 +0000 Received: from localhost ([127.0.0.1]:43650 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1T4EGK-0003wA-6Y for submit@debbugs.gnu.org; Wed, 22 Aug 2012 12:58:36 -0400 Received: from mtaout23.012.net.il ([80.179.55.175]:64125) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1T4EGH-0003vz-Bq for 12242@debbugs.gnu.org; Wed, 22 Aug 2012 12:58:35 -0400 Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0M96002000W58E00@a-mtaout23.012.net.il> for 12242@debbugs.gnu.org; Wed, 22 Aug 2012 19:58:06 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0M960027X1ST25C0@a-mtaout23.012.net.il>; Wed, 22 Aug 2012 19:58:06 +0300 (IDT) Date: Wed, 22 Aug 2012 19:58:12 +0300 From: Eli Zaretskii Subject: Re: bug#12242: Emacs 24.2 RC1 build fails on OpenBSD In-reply-to: X-012-Sender: halo1@inter.net.il To: YAMAMOTO Mitsuharu , Stefan Monnier , Chong Yidong , Kenichi Handa Message-id: <83y5l6amor.fsf@gnu.org> References: <877gstuyqb.fsf@moo.wxcvbn.org> <83txvxaquu.fsf@gnu.org> <83obm4b367.fsf@gnu.org> <837gsrbpe9.fsf@gnu.org> X-Spam-Score: -1.2 (-) X-Debbugs-Envelope-To: 12242 Cc: 12242@debbugs.gnu.org, jca@wxcvbn.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.2 (-) > Date: Wed, 22 Aug 2012 12:13:27 +0900 > From: YAMAMOTO Mitsuharu > Cc: jca@wxcvbn.org, > 12242@debbugs.gnu.org > > >>>>> On Wed, 22 Aug 2012 06:02:06 +0300, Eli Zaretskii said: > > >> Date: Wed, 22 Aug 2012 11:35:26 +0900 From: YAMAMOTO Mitsuharu > >> Cc: jca@wxcvbn.org, > >> 12242@debbugs.gnu.org > >> > >> I took a look at ralloc.c a bit, and I thought that the variable > >> `use_relocatable_buffers' is not designed to be changed temporarily > >> in the first place. > > > Why not? Can you tell what led you to that conclusion? > > > My reading of the code is that inhibiting relocation just means that > > ralloc.c always asks for more memory when it cannot find a large > > enough block in the existing heaps. > > For example, `virtual_break_value' is not updated in that case. It > can lead to an inconsistent state as reported if r_alloc_sbrk is > called with a positive argument via malloc when > use_relocatable_buffers <= 0, and then it is called with a negative > argument via free when use_relocatable_buffers > 0. I see your point. Unfortunately, using r_alloc_freeze/r_alloc_thaw doesn't seem to be workable in practice, either. I tried to use it, and the best patch I could come up with (got me through several bootstraps with different compiler switches) is below. It is (a) butt-ugly, and (b) very fragile, for the reasons I explain below. Basically, the difficulty is to know which number to pass to r_alloc_freeze. The only place that knows how much memory is to be allocated is the code that actually allocates it. So I cannot put the call to r_alloc_freeze in maybe_unify_char, where we now call r_alloc_inhibit_buffer_relocation, because the memory allocations are in the functions called from there, and the amount of memory is not known to the caller in advance. Moreover, at least one of the functions called from maybe_unify_char via load_charset allocates memory in a data-dependent loop, so I think it is in principle impossible to know how much memory it can ask for. What's worse, malloc (at least the implementation in gmalloc.c) will actually allocate more than it was asked for, and sometimes allocates an additional chunk of memory on top of that to expand its internal tables where it maintains information about the arena. The size of this additional chunk is also data-dependent, so the value I add in r_alloc_freeze in the patch below is not guaranteed to work, it's based on what I saw during a bootstrap, with some safety margin added for good measure. So it sounds like the only practical way out of this mess is to step back one notch and talk about bug #11519, which was the cause for inhibiting relocations while maybe_unify_char is in progress. At the time, Handa-san promised to work on removing unify_char, but I guess that job is not yet done, since it isn't even on the trunk. Ken'ichi, what would it take to do this now? Another alternative would be to rewrite load_charset_map_from_file and load_charset_map_from_vector so as not to allocate the large structs they do now. (These functions also create char-tables, but I think a char-table is enlarged 256 elements at a time, which doesn't cross the threshold of "large" allocations that can trigger relocation in ralloc.c. Am I missing something?) Yet another possibility is to disable relocations entirely on all platforms but MS-Windows (where the crash which triggered this bug report doesn't happen, probably because there we reserve the memory at startup in one contiguous block). Any other suggestions and thoughts are welcome. Last, but not least: I'm very sorry for this obstacle to making an emergency release. It always bewilders me how such problems can lie dormant for so long, until the most un-opportune moment. Here's the patch that I DON'T recommend to install: --- src/ralloc.c~0 2012-06-29 17:50:48.000000000 +0300 +++ src/ralloc.c 2012-08-22 16:59:32.511794000 +0300 @@ -1022,12 +1022,22 @@ r_re_alloc (POINTER *ptr, SIZE size) void r_alloc_freeze (long int size) { if (! r_alloc_initialized) r_alloc_init (); /* If already frozen, we can't make any more room, so don't try. */ if (r_alloc_freeze_level > 0) size = 0; + else + { + /* malloc will usually ask for more than its callers, so ensure + we have some extra room. */ + size += (max (__malloc_extra_blocks, 64) + 1) * 4096; + /* gmalloc will sometimes need to enlarge its internal tables, + which asks for yet more memory. */ + size += size / 4; + } /* If we can't get the amount requested, half is better than nothing. */ while (size > 0 && r_alloc_sbrk (size) == 0) size /= 2; --- src/charset.c~0 2012-06-29 17:50:48.000000000 +0300 +++ src/charset.c 2012-08-22 14:41:55.981714000 +0300 @@ -214,6 +214,10 @@ static struct text and a string data may be relocated. */ int charset_map_loaded; +/* Flag used to signal to load_charset_* that it is unsafe to relocate + buffers (indirectly via calls to rel_alloc_* functions in ralloc.c). */ +static int in_maybe_unify_char; + struct charset_map_entries { struct { @@ -293,7 +297,20 @@ load_charset_map (struct charset *charse else { if (! temp_charset_work) - temp_charset_work = xmalloc (sizeof (*temp_charset_work)); + { +#ifdef REL_ALLOC + /* Allocating heap memory screws callers of this + function through STRING_CHAR_* macros that hold C + pointers to buffer text, if REL_ALLOC is used. */ + if (in_maybe_unify_char) + r_alloc_freeze (sizeof (*temp_charset_work)); +#endif + temp_charset_work = xmalloc (sizeof (*temp_charset_work)); +#ifdef REL_ALLOC + if (in_maybe_unify_char) + r_alloc_thaw (); +#endif + } if (control_flag == 1) { memset (temp_charset_work->table.decoder, -1, @@ -498,8 +515,19 @@ load_charset_map_from_file (struct chars /* Use SAFE_ALLOCA instead of alloca, as `charset_map_entries' is large (larger than MAX_ALLOCA). */ +#ifdef REL_ALLOC + /* The calls to SAFE_ALLOCA below can allocate heap memory, which + screws callers of this function through STRING_CHAR_* macros that + hold C pointers to buffer text, if REL_ALLOC is used. */ + if (in_maybe_unify_char) + r_alloc_freeze (sizeof (struct charset_map_entries)); +#endif SAFE_ALLOCA (head, struct charset_map_entries *, sizeof (struct charset_map_entries)); +#ifdef REL_ALLOC + if (in_maybe_unify_char) + r_alloc_thaw (); +#endif entries = head; memset (entries, 0, sizeof (struct charset_map_entries)); @@ -530,8 +558,16 @@ load_charset_map_from_file (struct chars if (n_entries > 0 && (n_entries % 0x10000) == 0) { +#ifdef REL_ALLOC + if (in_maybe_unify_char) + r_alloc_freeze (sizeof (struct charset_map_entries)); +#endif SAFE_ALLOCA (entries->next, struct charset_map_entries *, sizeof (struct charset_map_entries)); +#ifdef REL_ALLOC + if (in_maybe_unify_char) + r_alloc_thaw (); +#endif entries = entries->next; memset (entries, 0, sizeof (struct charset_map_entries)); } @@ -566,8 +602,19 @@ load_charset_map_from_vector (struct cha /* Use SAFE_ALLOCA instead of alloca, as `charset_map_entries' is large (larger than MAX_ALLOCA). */ +#ifdef REL_ALLOC + /* The calls to SAFE_ALLOCA below can allocate heap memory, which + screws callers of this function through STRING_CHAR_* macros that + hold C pointers to buffer text, if REL_ALLOC is used. */ + if (in_maybe_unify_char) + r_alloc_freeze (sizeof (struct charset_map_entries)); +#endif SAFE_ALLOCA (head, struct charset_map_entries *, sizeof (struct charset_map_entries)); +#ifdef REL_ALLOC + if (in_maybe_unify_char) + r_alloc_thaw (); +#endif entries = head; memset (entries, 0, sizeof (struct charset_map_entries)); @@ -603,8 +650,16 @@ load_charset_map_from_vector (struct cha if (n_entries > 0 && (n_entries % 0x10000) == 0) { +#ifdef REL_ALLOC + if (in_maybe_unify_char) + r_alloc_freeze (sizeof (struct charset_map_entries)); +#endif SAFE_ALLOCA (entries->next, struct charset_map_entries *, sizeof (struct charset_map_entries)); +#ifdef REL_ALLOC + if (in_maybe_unify_char) + r_alloc_thaw (); +#endif entries = entries->next; memset (entries, 0, sizeof (struct charset_map_entries)); } @@ -1641,13 +1696,9 @@ maybe_unify_char (int c, Lisp_Object val return c; CHECK_CHARSET_GET_CHARSET (val, charset); -#ifdef REL_ALLOC - /* The call to load_charset below can allocate memory, whcih screws - callers of this function through STRING_CHAR_* macros that hold C - pointers to buffer text, if REL_ALLOC is used. */ - r_alloc_inhibit_buffer_relocation (1); -#endif + in_maybe_unify_char++; load_charset (charset, 1); + in_maybe_unify_char--; if (! inhibit_load_charset_map) { val = CHAR_TABLE_REF (Vchar_unify_table, c); @@ -1662,9 +1713,6 @@ maybe_unify_char (int c, Lisp_Object val if (unified > 0) c = unified; } -#ifdef REL_ALLOC - r_alloc_inhibit_buffer_relocation (0); -#endif return c; } From debbugs-submit-bounces@debbugs.gnu.org Wed Aug 22 19:13:13 2012 Received: (at 12242) by debbugs.gnu.org; 22 Aug 2012 23:13:13 +0000 Received: from localhost ([127.0.0.1]:43932 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1T4K6q-0005ae-EI for submit@debbugs.gnu.org; Wed, 22 Aug 2012 19:13:13 -0400 Received: from mathmail.math.s.chiba-u.ac.jp ([133.82.132.2]:64190) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1T4K6m-0005aS-CI for 12242@debbugs.gnu.org; Wed, 22 Aug 2012 19:13:10 -0400 Received: from church.math.s.chiba-u.ac.jp (church [133.82.132.36]) by mathmail.math.s.chiba-u.ac.jp (Postfix) with ESMTP id A4A6CC055D; Thu, 23 Aug 2012 08:12:37 +0900 (JST) Date: Thu, 23 Aug 2012 08:12:37 +0900 Message-ID: From: YAMAMOTO Mitsuharu To: Eli Zaretskii Subject: Re: bug#12242: Emacs 24.2 RC1 build fails on OpenBSD In-Reply-To: <83y5l6amor.fsf@gnu.org> References: <877gstuyqb.fsf@moo.wxcvbn.org> <83txvxaquu.fsf@gnu.org> <83obm4b367.fsf@gnu.org> <837gsrbpe9.fsf@gnu.org> <83y5l6amor.fsf@gnu.org> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.6 Emacs/22.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) Organization: Faculty of Science, Chiba University MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: -2.1 (--) X-Debbugs-Envelope-To: 12242 Cc: jca@wxcvbn.org, Kenichi Handa , 12242@debbugs.gnu.org, Chong Yidong , Stefan Monnier , YAMAMOTO Mitsuharu X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.1 (--) >>>>> On Wed, 22 Aug 2012 19:58:12 +0300, Eli Zaretskii said: >>> My reading of the code is that inhibiting relocation just means >>> that ralloc.c always asks for more memory when it cannot find a >>> large enough block in the existing heaps. >> >> For example, `virtual_break_value' is not updated in that case. It >> can lead to an inconsistent state as reported if r_alloc_sbrk is >> called with a positive argument via malloc when >> use_relocatable_buffers <= 0, and then it is called with a negative >> argument via free when use_relocatable_buffers > 0. > I see your point. Sorry, I noticed that the senario I gave above was actually bogus. Typically free will call r_alloc_sbrk(0) and check the return value with respect to the area to be reclaimed before calling r_alloc_sbrk with a negative argument. Now I don't have a concrete senario to conclude that it is wrong to change use_relocatable_buffers temporarily. I'm really sorry if my previous posts confused you. YAMAMOTO Mitsuharu mituharu@math.s.chiba-u.ac.jp From debbugs-submit-bounces@debbugs.gnu.org Thu Aug 23 10:25:00 2012 Received: (at 12242) by debbugs.gnu.org; 23 Aug 2012 14:25:00 +0000 Received: from localhost ([127.0.0.1]:45114 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1T4YLD-0002bO-Qk for submit@debbugs.gnu.org; Thu, 23 Aug 2012 10:25:00 -0400 Received: from mail-pz0-f44.google.com ([209.85.210.44]:36849) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1T4YLB-0002bG-79 for 12242@debbugs.gnu.org; Thu, 23 Aug 2012 10:24:58 -0400 Received: by dadf8 with SMTP id f8so408177dad.3 for <12242@debbugs.gnu.org>; Thu, 23 Aug 2012 07:24:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type; bh=rKJhelYqSeOukGBwo/oEeFQxcbaN0tUAESdV4Rkl7Y8=; b=lpT7oAm0pbX9wvMRlIsWo6nbhZshn/hXfACkym508AQBGrYpZWNvQq7ZM5QjRdm6aa bfQPM/mW6FnJx+m4Unrd5OfWuYSkQc7mWG/h15tVBeVcj/0XEths9HJAsMh/o57VUUNU 5QbpXyM+StFMgUORUlaZt+9sGCoa/Qmp2VLQOaz9KYz43qCZg+izZ9kchH8zF7YWoDyh i0HZzjv1SxzEZJ+85whhgl8YN7fAkNqm5hgwSppeHsUwSTlAZ/wfcG6au9jBCv6Je8Y0 sBCVqC3/M3Xq2uWJRIBhxTCwINlOsT3ljbzqsHpIO0jvXU0yXkqGF2zEDsx/tbbBi35I y7vg== Received: by 10.68.213.167 with SMTP id nt7mr5018491pbc.127.1345731865708; Thu, 23 Aug 2012 07:24:25 -0700 (PDT) Received: from ulysses (cm162.gamma80.maxonline.com.sg. [202.156.80.162]) by mx.google.com with ESMTPS id kt8sm6132612pbc.1.2012.08.23.07.24.22 (version=SSLv3 cipher=OTHER); Thu, 23 Aug 2012 07:24:24 -0700 (PDT) From: Chong Yidong To: Eli Zaretskii Subject: Re: bug#12242: Emacs 24.2 RC1 build fails on OpenBSD References: <877gstuyqb.fsf@moo.wxcvbn.org> <83txvxaquu.fsf@gnu.org> <83obm4b367.fsf@gnu.org> <837gsrbpe9.fsf@gnu.org> <83y5l6amor.fsf@gnu.org> Date: Thu, 23 Aug 2012 22:24:19 +0800 In-Reply-To: <83y5l6amor.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 22 Aug 2012 19:58:12 +0300") Message-ID: <87vcg93cvg.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.6 (--) X-Debbugs-Envelope-To: 12242 Cc: 12242@debbugs.gnu.org, jca@wxcvbn.org, Stefan Monnier , YAMAMOTO Mitsuharu , Kenichi Handa X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) Eli Zaretskii writes: > Unfortunately, using r_alloc_freeze/r_alloc_thaw doesn't seem to be > workable in practice, either. I tried to use it, and the best patch I > could come up with (got me through several bootstraps with different > compiler switches) is below. It is (a) butt-ugly, and (b) very > fragile, for the reasons I explain below. > > So it sounds like the only practical way out of this mess is to step > back one notch and talk about bug #11519, which was the cause for > inhibiting relocations while maybe_unify_char is in progress. At the > time, Handa-san promised to work on removing unify_char, but I guess > that job is not yet done, since it isn't even on the trunk. Ken'ichi, > what would it take to do this now? I don't think it is feasible to rework maybe_unify_char, and test that fix, and still have a reasonably timely 24.2 release. Let us consider outright reversion of 108048. What would be the effect? Given a choice between a bug (Bug#11519) which is also in 24.1, and failure-to-compile on OpenBSD as a new regression, the former is far preferable, unless you can point out some consequence that is more serious that the discussion in Bug#11519 implies. Also, if we revert 108048, should we revert 108020 (which is in 24.1) as well? Could you explain what problem 108020 causes which 108048 is supposed to fix? Does it have symptoms? Thanks. From debbugs-submit-bounces@debbugs.gnu.org Thu Aug 23 12:06:56 2012 Received: (at 12242) by debbugs.gnu.org; 23 Aug 2012 16:06:56 +0000 Received: from localhost ([127.0.0.1]:45224 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1T4Zvr-0004uh-Uq for submit@debbugs.gnu.org; Thu, 23 Aug 2012 12:06:56 -0400 Received: from mtaout23.012.net.il ([80.179.55.175]:58105) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1T4Zvp-0004uX-5F for 12242@debbugs.gnu.org; Thu, 23 Aug 2012 12:06:54 -0400 Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0M9700900U2GAB00@a-mtaout23.012.net.il> for 12242@debbugs.gnu.org; Thu, 23 Aug 2012 19:06:20 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0M970096WU2E0QA0@a-mtaout23.012.net.il>; Thu, 23 Aug 2012 19:06:15 +0300 (IDT) Date: Thu, 23 Aug 2012 19:06:23 +0300 From: Eli Zaretskii Subject: Re: bug#12242: Emacs 24.2 RC1 build fails on OpenBSD In-reply-to: X-012-Sender: halo1@inter.net.il To: YAMAMOTO Mitsuharu Message-id: <83lih5a8zk.fsf@gnu.org> References: <877gstuyqb.fsf@moo.wxcvbn.org> <83txvxaquu.fsf@gnu.org> <83obm4b367.fsf@gnu.org> <837gsrbpe9.fsf@gnu.org> <83y5l6amor.fsf@gnu.org> X-Spam-Score: -1.2 (-) X-Debbugs-Envelope-To: 12242 Cc: jca@wxcvbn.org, handa@m17n.org, 12242@debbugs.gnu.org, cyd@gnu.org, monnier@iro.umontreal.ca, mituharu@math.s.chiba-u.ac.jp X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.2 (-) > Date: Thu, 23 Aug 2012 08:12:37 +0900 > From: YAMAMOTO Mitsuharu > Cc: YAMAMOTO Mitsuharu , > Stefan Monnier , > Chong Yidong , > Kenichi Handa , > jca@wxcvbn.org, > 12242@debbugs.gnu.org > > >>>>> On Wed, 22 Aug 2012 19:58:12 +0300, Eli Zaretskii said: > > >>> My reading of the code is that inhibiting relocation just means > >>> that ralloc.c always asks for more memory when it cannot find a > >>> large enough block in the existing heaps. > >> > >> For example, `virtual_break_value' is not updated in that case. It > >> can lead to an inconsistent state as reported if r_alloc_sbrk is > >> called with a positive argument via malloc when > >> use_relocatable_buffers <= 0, and then it is called with a negative > >> argument via free when use_relocatable_buffers > 0. > > > I see your point. > > Sorry, I noticed that the senario I gave above was actually bogus. > Typically free will call r_alloc_sbrk(0) and check the return value > with respect to the area to be reclaimed before calling r_alloc_sbrk > with a negative argument. > > Now I don't have a concrete senario to conclude that it is wrong to > change use_relocatable_buffers temporarily. I'm really sorry if my > previous posts confused you. No sweat. I guess I will need to take a deeper look at the problem. From debbugs-submit-bounces@debbugs.gnu.org Thu Aug 23 12:18:03 2012 Received: (at 12242) by debbugs.gnu.org; 23 Aug 2012 16:18:03 +0000 Received: from localhost ([127.0.0.1]:45245 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1T4a6d-0005Ad-47 for submit@debbugs.gnu.org; Thu, 23 Aug 2012 12:18:03 -0400 Received: from mtaout20.012.net.il ([80.179.55.166]:37184) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1T4a6a-0005AD-Ld for 12242@debbugs.gnu.org; Thu, 23 Aug 2012 12:18:01 -0400 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0M9700B00UJ3ZR00@a-mtaout20.012.net.il> for 12242@debbugs.gnu.org; Thu, 23 Aug 2012 19:16:44 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0M9700BUBUJVT840@a-mtaout20.012.net.il>; Thu, 23 Aug 2012 19:16:44 +0300 (IDT) Date: Thu, 23 Aug 2012 19:16:52 +0300 From: Eli Zaretskii Subject: Re: bug#12242: Emacs 24.2 RC1 build fails on OpenBSD In-reply-to: <87vcg93cvg.fsf@gnu.org> To: Chong Yidong Message-id: <83k3wpa8i3.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: QUOTED-PRINTABLE X-012-Sender: halo1@inter.net.il References: <877gstuyqb.fsf@moo.wxcvbn.org> <83txvxaquu.fsf@gnu.org> <83obm4b367.fsf@gnu.org> <837gsrbpe9.fsf@gnu.org> <83y5l6amor.fsf@gnu.org> <87vcg93cvg.fsf@gnu.org> X-Spam-Score: -1.2 (-) X-Debbugs-Envelope-To: 12242 Cc: 12242@debbugs.gnu.org, jca@wxcvbn.org, monnier@iro.umontreal.ca, mituharu@math.s.chiba-u.ac.jp, handa@m17n.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.2 (-) > From: Chong Yidong > Cc: YAMAMOTO Mitsuharu , Stefan Mon= nier , Kenichi Handa , jc= a@wxcvbn.org, 12242@debbugs.gnu.org > Date: Thu, 23 Aug 2012 22:24:19 +0800 >=20 > Let us consider outright reversion of 108048. What would be the ef= fect? > Given a choice between a bug (Bug#11519) which is also in 24.1, and > failure-to-compile on OpenBSD as a new regression, the former is fa= r > preferable, unless you can point out some consequence that is more > serious that the discussion in Bug#11519 implies. Reverting 108048 (and 108020, see below) will cause trouble to any system that uses ralloc.c, including (evidently) OpenBSD. The fact that the problem was originally found only during bootstrap on Window= s is just a coincidence. It can strike at any time that regexp search is used in a text that includes characters which need unification. It's a bomb waiting to explode. So I don't recommend that. Of course, Emacs 24.1 was shipped with that bug, so ... Can I have a 1-day grace to try debugging the OpenBSD crash? J=C3= =A9r=C3=A9mie generously gave me a login on the machine where it happened, and I'd like a chance to try debugging it. > Also, if we revert 108048, should we revert 108020 (which is in 24.= 1) as > well? Could you explain what problem 108020 causes which 108048 is > supposed to fix? Does it have symptoms? 108020 had a logic flaw in the incrementing and decrementing the flag that inhibits relocation. Due to that flaw, the inhibition was not really working beyond the first time. 108048 fixed that part. And yes, these two revisions go together. From debbugs-submit-bounces@debbugs.gnu.org Thu Aug 23 23:26:11 2012 Received: (at 12242) by debbugs.gnu.org; 24 Aug 2012 03:26:11 +0000 Received: from localhost ([127.0.0.1]:45888 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1T4kXD-0003Hw-8V for submit@debbugs.gnu.org; Thu, 23 Aug 2012 23:26:11 -0400 Received: from mail-pb0-f44.google.com ([209.85.160.44]:40295) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1T4kXA-0003Ho-M3 for 12242@debbugs.gnu.org; Thu, 23 Aug 2012 23:26:09 -0400 Received: by pbbrr4 with SMTP id rr4so2519768pbb.3 for <12242@debbugs.gnu.org>; Thu, 23 Aug 2012 20:25:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type:content-transfer-encoding; bh=LrTFtYBAFNHOTmk1x28o0HwmODDTr+CtTIP9XQGSLRU=; b=q9QoCFKqu9HG7r2rnaJZRO7ybPoMDczXm1TMu4WP7tMYgt/p0Z8BNP5dtVCnjfFoZw wRi3LLFF4fY3xp/m0qVlRHCK+pu3RHWcG/Ls+0Y5311FZIGqS4Bq4sZFXWcw8tSgL7/W geIi2/4HijBIVW0gxAepU4tdAxZAsUNGdUkcgjNRzYFVnFVmH5p3yFZHwswkULtz8ixF xoG/EctNdwEeJhwN2YxU4X1HuGI6E96PHVBz4twMfVhNKl+6SdNf1WULqxGy7hail4Eb bLmRQLiMy3LRzHh/SeUOxfqRrZ7dTimx7DY5ef7DmdrOs3Re1jpVha0Al9ZsIwxJ11Sn MGew== Received: by 10.66.88.1 with SMTP id bc1mr7735836pab.18.1345778734251; Thu, 23 Aug 2012 20:25:34 -0700 (PDT) Received: from ulysses ([155.69.16.255]) by mx.google.com with ESMTPS id mr2sm7342039pbb.16.2012.08.23.20.25.30 (version=SSLv3 cipher=OTHER); Thu, 23 Aug 2012 20:25:33 -0700 (PDT) From: Chong Yidong To: Eli Zaretskii Subject: Re: bug#12242: Emacs 24.2 RC1 build fails on OpenBSD References: <877gstuyqb.fsf@moo.wxcvbn.org> <83txvxaquu.fsf@gnu.org> <83obm4b367.fsf@gnu.org> <837gsrbpe9.fsf@gnu.org> <83y5l6amor.fsf@gnu.org> <87vcg93cvg.fsf@gnu.org> <83k3wpa8i3.fsf@gnu.org> Date: Fri, 24 Aug 2012 11:25:26 +0800 In-Reply-To: <83k3wpa8i3.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 23 Aug 2012 19:16:52 +0300") Message-ID: <87obm10y55.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.6 (--) X-Debbugs-Envelope-To: 12242 Cc: 12242@debbugs.gnu.org, jca@wxcvbn.org, monnier@iro.umontreal.ca, mituharu@math.s.chiba-u.ac.jp, handa@m17n.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) Eli Zaretskii writes: > The fact that the problem was originally found only during bootstrap > on Windows is just a coincidence. It can strike at any time that > regexp search is used in a text that includes characters which need > unification. > > Of course, Emacs 24.1 was shipped with that bug, so ... The fact that the problem showed up so late in the 24.1 pretest, and has been with us since Emacs 23, indicates that the symptoms are rather rare in practice. So reverting seems like the least bad solution. > Can I have a 1-day grace to try debugging the OpenBSD crash? J=C3=A9r=C3= =A9mie > generously gave me a login on the machine where it happened, and I'd > like a chance to try debugging it. OK. Good luck, and thanks for all your efforts with this bug. From debbugs-submit-bounces@debbugs.gnu.org Fri Aug 24 04:47:14 2012 Received: (at 12242) by debbugs.gnu.org; 24 Aug 2012 08:47:14 +0000 Received: from localhost ([127.0.0.1]:46284 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1T4pXt-000297-OA for submit@debbugs.gnu.org; Fri, 24 Aug 2012 04:47:14 -0400 Received: from mtaout21.012.net.il ([80.179.55.169]:64642) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1T4pXq-00028y-FA for 12242@debbugs.gnu.org; Fri, 24 Aug 2012 04:47:12 -0400 Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0M9900A004BJCU00@a-mtaout21.012.net.il> for 12242@debbugs.gnu.org; Fri, 24 Aug 2012 11:45:55 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0M9900AVC4CIBY10@a-mtaout21.012.net.il>; Fri, 24 Aug 2012 11:45:55 +0300 (IDT) Date: Fri, 24 Aug 2012 11:46:05 +0300 From: Eli Zaretskii Subject: Re: bug#12242: Emacs 24.2 RC1 build fails on OpenBSD In-reply-to: <87obm10y55.fsf@gnu.org> To: Chong Yidong Message-id: <83obm08ype.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: QUOTED-PRINTABLE X-012-Sender: halo1@inter.net.il References: <877gstuyqb.fsf@moo.wxcvbn.org> <83txvxaquu.fsf@gnu.org> <83obm4b367.fsf@gnu.org> <837gsrbpe9.fsf@gnu.org> <83y5l6amor.fsf@gnu.org> <87vcg93cvg.fsf@gnu.org> <83k3wpa8i3.fsf@gnu.org> <87obm10y55.fsf@gnu.org> X-Spam-Score: -1.2 (-) X-Debbugs-Envelope-To: 12242 Cc: 12242@debbugs.gnu.org, jca@wxcvbn.org, monnier@iro.umontreal.ca, mituharu@math.s.chiba-u.ac.jp, handa@m17n.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.2 (-) > From: Chong Yidong > Cc: mituharu@math.s.chiba-u.ac.jp, monnier@iro.umontreal.ca, hand= a@m17n.org, jca@wxcvbn.org, 12242@debbugs.gnu.org > Date: Fri, 24 Aug 2012 11:25:26 +0800 >=20 > > Can I have a 1-day grace to try debugging the OpenBSD crash? J= =C3=A9r=C3=A9mie > > generously gave me a login on the machine where it happened, and = I'd > > like a chance to try debugging it. >=20 > OK. Good luck, and thanks for all your efforts with this bug. I committed a fix for this as emacs-24 branch revision 108120. It is somewhat of a phenomenological nature, because I could not actually catch the entire sequence of calls and actions leading to the crash, which might have allowed me to fix the root cause where it happens, i= f possible. (It turns out OpenBSD doesn't have hardware watchpoints support in GDB, which makes catching references to variables painfull= y slow, certainly when a deadline is looming.) I did see that the crash happens because a 'heap' structure recorded in a memory control block maintained by ralloc.c refers to addresses that aren't managed as part of the linked list of 'heap' structures. It is therefore wrong to dereference such bogus 'heap' structures to update them. The crash happens because 'heap' pointed to memory that was beyond our break point; however, I found that we dereference such bogus 'heap's in more places, and survive that only because, by sheer luck, they are still within our address space. (ralloc.c does not relinquish memory to the system until it has enough excess memory to justify that.) The solution I checked in is not to dereference 'heap' pointers that are not in the linked list of heaps we maintain. The fixed version survived the command that crashed and in addition 3 different bootstraps, one on OpenBSD where the crash happened and 2 more (optimized and unoptimized) on MS-Windows. I also checked that the MS-DOS build, which also uses ralloc.c, still works OK with the offending commands after the patch. Those are the only systems I hav= e access to which use ralloc.c. I do suggest another pretest, to make sure this fix is solid. I will also work on the trunk on removing calls to xmalloc inside the functions called by maybe_unify_char, which should probably eliminate the original problem (although they also call to make-char-table, which still allocates memory, albeit in smaller chunks). Thanks. From debbugs-submit-bounces@debbugs.gnu.org Sun Sep 16 01:01:28 2012 Received: (at control) by debbugs.gnu.org; 16 Sep 2012 05:01:28 +0000 Received: from localhost ([127.0.0.1]:36239 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TD6z1-0008Vl-BT for submit@debbugs.gnu.org; Sun, 16 Sep 2012 01:01:27 -0400 Received: from mail-ie0-f172.google.com ([209.85.223.172]:34125) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TD6yw-0008VZ-TK for control@debbugs.gnu.org; Sun, 16 Sep 2012 01:01:24 -0400 Received: by ieak13 with SMTP id k13so8484612iea.3 for ; Sat, 15 Sep 2012 22:00:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:from:to:subject:date:message-id:mime-version:content-type; bh=l8DJDb43kqWZguDx7rqp+0t4QlYnhlH79t5Kan+mbJ8=; b=E6dml1yvNn9Zm91D+k7ZbCjNXJIq6lJLDqEMXshFo52iTXwuhhnPb29H9t3VOmAZxW pm8tKQT7750RsqALM01GCLf+mcXbMzIOayYbDa4sfcbvhXbS3oVq7hK/5skJ6pwu97XS YWedLDLxQG1VXyEP9keg6SpRJ2PVCzz/+aycs1Um1BWiDmnUyzMtglFjmNSDjhoVNUPu 0EESQhsecrrqBOpOiD6DHmLms+4bVoXzsHI6Zknh6w9St9Zwkxz5tmaQdQ0JOdW7IZ0u tEBg8qH7ESeGHxb+uvppz2DvOdRahpzqj+b/MpZzacRd4+kFis1lW9UVzGXVD50qnT7B 7NkA== Received: by 10.50.159.130 with SMTP id xc2mr3455876igb.33.1347771615527; Sat, 15 Sep 2012 22:00:15 -0700 (PDT) Received: from ulysses (cm162.gamma80.maxonline.com.sg. [202.156.80.162]) by mx.google.com with ESMTPS id p5sm3225017igm.13.2012.09.15.22.00.12 (version=SSLv3 cipher=OTHER); Sat, 15 Sep 2012 22:00:14 -0700 (PDT) From: Chong Yidong To: control@debbugs.gnu.org Subject: close 12242 Date: Sun, 16 Sep 2012 13:00:09 +0800 Message-ID: <87txuyftpi.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.6 (--) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) close 12242 thanks From unknown Sat Sep 06 14:24:03 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Sun, 14 Oct 2012 11:24:03 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator