* bug#11236: 24.1.50; Maximum buffer size exceeded @ 2012-04-13 14:04 Peter Dyballa 2012-04-13 15:31 ` Eli Zaretskii 2012-04-23 5:12 ` Paul Eggert 0 siblings, 2 replies; 20+ messages in thread From: Peter Dyballa @ 2012-04-13 14:04 UTC (permalink / raw) To: 11236 Hello! When I try 'make bootstrap' on PPC Mac OS X 10.5.8 (Leopard) for a GTK2 or Athena/libXaw3d X client or the NS variant the build process each time ends here: Loading loadup.el (source)... Using load-path (.../emacs-24.1.50/lisp .../emacs-24.1.50/lisp/emacs- lisp .../emacs-24.1.50/lisp/language .../emacs-24.1.50/lisp/ international .../emacs-24.1.50/lisp/textmodes) Loading emacs-lisp/byte-run (source)... Loading emacs-lisp/backquote (source)... Loading subr (source)... Loading version.el (source)... Loading widget (source)... Loading custom (source)... Loading emacs-lisp/map-ynp (source)... Loading international/mule (source)... Loading international/mule-conf (source)... Loading env (source)... Loading format (source)... Loading bindings (source)... Loading cus-start (source)... Loading window (source)... Loading .../emacs-24.1.50/lisp/files.el (source)... Maximum buffer size exceeded make[2]: *** [bootstrap-emacs] Error 1 make[1]: *** [src] Error 2 make: *** [bootstrap] Error 2 I am now at revno: 107887 branch nick: trunk timestamp: Fri 2012-04-13 06:17:25 -0400 I tried to configure with and without --with-wide-int, GCC used is Apple's version 4.2. The configuration is performed like for example this (this time to use Apple's LLVM GCC 4.2): time nice +11 env LANG=C PATH=/Developer/usr/bin:/sw/bin:$PATH ./ configure --without-sound --without-dbus --without-pop --without-gconf --without-gpm --without-gsettings --without-selinux --without-gif -- without-jpeg --without-png --without-rsvg --without-tiff --without-xpm --with-x --x-libraries=/usr/X11/lib --x-includes=/usr/X11/include -- with-x-toolkit=athena --enable-locallisppath=/Library/Application\ Support/Emacs/calendar24:/Library/Application\ Support/Emacs CFLAGS="- g -H -pipe -fPIC -fno-common -fast -pthread -mfused-madd -mmultiple - ftree-vectorize -mpowerpc-gfxopt -maltivec -faltivec -mabi=altivec - mcpu=7450 -mtune=7450" LDFLAGS="-Wl,-dead_strip_dylibs -Wl,- bind_at_load -Wl,-t" PKG_CONFIG_PATH=/sw/lib/xft2/lib/pkgconfig:/sw/ share/pkgconfig:/sw/lib/pkgconfig:/usr/X11/lib/pkgconfig:/usr/X11/ share/pkgconfig:/usr/lib/pkgconfig -- Greetings Pete Email is a wonderful thing for people whose role in life is to be on top of things. But not for me; my role is to be on the bottom of things. What I do takes long hours of studying and uninterruptible concentration. – Donald Knuth ^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#11236: 24.1.50; Maximum buffer size exceeded 2012-04-13 14:04 bug#11236: 24.1.50; Maximum buffer size exceeded Peter Dyballa @ 2012-04-13 15:31 ` Eli Zaretskii 2012-04-14 10:57 ` Peter Dyballa ` (3 more replies) 2012-04-23 5:12 ` Paul Eggert 1 sibling, 4 replies; 20+ messages in thread From: Eli Zaretskii @ 2012-04-13 15:31 UTC (permalink / raw) To: Peter Dyballa; +Cc: 11236 > From: Peter Dyballa <Peter_Dyballa@Freenet.DE> > Date: Fri, 13 Apr 2012 16:04:29 +0200 > > When I try 'make bootstrap' on PPC Mac OS X 10.5.8 (Leopard) for a > GTK2 or Athena/libXaw3d X client or the NS variant the build process > each time ends here: > > Loading loadup.el (source)... > Using load-path (.../emacs-24.1.50/lisp .../emacs-24.1.50/lisp/emacs- > lisp .../emacs-24.1.50/lisp/language .../emacs-24.1.50/lisp/ > international .../emacs-24.1.50/lisp/textmodes) > Loading emacs-lisp/byte-run (source)... > Loading emacs-lisp/backquote (source)... > Loading subr (source)... > Loading version.el (source)... > Loading widget (source)... > Loading custom (source)... > Loading emacs-lisp/map-ynp (source)... > Loading international/mule (source)... > Loading international/mule-conf (source)... > Loading env (source)... > Loading format (source)... > Loading bindings (source)... > Loading cus-start (source)... > Loading window (source)... > Loading .../emacs-24.1.50/lisp/files.el (source)... > Maximum buffer size exceeded > make[2]: *** [bootstrap-emacs] Error 1 > make[1]: *** [src] Error 2 > make: *** [bootstrap] Error 2 Can you run under a debugger, but a breakpoint inside buffer_overflow, and when it breaks, look around in make_gap_larger and see why exactly this overflow happens? E.g., what are the values of current_size and of nbytes_added? Please compile without optimizations, to make debugging reliable. ^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#11236: 24.1.50; Maximum buffer size exceeded 2012-04-13 15:31 ` Eli Zaretskii @ 2012-04-14 10:57 ` Peter Dyballa 2012-04-14 11:31 ` Eli Zaretskii 2012-04-14 15:27 ` Peter Dyballa ` (2 subsequent siblings) 3 siblings, 1 reply; 20+ messages in thread From: Peter Dyballa @ 2012-04-14 10:57 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 11236 Am 13.04.2012 um 17:31 schrieb Eli Zaretskii: > Please compile without optimizations, to make debugging reliable. Compiling with -O0 temacs survives loading lisp/files.el... Will add --with-wide-int and just 'make' for the next round. -- Greetings Pete For some reason, this fortune reminds everyone of Marvin Zelkowitz. ^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#11236: 24.1.50; Maximum buffer size exceeded 2012-04-14 10:57 ` Peter Dyballa @ 2012-04-14 11:31 ` Eli Zaretskii 2012-04-16 14:59 ` Peter Dyballa 0 siblings, 1 reply; 20+ messages in thread From: Eli Zaretskii @ 2012-04-14 11:31 UTC (permalink / raw) To: Peter Dyballa; +Cc: 11236 > Cc: 11236@debbugs.gnu.org > From: Peter Dyballa <Peter_Dyballa@Freenet.DE> > Date: Sat, 14 Apr 2012 12:57:51 +0200 > > > Am 13.04.2012 um 17:31 schrieb Eli Zaretskii: > > > Please compile without optimizations, to make debugging reliable. > > > Compiling with -O0 temacs survives loading lisp/files.el... I feared this is what will happen. It could be a compiler bug, but to make sure it isn't an Emacs bug, I would suggest to look at the machine code emitted by the compiler in an optimized build at the point of the fatal error. ^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#11236: 24.1.50; Maximum buffer size exceeded 2012-04-14 11:31 ` Eli Zaretskii @ 2012-04-16 14:59 ` Peter Dyballa 2012-04-16 16:54 ` Eli Zaretskii 0 siblings, 1 reply; 20+ messages in thread From: Peter Dyballa @ 2012-04-16 14:59 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 11236 Am 14.04.2012 um 13:31 schrieb Eli Zaretskii: > It could be a compiler bug, but to > make sure it isn't an Emacs bug, I would suggest to look at the > machine code emitted by the compiler in an optimized build at the > point of the fatal error. I decided to perform something I understand: I modified the function buffer_overflow () to report where it was called. It happens in src/ fileio.c on line #3424, so buf_growth_max < likely_growth is true. -- Greetings Pete "A TRUE Klingon warrior does not comment his code." ^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#11236: 24.1.50; Maximum buffer size exceeded 2012-04-16 14:59 ` Peter Dyballa @ 2012-04-16 16:54 ` Eli Zaretskii 2012-04-16 20:12 ` Peter Dyballa 0 siblings, 1 reply; 20+ messages in thread From: Eli Zaretskii @ 2012-04-16 16:54 UTC (permalink / raw) To: Peter Dyballa; +Cc: 11236 > Cc: 11236@debbugs.gnu.org > From: Peter Dyballa <Peter_Dyballa@Freenet.DE> > Date: Mon, 16 Apr 2012 16:59:47 +0200 > > > Am 14.04.2012 um 13:31 schrieb Eli Zaretskii: > > > It could be a compiler bug, but to > > make sure it isn't an Emacs bug, I would suggest to look at the > > machine code emitted by the compiler in an optimized build at the > > point of the fatal error. > > I decided to perform something I understand: I modified the function > buffer_overflow () to report where it was called. It happens in src/ > fileio.c on line #3424, so buf_growth_max < likely_growth is true. Can you show all the other variables involved in the calculations leading to line 3424 of fileio.c? ^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#11236: 24.1.50; Maximum buffer size exceeded 2012-04-16 16:54 ` Eli Zaretskii @ 2012-04-16 20:12 ` Peter Dyballa 2012-04-16 20:39 ` Andreas Schwab 0 siblings, 1 reply; 20+ messages in thread From: Peter Dyballa @ 2012-04-16 20:12 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 11236 Am 16.04.2012 um 18:54 schrieb Eli Zaretskii: >> I decided to perform something I understand: I modified the function >> buffer_overflow () to report where it was called. It happens in src/ >> fileio.c on line #3424, so buf_growth_max < likely_growth is true. > > Can you show all the other variables involved in the calculations > leading to line 3424 of fileio.c? The GUD documentation mentions a few key bindings – C-x C-a C-p can (cleverly) print values! (gdb) pr buf_growth_max The history is empty. buf_growth_max < likely_growth = $1 = 1 buf_growth_max = $2 = 2147483646 likely_growth = $3 = 5425793530331136 likely_end = $4 = 5425793530331136 beg_offset = $5 = 0 BUF_BYTES_MAX = No symbol "BUF_BYTES_MAX" in current context. buf_bytes = $6 = 1 not_regular = $7 = 0 end_offset = $8 = 5425793530331136 st.st_size = $9 = 5425793530331136 The values of likely_growth, likely_end, end_offset, and st.st_size are the same, ≈ 5·10^15 – this is an unlikely value for a 50 GB partition on an 80 GB disk... I configured --with-wide-int. When GDB hits the breakpoint it prints out: Breakpoint 2, Finsert_file_contents (filename=-9223372036828660272, visit=4611686018452566072, beg=4611686018452566072, end=4611686018452566072, replace=4611686018452566072) at fileio.c:3424 It seems to me that the variables visit, beg, end, and replace, all equal, are byte positions in the file – but almost 5·10^18 cannot be correct. These values come partially from the struct st, which has: st_dev = 234881028, st_mode = 33188, st_nlink = 1, st_ino = 43973072, st_uid = 501, st_gid = 80, st_rdev = 0, st_size = 5425793530331136, st_blocks = 10617159159808, Ls delivers: gls -lin lisp/loaddefs.el 43973072 -rw-r--r-- 1 501 80 1263291 16. Apr 10:40 lisp/loaddefs.el So some values are OK. And it's obvious that the error seems to happen earlier, I think, when the file is opened – the DEFUN ("insert-file- contents", ...) is not opening the file. The variable Sinsert_file_contents, one of the DEFUN's arguments, has: size = 4611686018427404288, I can dig further... with some help. -- Greetings Pete Theory and practice are the same, in theory, but, in practice, they are different. ^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#11236: 24.1.50; Maximum buffer size exceeded 2012-04-16 20:12 ` Peter Dyballa @ 2012-04-16 20:39 ` Andreas Schwab 2012-04-16 22:09 ` Peter Dyballa 0 siblings, 1 reply; 20+ messages in thread From: Andreas Schwab @ 2012-04-16 20:39 UTC (permalink / raw) To: Peter Dyballa; +Cc: 11236 Peter Dyballa <Peter_Dyballa@Freenet.DE> writes: > (gdb) pr buf_growth_max pr doesn't take an argument, use pp instead. Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#11236: 24.1.50; Maximum buffer size exceeded 2012-04-16 20:39 ` Andreas Schwab @ 2012-04-16 22:09 ` Peter Dyballa 0 siblings, 0 replies; 20+ messages in thread From: Peter Dyballa @ 2012-04-16 22:09 UTC (permalink / raw) To: Andreas Schwab; +Cc: 11236 Am 16.04.2012 um 22:39 schrieb Andreas Schwab: > pr doesn't take an argument, use pp instead. Yes! This pp works. Thank you! -- Mit friedvollen Grüßen Pete Hard Disk, n.: A device that allows users to delete vast quantities of data with simple mnemonic commands. ^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#11236: 24.1.50; Maximum buffer size exceeded 2012-04-13 15:31 ` Eli Zaretskii 2012-04-14 10:57 ` Peter Dyballa @ 2012-04-14 15:27 ` Peter Dyballa 2012-04-15 12:02 ` Peter Dyballa 2012-04-15 22:44 ` Peter Dyballa 3 siblings, 0 replies; 20+ messages in thread From: Peter Dyballa @ 2012-04-14 15:27 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 11236 Am 13.04.2012 um 17:31 schrieb Eli Zaretskii: > Can you run under a debugger, but a breakpoint inside buffer_overflow, > and when it breaks, look around in make_gap_larger and see why exactly > this overflow happens? I did that, and the gdb stopped at the proper moment and showed the source code of the function buffer_overflow () at insdel.c:391 in a new window: Loading window (source)... Loading .../emacs-24.1.50/lisp/files.el (source)... Breakpoint 2, buffer_overflow () at insdel.c:391 > E.g., what are the values of current_size and > of nbytes_added? Please compile without optimizations, to make > debugging reliable. With optimisation on not that much is shown: (gdb) bt #0 buffer_overflow () at insdel.c:391 #1 0x0017c028 in Finsert_file_contents (filename=34582793, visit=33560610, beg=<value temporarily unavailable, due to optimizations>, end=33560610, replace=-2113924036) at fileio.c:3424 #2 0x001d5b20 in eval_sub (form=33560610) at eval.c:2297 #3 0x001d725c in Flet (args=21916334) at eval.c:364 #4 0x001d5be0 in eval_sub (form=21916350) at eval.c:2231 #5 0x001d6afc in Fprogn (args=<value temporarily unavailable, due to optimizations>) at eval.c:364 #6 0x001c2c08 in Fsave_current_buffer (args=21997158) at editfns.c:987 #7 0x001d5be0 in eval_sub (form=21997134) at eval.c:2231 #8 0x001d59f8 in eval_sub (form=21916390) at eval.c:2344 #9 0x001d725c in Flet (args=21916398) at eval.c:364 #10 0x001d5be0 in eval_sub (form=21916478) at eval.c:2231 #11 0x001d60d8 in Funwind_protect (args=21916030) at eval.c:1304 #12 0x001d5be0 in eval_sub (form=21916486) at eval.c:2231 #13 0x001d6efc in FletX (args=21886046) at eval.c:364 #14 0x001d5be0 in eval_sub (form=21886238) at eval.c:2231 #15 0x001d6d2c in Fif (args=<value temporarily unavailable, due to optimizations>) at eval.c:364 #16 0x001d5be0 in eval_sub (form=21886406) at eval.c:2231 #17 0x001d7c8c in funcall_lambda (fun=21915766, nargs=4, arg_vector=0xbfffdbfc) at eval.c:364 #18 0x001d22fc in Ffuncall (nargs=<value temporarily unavailable, due to optimizations>, args=<value temporarily unavailable, due to optimizations>) at eval.c:2996 #19 0x001d28dc in call4 (fn=<value temporarily unavailable, due to optimizations>, arg1=<value temporarily unavailable, due to optimizations>, arg2=<value temporarily unavailable, due to optimizations>, arg3=<value temporarily unavailable, due to optimizations>, arg4=<value temporarily unavailable, due to optimizations>) at eval.c:2753 #20 0x0020d388 in Fload (file=<value temporarily unavailable, due to optimizations>, noerror=33560610, nomessage=33560610, nosuffix=<value temporarily unavailable, due to optimizations>, must_suffix=<value temporarily unavailable, due to optimizations>) at lread.c:1256 #21 0x001d5b20 in eval_sub (form=33560610) at eval.c:2297 #22 0x0020c55c in readevalloop (readcharfun=33623138, stream=0xa04e04c8, sourcename=33709753, printflag=0, unibyte=<value temporarily unavailable, due to optimizations>, readfun=33560610, start=33560610, end=33560610) at lread.c:1838 #23 0x0020d850 in Fload (file=33709625, noerror=<value temporarily unavailable, due to optimizations>, nomessage=33560610, nosuffix=<value temporarily unavailable, due to optimizations>, must_suffix=<value temporarily unavailable, due to optimizations>) at lread.c:1316 #24 0x001d5b20 in eval_sub (form=33560610) at eval.c:2297 #25 0x001d5fbc in Feval (form=21684678, lexical=<value temporarily unavailable, due to optimizations>) at eval.c:2137 #26 0x001d0010 in internal_condition_case (bfun=0x1376a0 <top_level_2>, handlers=33589130, hfun=0x13fef0 <cmd_error>) at eval.c: 1448 #27 0x00137728 in top_level_1 (ignore=<value temporarily unavailable, due to optimizations>) at keyboard.c:1177 #28 0x001cfea8 in internal_catch (tag=<value temporarily unavailable, due to optimizations>, func=0x1376d0 <top_level_1>, arg=33560610) at eval.c:1205 #29 0x001375dc in recursive_edit_1 () at keyboard.c:1132 #30 0x001403a8 in Frecursive_edit () at keyboard.c:823 #31 0x001368bc in main (argc=<value temporarily unavailable, due to optimizations>, argv=0xbffff244) at emacs.c:1711 Lisp Backtrace: "insert-file-contents" (0xbfffd160) "let" (0xbfffd2ac) "save-current-buffer" (0xbfffd41c) "with-current-buffer" (0xbfffd4ec) "let" (0xbfffd65c) "unwind-protect" (0xbfffd79c) "let*" (0xbfffd8ec) "if" (0xbfffda0c) "load-with-code-conversion" (0xbfffdbfc) "load" (0xbfffe1a0) "load" (0xbfffe820) (gdb) pr current_size The history is empty. (gdb) pr nbytes_added The history is empty. (gdb) The program is running. Exit anyway? (y or n) y Debugger finished I think this was a Friday the 13th issue... because I can't reproduce the failure with and without optimisation. Maybe I need to fail rebuilding the NS variant first, which was my start yesterday (the NS variant installs a /usr/local/bin/emacs and a /usr/local/bin/emacs- yversion> that cannot be used as is, so they need to be overwritten with usable stuff) -- Greetings Pete When confronted with actual numbers, a mathematician is at a loss. – Steffen Hokland ^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#11236: 24.1.50; Maximum buffer size exceeded 2012-04-13 15:31 ` Eli Zaretskii 2012-04-14 10:57 ` Peter Dyballa 2012-04-14 15:27 ` Peter Dyballa @ 2012-04-15 12:02 ` Peter Dyballa 2012-04-15 22:44 ` Peter Dyballa 3 siblings, 0 replies; 20+ messages in thread From: Peter Dyballa @ 2012-04-15 12:02 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 11236 Am 13.04.2012 um 17:31 schrieb Eli Zaretskii: > Can you run under a debugger, but a breakpoint inside buffer_overflow, > and when it breaks, look around in make_gap_larger and see why exactly > this overflow happens? E.g., what are the values of current_size and > of nbytes_added? Please compile without optimizations, to make > debugging reliable. The NS variant produces the failure when compiling with -fast. With - Os and less the build is OK. When I configure --with-wide-int the failure becomes: Loading window... Loading files... Loading cus-face... Loading faces... Loading button... Loading startup... Loading .../emacs-24.1.50/lisp/loaddefs.el (source)... If I spend some time I can manually make Apple's GCC 4.2.1 to compile as with -fast, because all the switches are documented (-O3 plus many extras plus optimisation for the 64-bit G5 processor/IBM PowerPC 970 variants compensated by -mcpu=7450 -mtune=G4) and find out which switch causes the defect... -- Greetings Pete We need a president who's fluent in at least one language. – Buck Henry ^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#11236: 24.1.50; Maximum buffer size exceeded 2012-04-13 15:31 ` Eli Zaretskii ` (2 preceding siblings ...) 2012-04-15 12:02 ` Peter Dyballa @ 2012-04-15 22:44 ` Peter Dyballa 2012-04-15 23:48 ` Glenn Morris 2012-04-23 9:37 ` Andreas Schwab 3 siblings, 2 replies; 20+ messages in thread From: Peter Dyballa @ 2012-04-15 22:44 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 11236 Am 13.04.2012 um 17:31 schrieb Eli Zaretskii: > Can you run under a debugger, but a breakpoint inside buffer_overflow, > and when it breaks, look around in make_gap_larger and see why exactly > this overflow happens? E.g., what are the values of current_size and > of nbytes_added? The value returned is consistently and always: "The history is empty." The culprit compiler switch is: -malign-natural. I'll configure the X client version (Xaw3d) with that switch and see if it behaves the same. If that fails I'll reconfigure and recompile the NS variant, now with the -ggdb3 or -ggdb switch (default extended format), and maybe with -gdwarf-2, to name the native debug information format of Mac OS X. -- Greetings Pete I love deadlines. I love the whooshing noise they make as they go by. – Douglas Adams ^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#11236: 24.1.50; Maximum buffer size exceeded 2012-04-15 22:44 ` Peter Dyballa @ 2012-04-15 23:48 ` Glenn Morris 2012-04-16 9:03 ` Peter Dyballa 2012-04-23 9:37 ` Andreas Schwab 1 sibling, 1 reply; 20+ messages in thread From: Glenn Morris @ 2012-04-15 23:48 UTC (permalink / raw) To: Peter Dyballa; +Cc: 11236 Peter Dyballa wrote: > The culprit compiler switch is: -malign-natural. Your life would probably be a lot easier if you didn't try all these unusual compilation options. Ref bugs 10749, 9927, 9705, 8810, 6939, 5745, 5606, ... ^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#11236: 24.1.50; Maximum buffer size exceeded 2012-04-15 23:48 ` Glenn Morris @ 2012-04-16 9:03 ` Peter Dyballa 2012-04-16 10:28 ` Andreas Schwab 2012-04-16 18:24 ` Glenn Morris 0 siblings, 2 replies; 20+ messages in thread From: Peter Dyballa @ 2012-04-16 9:03 UTC (permalink / raw) To: Glenn Morris; +Cc: 11236 Am 16.4.2012 um 01:48 schrieb Glenn Morris: >> The culprit compiler switch is: -malign-natural. > > Your life would probably be a lot easier if you didn't try all these > unusual compilation options. Ten years old hardware needs some optimisation to keep pace with recent software... -malign-natural makes reading from memory faster. Besides, it's just one of almost 20 switches added to -O3 that build up the Apple convenience switch -fast, which I am using by default. I'd say, my life would be easier if GNU Emacs would not become uncompilable from time to time... -- Greetings Pete <] o __o |__ o HPV, the real ___o /I -\<, |o \ -\),-% high speed! ___/\ /\___./ \___...O/ O____.....`-O-'-()--o_________________ ^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#11236: 24.1.50; Maximum buffer size exceeded 2012-04-16 9:03 ` Peter Dyballa @ 2012-04-16 10:28 ` Andreas Schwab 2012-04-16 13:59 ` Peter Dyballa 2012-04-16 18:24 ` Glenn Morris 1 sibling, 1 reply; 20+ messages in thread From: Andreas Schwab @ 2012-04-16 10:28 UTC (permalink / raw) To: Peter Dyballa; +Cc: 11236 Peter Dyballa <Peter_Dyballa@Freenet.DE> writes: > Ten years old hardware needs some optimisation to keep pace with recent > software... -malign-natural makes reading from memory faster. Besides, > it's just one of almost 20 switches added to -O3 that build up the Apple > convenience switch -fast, which I am using by default. If you want to use a different ABI you must use it for *everything*. Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#11236: 24.1.50; Maximum buffer size exceeded 2012-04-16 10:28 ` Andreas Schwab @ 2012-04-16 13:59 ` Peter Dyballa 0 siblings, 0 replies; 20+ messages in thread From: Peter Dyballa @ 2012-04-16 13:59 UTC (permalink / raw) To: Andreas Schwab; +Cc: 11236 Am 16.4.2012 um 12:28 schrieb Andreas Schwab: > If you want to use a different ABI you must use it for *everything*. This does not happen – in case I understand you correctly. The libraries from Fink are compiled with GCC 4.2 while Macports has recently switched to LLVM GCC 4.2. -- Mit friedvollen Grüßen Pete The human brain operates at only 10% of its capacity. The rest is overhead for the operating system. ^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#11236: 24.1.50; Maximum buffer size exceeded 2012-04-16 9:03 ` Peter Dyballa 2012-04-16 10:28 ` Andreas Schwab @ 2012-04-16 18:24 ` Glenn Morris 2012-04-16 20:16 ` Peter Dyballa 1 sibling, 1 reply; 20+ messages in thread From: Glenn Morris @ 2012-04-16 18:24 UTC (permalink / raw) To: Peter Dyballa; +Cc: 11236 Peter Dyballa wrote: > Ten years old hardware needs some optimisation to keep pace with > recent software... -malign-natural makes reading from memory faster. My take on these things is that when the time you spend tracking down obscure problems exceeds the fraction of a second you save from optimising, it's time to give up. > I'd say, my life would be easier if GNU Emacs would not become > uncompilable from time to time... Which of the dozen or so compilation bug reports that I referred to previously still apply? All of them? IMO, the lack of response to many of them indicates that this is not an area that people are generally interesting in helping with. ^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#11236: 24.1.50; Maximum buffer size exceeded 2012-04-16 18:24 ` Glenn Morris @ 2012-04-16 20:16 ` Peter Dyballa 0 siblings, 0 replies; 20+ messages in thread From: Peter Dyballa @ 2012-04-16 20:16 UTC (permalink / raw) To: Glenn Morris; +Cc: 11236 Am 16.04.2012 um 20:24 schrieb Glenn Morris: > Which of the dozen or so compilation bug reports that I referred to > previously still apply? All of them? IMO, the lack of response to many > of them indicates that this is not an area that people are generally > interesting in helping with. I'll check them and see if I can close them! -- Greetings Pete There's no place like 127.0.0.1 – origin unknown ^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#11236: 24.1.50; Maximum buffer size exceeded 2012-04-15 22:44 ` Peter Dyballa 2012-04-15 23:48 ` Glenn Morris @ 2012-04-23 9:37 ` Andreas Schwab 1 sibling, 0 replies; 20+ messages in thread From: Andreas Schwab @ 2012-04-23 9:37 UTC (permalink / raw) To: 11236-done tags 11236 + notabug quit Peter Dyballa <Peter_Dyballa@Freenet.DE> writes: > The culprit compiler switch is: -malign-natural. Thus not a bug. Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#11236: 24.1.50; Maximum buffer size exceeded 2012-04-13 14:04 bug#11236: 24.1.50; Maximum buffer size exceeded Peter Dyballa 2012-04-13 15:31 ` Eli Zaretskii @ 2012-04-23 5:12 ` Paul Eggert 1 sibling, 0 replies; 20+ messages in thread From: Paul Eggert @ 2012-04-23 5:12 UTC (permalink / raw) To: 11236 > the struct st, which has: > > ... > st_size = 5425793530331136, > st_blocks = 10617159159808, > > Ls delivers: > > gls -lin lisp/loaddefs.el > 43973072 -rw-r--r-- 1 501 80 1263291 16. Apr 10:40 lisp/loaddefs.el Since 5425793530331136 == 1263291 << 32, this suggests that there's a mismatch between the ABI that Emacs is assuming and the ABI that the 'stat' system call is actually using. Perhaps it's a bug in the way largefile mode is being set up (see Autoconf's AC_SYS_LARGFILE, which Emacs uses). Perhaps some code is compiled in largefile mode, and other code is not -- that's a no-no. Or, as Andreas Schwab suggests, if you're mixing code that's compiled by incompatible compilers, that would cause these symptoms. One other thought: is Emacs invoking 'stat' directly, or indirectly via the 'stat' defined in lib/stat.c? If the latter, perhaps there's something messed up with the indirection. ^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2012-04-23 9:37 UTC | newest] Thread overview: 20+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2012-04-13 14:04 bug#11236: 24.1.50; Maximum buffer size exceeded Peter Dyballa 2012-04-13 15:31 ` Eli Zaretskii 2012-04-14 10:57 ` Peter Dyballa 2012-04-14 11:31 ` Eli Zaretskii 2012-04-16 14:59 ` Peter Dyballa 2012-04-16 16:54 ` Eli Zaretskii 2012-04-16 20:12 ` Peter Dyballa 2012-04-16 20:39 ` Andreas Schwab 2012-04-16 22:09 ` Peter Dyballa 2012-04-14 15:27 ` Peter Dyballa 2012-04-15 12:02 ` Peter Dyballa 2012-04-15 22:44 ` Peter Dyballa 2012-04-15 23:48 ` Glenn Morris 2012-04-16 9:03 ` Peter Dyballa 2012-04-16 10:28 ` Andreas Schwab 2012-04-16 13:59 ` Peter Dyballa 2012-04-16 18:24 ` Glenn Morris 2012-04-16 20:16 ` Peter Dyballa 2012-04-23 9:37 ` Andreas Schwab 2012-04-23 5:12 ` Paul Eggert
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.