http://permalink.gmane.org/gmane.emacs.bugs hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.emacs.bugs/60299 <pre> Sorry, tool failure here. Now I'm seeing: 660 insertions(+), 243 deletions(-) Start either Emacs with -Q -nw. Open a largish C++ file. Hold down C-v. On my laptop the lagginess was quite obvious, on my desktop a little less so. Thanks, John </pre> John Wiegley 2012-05-23T10:28:24 http://permalink.gmane.org/gmane.emacs.bugs/60298 <pre> &gt; Typing ediff command '?' initially redraws the command frame at the &gt; correct size and then auto-shrinks the width down to 1. Do you really mean "width" here? IIUC ediff never tries to shrink a frame/window horizontally, so I doubt this is an Emacs problem then. Also, bug#11544 describes a similar scenario in a similar environment so it might help if someone with a GNU Emacs 24.1.50.1 (i686-pc-linux-gnu, GTK+ Version 3.4.1) of 2012-05-10 on radium/rhenium, modified by Debian (emacs-snapshot package, version 2:20120510-1~ppa1~precise1) could try to reproduce this. martin </pre> martin rudalics 2012-05-23T09:09:57 http://permalink.gmane.org/gmane.emacs.bugs/60297 <pre> &gt; start emacs -Q, load in two files let's say .bashrc from two locations, &gt; M-x ediff-buffers, now the little pop up window comes up, type ? and the &gt; window does some bizarre moves and shrinks to almost nothing, This looks like bug #11480. Could you chararacterize the "moves" (are they discrete or continuous, is a certain edge of the pop up window always at the same screen position) and the shrinking (height or width)? martin </pre> martin rudalics 2012-05-23T09:10:04 http://permalink.gmane.org/gmane.emacs.bugs/60296 <pre> PS The context for this bug report is missing; but I imagine the first thing Alan will ask for is an example that shows how to reproduce the problem. </pre> Glenn Morris 2012-05-23T08:15:38 http://permalink.gmane.org/gmane.emacs.bugs/60295 <pre> I see hundreds of lines of differences between the emacs-23 and emacs-24 branch versions of cc-fonts. </pre> Glenn Morris 2012-05-23T07:51:49 http://permalink.gmane.org/gmane.emacs.bugs/60294 <pre> Do they also differ semantically? Andreas. </pre> Andreas Schwab 2012-05-23T07:35:17 http://permalink.gmane.org/gmane.emacs.bugs/60293 <pre> Indeed, this makes the speed situation much better on Emacs 24.0.97. - When I scroll a large C++ file in Emacs 24.0.97 the first time, the performance is very choppy, even on a powerful Mac Pro machine. There are moments toward the end of the file when I can actually count out 10 seconds or so before it moves on to the next page. The file is 17,983 lines long, consisting entirely of type declarations, enum, #define's and prototypes. - If I press M-&lt;, go back to the top of the file, and then scroll to the bottom again, there are basically no pauses. - If I delete the buffer and re-open the file, scrolling is the same as before. - If I delete the buffer and load cc-fonts.elc from Emacs 23.4, scrolling performance is *much* better. It is less choppy, and although it still shows one long pause toward the end (garbage collection?), that's it. - As before, going to the top with M-&lt; and re-scrolling shows perfect speed, no lag whatsoever; and killing the buffer and re-sc</pre> John Wiegley 2012-05-23T07:24:49 http://permalink.gmane.org/gmane.emacs.bugs/60292 <pre> Which other places use C pointers to buffer text and call functions that can allocate memory? If you know about such places, please point them out. I don't think we have them, but that's me. That "if" is profoundly false, as I can now easily craft a use case where it _will_ show up. Anyway, are you against committing this to the release branch? I'd be very sad if you were, having invested so much time in hunting this bug, but I guess I'll survive. I don't think this is only about _returning_ memory. It is first and foremost about not _asking_ for more memory when we can come up with it by reshuffling buffer text. I have no idea. ralloc.c was in place (and used by all platforms) long before I became involved with Emacs. Perhaps Richard can tell. </pre> Eli Zaretskii 2012-05-23T02:59:41 http://permalink.gmane.org/gmane.emacs.bugs/60291 <pre> Fixed in the patch below. This defvar needs to be re-evaluated when the user customized faces. Since faces are used by font-lock, a good place to re-evaluate the value of this defvar before font-lock starts is in the function `diff-mode'. The following patch implements the API for all possible cases: === modified file 'lisp/vc/diff-mode.el' --- lisp/vc/diff-mode.el2012-05-01 02:48:41 +0000 +++ lisp/vc/diff-mode.el2012-05-23 00:31:05 +0000 &lt; at &gt;&lt; at &gt; -277,14 +275,28 &lt; at &gt;&lt; at &gt; (define-obsolete-face-alias 'diff-hunk-h (defvar diff-hunk-header-face 'diff-hunk-header) (defface diff-removed - '((t :inherit diff-changed)) + '((default + :inherit diff-changed) + (((class color) (min-colors 88)) + :background "#ffdddd") + (((class color)) + :foreground "red" + :weight normal + :slant normal)) "`diff-mode' face used to highlight removed lines." :group 'diff-mode) (define-obsolete-face-alias 'diff-removed-face 'diff-removed "22.1") (defvar diff-removed-face 'diff-removed) (defface di</pre> Juri Linkov 2012-05-23T00:36:18 http://permalink.gmane.org/gmane.emacs.bugs/60290 <pre> I assume that the problem can show up in many other places than re_search, so yes, it's a real problem that we need to fix for real, but your workaround will only fix the problem we happened to bump into, so adding this fix to the emacs-24 branch may be completely useless if this bug never shows up at that place there. So, IIUC the only reason to use it is so that we can more often return memory to the OS even for the non-mmap case? Is that because returning memory can only be done via sbrk style memory management? I wonder how effective it is in practice. Stefan </pre> Stefan Monnier 2012-05-23T00:47:54 http://permalink.gmane.org/gmane.emacs.bugs/60289 <pre>--text follows this line-- start emacs -Q, load in two files let's say .bashrc from two locations, M-x ediff-buffers, now the little pop up window comes up, type ? and the window does some bizarre moves and shrinks to almost nothing, This bug report will be sent to the Bug-GNU-Emacs mailing list, and the GNU bug tracker at debbugs.gnu.org. Please check that, the From: line contains a valid email address. After a delay of up, to one day, you should receive an acknowledgement at that address., Please write in English if possible, as the Emacs maintainers, usually do not have translators for other languages., Please describe exactly what actions triggered the bug, and, the precise symptoms of the bug. If you can, give a recipe, starting from `emacs -Q':, If Emacs crashed, and you have the Emacs process in the gdb debugger, please include the output from the following gdb commands:, `bt full' and `xbacktrace'., For information about debugging Emacs, please read the file, /usr/share/emacs/24.1.50/etc/DEBUG.</pre> Munawar Cheema 2012-05-22T20:54:40 http://permalink.gmane.org/gmane.emacs.bugs/60288 <pre> It happens in xmalloc/xrealloc when ralloc.c is used. The problem is indeed not new, but so what? It is real, and it just happened to us in real life, albeit on the trunk. Who knows how many other problems which we dismiss as not reproducible could have been caused by this (especially when exotic character sets were involved)? AFAIK, we do that only on platforms that don't support mmap for allocating buffer text. The relocatable allocator makes a more efficient use of memory, especially when it is almost full: it can potentially produce a large block from several small ones by moving buffer text around to "compact" their storage. </pre> Eli Zaretskii 2012-05-22T19:47:26 http://permalink.gmane.org/gmane.emacs.bugs/60287 <pre> Huh! Indeed, I always assumed that relocation would be something that can only happen during GC, not in a mere xmalloc. This brings up back to the issue of calling maybe_unify_char in STRING_CHAR_AND_LENGTH. One more strike against it. Handa, could you prepare a patch that removes this? Might be an acceptable workaround for the emacs-24 branch, yes (tho I'd replace "inhibit ? 0 : 1" with "!inhibit"). But is it really new in Emacs-24? It seems the same problem is already present in Emacs-23, so it's probably not so urgent to fix it for 24.1. I wonder: why do we use REL_ALLOC? Stefan </pre> Stefan Monnier 2012-05-22T19:19:12 http://permalink.gmane.org/gmane.emacs.bugs/60286 <pre> You are right: it was not char_table_translate, it was load_charset_map_from_file, invoked through STRING_CHAR_AND_LENGTH. </pre> Eli Zaretskii 2012-05-22T19:02:09 http://permalink.gmane.org/gmane.emacs.bugs/60285 <pre> I did the equivalent of the above, but without changing the source (to minimize the chances that the bug will disappear). Is the evidence below conclusive enough? Breakpoint 3, search_buffer (string=272417249, pos=1, pos_byte=1, lim=48448, lim_byte=51025, n=1, RE=1, trt=61843973, inverse_trt=61841925, posix=0) at search.c:1206 1206 val = re_search_2 (bufp, (char *) p1, s1, (char *) p2, s2, $1771 = 272417249 $1772 = (struct Lisp_String *) 0x103cc1e0 "(provide[ \n]+\\('\\|(quote[ \n]\\)[ \n]*ethio-util[ \n)]" (gdb) p current_buffer-&gt;text-&gt;beg $1773 = ( unsigned char *) 0x10757948 ";;; ethio-util.el --- utilities for Ethiopic -*- coding: utf-8-emacs; -*-\n\n;; Copyright (C) 1997-1998, 2002-2012 Free Software Foundation, Inc.\n;; Copyright (C) 1997, 1998, 1999, 2000, 2001, 2002, 20"... (gdb) p *p1&lt; at &gt;20 $1774 = ";;; ethio-util.el --" (gdb) p p1 $1775 = ( unsigned char *) 0x10757948 ";;; ethio-util.el --- utilities for Ethiopic -*- coding: utf-8-emac</pre> Eli Zaretskii 2012-05-22T19:00:46 http://permalink.gmane.org/gmane.emacs.bugs/60284 <pre>The doc string, like the description in the Elisp manual, should speak not in terms of saving the buffer but in terms of saving the indentity of the current buffer. Since even that is a bit ambiguous, it is even better to speak in terms of remembering which buffer is current. This is important because the Emacs doc speaks elsewhere of "saving" a buffer as saving the buffer's contents to a file. We should avoid using "saving" for anything else when it comes to buffers. So I would suggest something like this for the doc string: "Execute BODY then return to the buffer that was current at the outset." In GNU Emacs 24.0.97.1 (i386-mingw-nt5.1.2600) of 2012-05-16 on MARVIN Windowing system distributor `Microsoft Corp.', version 5.1.2600 Configured using: `configure --with-gcc (4.6) --no-opt --enable-checking --cflags -ID:/devel/emacs/libs/libXpm-3.5.8/include -ID:/devel/emacs/libs/libXpm-3.5.8/src -ID:/devel/emacs/libs/libpng-dev_1.4.3-1/include -ID:/devel/emacs/libs/zlib-dev_1.2.5-2/include -ID:/d</pre> Drew Adams 2012-05-22T18:29:26 http://permalink.gmane.org/gmane.emacs.bugs/60283 <pre>I run the Cocoa application without configuration from the debugger. See below for output. The I visit a file (C-x C-f) that contains a single utf-8 character, ARROW RIGHT and a newline. That file, utf8test, is four bytes: $ hexdump utf8test 0000000 e2 86 92 0a 0000004 It crashes (SIGABRT signal). A few more observations: - the same file opens without problems when running -nw in a terminal shell - this same crash happens when setting the coding system to utf-8-unix for the next command before find-file (C-x RET c) - this crash also seemed to occur with versions 23.something and 24.0.94, but I didn't reproduce them under as controlled conditions (not same file, but similar utf-8 containing short file) Output from debugger 'bt full' looks like this: gdb /Applications/Emacs.app/Contents/MacOS/Emacs GNU gdb 6.3.50-20050815 (Apple version gdb-1752) (Sat Jan 28 03:02:46 UTC 2012) Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by t</pre> Florian Ebeling 2012-05-22T10:29:16 http://permalink.gmane.org/gmane.emacs.bugs/60282 <pre> The function char_table_translate may allocate some amount of memory. But that's only when the char-table is one of a "unicode character property table" loaded via the function uniprop_table. When char_table_translate is called from re_search_2 (via the macro RE_TRANSLATE), the char-table to lookup is one of a case-related table (equiv? canon?) which is not a unicode property table. The function that acutally allocates memory via. char_table_translate is uniprop_table_uncompress. --- Kenichi Handa handa&lt; at &gt;m17n.org </pre> Kenichi Handa 2012-05-22T14:38:34 http://permalink.gmane.org/gmane.emacs.bugs/60281 <pre> Yes. Put it in a form acceptable for ELPA. This is documented in the Elisp manual, but as you'll see the requirements are very simple. Stefan </pre> Stefan Monnier 2012-05-22T12:51:20 http://permalink.gmane.org/gmane.emacs.bugs/60280 <pre>tags 11539 wontfix thanks If you read the threads that lead to the current situation, the whole point of the change was to force the coder to choose a value. Stefan </pre> Stefan Monnier 2012-05-22T12:50:13 http://permalink.gmane.org/gmane.emacs.bugs/60279 <pre> That looks OK, thanks, Stefan </pre> Stefan Monnier 2012-05-22T12:48:00 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.emacs.bugs