GNU bug report logs -
#13528
24.3.50; "find_emacs_zone_regions: too many regions" --with-wide-int on PPC 7447A Mac OS X 10.5.8
Previous Next
Reported by: Peter Dyballa <Peter_Dyballa <at> Freenet.DE>
Date: Tue, 22 Jan 2013 19:06:02 UTC
Severity: normal
Found in version 24.3.50
Done: Paul Eggert <eggert <at> cs.ucla.edu>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 13528 in the body.
You can then email your comments to 13528 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13528; Package
emacs.
(Tue, 22 Jan 2013 19:06:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Peter Dyballa <Peter_Dyballa <at> Freenet.DE>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Tue, 22 Jan 2013 19:06:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Hello!
In GNU Emacs 24.3.50.1 (powerpc-apple-darwin9.8.0, X toolkit, Xaw3d
scroll bars)
of 2013-01-21 on Latsche.local
Bzr revision: 111577 dmantipov <at> yandex.ru-20130121170109-qsz6nomnl47c53nx
Windowing system distributor `The X.Org Foundation', version
11.0.11399901
Configured using:
`configure --without-pop --without-sound --without-xim --without-gpm
--without-dbus --without-gconf --without-gsettings --without-selinux
--without-imagemagick --with-x-toolkit=athena
--disable-ns-self-contained --x-libraries=/usr/X11/lib
--x-includes=/usr/X11/include
--enable-locallisppath=/Library/Application
Support/Emacs/calendar24:/Library/Application Support/Emacs CFLAGS=-g
-ggdb3 -H -pipe -fPIC -fno-common -Os -mcpu=7450 -mtune=G4
CPPFLAGS=-I/sw/include LDFLAGS=-L/sw/lib -v -Wl,-v
-Wl,-dead_strip_dylibs -Wl,-bind_at_load -Wl,-t GCC=gcc-4.2
CPP=cpp-4.2
CXX=c++-4.2 LD=c++-4.2
PKG_CONFIG_PATH=/sw/lib/pkgconfig:/sw/share/pkgconfig:/usr/X11/lib/
pkgconfig:/usr/lib/pkgconfig:/usr/lib/pkgconfig'
compiles and builds fine, but when I add --with-wide-int to the
configure options compilations ends here:
0x28f6000 (sz: 0x3fff/ 0x5000)
unexec: find_emacs_zone_regions: too many regions
make[2]: *** [bootstrap-emacs] Error 1
make[2]: Leaving directory `.../emacs-24.3.50/src'
It happens for both the X11 client and the NS variant. If I substitute
-Os with -O0 both compile.
--
Greetings
Pete
<\
\__ O __O
| O\ _\\/\-% _`\<,
'()-'-(_)--(_) (_)/(_)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13528; Package
emacs.
(Tue, 22 Jan 2013 20:49:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 13528 <at> debbugs.gnu.org (full text, mbox):
Thanks, does the following fix things for you, and if so, how many
regions does Emacs report when dumping?
=== modified file 'src/unexmacosx.c'
--- src/unexmacosx.c 2013-01-01 09:11:05 +0000
+++ src/unexmacosx.c 2013-01-22 20:46:07 +0000
@@ -437,7 +437,7 @@ build_region_list (void)
}
-#define MAX_UNEXEC_REGIONS 400
+#define MAX_UNEXEC_REGIONS 800
static int num_unexec_regions;
typedef struct {
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13528; Package
emacs.
(Tue, 22 Jan 2013 22:33:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 13528 <at> debbugs.gnu.org (full text, mbox):
Am 22.01.2013 um 21:46 schrieb Paul Eggert:
> Thanks, does the following fix things for you, and if so, how many
> regions does Emacs report when dumping?
I did not try that patch yet – because I was compiling GNU Emacs from
the same code basis as yesterday, now without the bootstrap option.
And it builds with -Os, and if fails when building the bootstrap
targets with -Os!
I saved all *compilation* buffers. Comparing "make bootstrap with -Os"
with "make with -Os" leads, when I leave away the initial bootstrap
paraphernalia, to these "major differences:
make bootstrap:
make[2]: Leaving directory `.../emacs-24.3.50/lib'
cd lib-src && make all -w \
CC='gcc -std=gnu99' CFLAGS='-g -ggdb3 -H -pipe -fPIC -fno-common -
Os -mcpu=7450 -mtune=G4' CPPFLAGS='-I/sw/include' \
LDFLAGS='-L/sw/lib -v -Wl,-v -Wl,-dead_strip_dylibs -Wl,-
bind_at_load -Wl,-t -L/usr/X11/lib' MAKE='make'
make[2]: Leaving directory `.../emacs-24.3.50/lib-src'
boot=bootstrap-emacs; \
if [ ! -x "src/$boot" ]; then \
cd src; make all -w \
CC='gcc -std=gnu99' CFLAGS='-g -ggdb3 -H -pipe -fPIC -fno-
common -Os -mcpu=7450 -mtune=G4' CPPFLAGS='-I/sw/include' \
LDFLAGS='-L/sw/lib -v -Wl,-v -Wl,-dead_strip_dylibs -Wl,-
bind_at_load -Wl,-t -L/usr/X11/lib' MAKE='make'
BOOTSTRAPEMACS="$boot"; \
fi;
make:
make[1]: Leaving directory `.../emacs-24.3.50/lib'
cd lib-src && make all \
CC='gcc -std=gnu99' CFLAGS='-g -ggdb3 -H -pipe -fPIC -fno-common -
Os -mcpu=7450 -mtune=G4' CPPFLAGS='-I/sw/include' \
LDFLAGS='-L/sw/lib -v -Wl,-v -Wl,-dead_strip_dylibs -Wl,-
bind_at_load -Wl,-t -L/usr/X11/lib' MAKE='make'
make[1]: Leaving directory `.../emacs-24.3.50/lib-src'
boot=bootstrap-emacs; \
if [ ! -x "src/$boot" ]; then \
cd src; make all \
CC='gcc -std=gnu99' CFLAGS='-g -ggdb3 -H -pipe -fPIC -fno-
common -Os -mcpu=7450 -mtune=G4' CPPFLAGS='-I/sw/include' \
LDFLAGS='-L/sw/lib -v -Wl,-v -Wl,-dead_strip_dylibs -Wl,-
bind_at_load -Wl,-t -L/usr/X11/lib' MAKE='make'
BOOTSTRAPEMACS="$boot"; \
fi;
which certainly is not significant. But then there are some during the
dumping step:
make bootstrap:
34 LC_LOAD_DYLIB 52
0x14fc080 (sz: 0x2cf1/ 0x3f0a)
0x1400000 (sz: 0x6b5e4/ 0xfc080)
0x27f8000 (sz: 0x6d58/ 0x7f80)
0x2000000 (sz: 0x6d5600/0x7f8000)
0x17f8000 (sz: 0x3fff/ 0x5000)
make:
34 LC_LOAD_DYLIB 52
0x14fc080 (sz: 0x2558/ 0x3f0a)
0x1400000 (sz: 0x2e950/ 0xfc080)
0x27f8000 (sz: 0x63b8/ 0x7f80)
0x2000000 (sz: 0x639917/0x7f8000)
0x13f3000 (sz: 0x3fff/ 0x5000)
This is just a snapshot from the start, more and subtle differences
follow like for example (same "line numbers"):
0x17b0000 (sz: 0x3fff/ 0x5000)
0x17a9000 (sz: 0x63c7/ 0x7000)
0x17a2000 (sz: 0x63bb/ 0x7000)
0x179d000 (sz: 0x3fff/ 0x5000)
vs.
0x17d4000 (sz: 0x3fff/ 0x5000)
0x13d2000 (sz: 0x3fff/ 0x5000)
0x17cd000 (sz: 0x63bb/ 0x7000)
0x13cd000 (sz: 0x3fff/ 0x5000)
Before I'll try the patch I'll make bootstrap with -O0 so see whether
this works – unless you recommend something different.
BTW, how do I count these regions? On Mac OS X this count is not
directly reported and I have no idea how determine the number.
My tries today were 'make clean', configure ..., make.
--
Greetings
Pete
"A TRUE Klingon warrior does not comment his code."
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13528; Package
emacs.
(Tue, 22 Jan 2013 22:40:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 13528 <at> debbugs.gnu.org (full text, mbox):
On 01/22/13 14:29, Peter Dyballa wrote:
> BTW, how do I count these regions? On Mac OS X this count is not directly reported and I have no idea how determine the number.
Sorry, I don't use OS X, I'm just trying to help remotely.
I'd just take the number of text lines that look like
those regions, as Emacs appears to output one line per region.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13528; Package
emacs.
(Tue, 22 Jan 2013 23:16:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 13528 <at> debbugs.gnu.org (full text, mbox):
Am 22.01.2013 um 23:37 schrieb Paul Eggert:
> On 01/22/13 14:29, Peter Dyballa wrote:
>> BTW, how do I count these regions? On Mac OS X this count is not
>> directly reported and I have no idea how determine the number.
>
> Sorry, I don't use OS X, I'm just trying to help remotely.
> I'd just take the number of text lines that look like
> those regions, as Emacs appears to output one line per region.
After the text "Dumping under the name emacs" follows
--- List of All Regions --- = 153 lines
+
--- List of Regions to be Dumped --- = 144 lines
followed by
--- Header Information ---
So it's presumingly 397 regions, less than the 400.
The 'make bootstrap' with -O0 fails as well.
I'm going to patch now…
--
Greetings
Pete
<\
\__ O __O
| O\ _\\/\-% _`\<,
'()-'-(_)--(_) (_)/(_)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13528; Package
emacs.
(Tue, 22 Jan 2013 23:40:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 13528 <at> debbugs.gnu.org (full text, mbox):
Am 22.01.2013 um 21:46 schrieb Paul Eggert:
> === modified file 'src/unexmacosx.c'
> --- src/unexmacosx.c 2013-01-01 09:11:05 +0000
> +++ src/unexmacosx.c 2013-01-22 20:46:07 +0000
> @@ -437,7 +437,7 @@ build_region_list (void)
> }
>
>
> -#define MAX_UNEXEC_REGIONS 400
> +#define MAX_UNEXEC_REGIONS 800
>
> static int num_unexec_regions;
> typedef struct {
With this patch applied, optimisation at -O0, 'make bootstrap'
delivers 124 + 116 lines plus 447 lines after the lines
32 LC_LOAD_DYLIB 52
33 LC_LOAD_DYLIB 56
34 LC_LOAD_DYLIB 52
The build now fails with:
Writing LC_LOAD_DYLIB command
Writing LC_LOAD_DYLIB command
Writing LC_LOAD_DYLIB command
unexec: not enough room for load commands for new __DATA segments
make[2]: *** [bootstrap-emacs] Error 1
--
Greetings
Pete
If it dies, it's biology. If it blows up, it's chemistry. If it
doesn't work, it's physics.
– University washroom sgraffito
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13528; Package
emacs.
(Wed, 23 Jan 2013 01:59:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 13528 <at> debbugs.gnu.org (full text, mbox):
On 01/22/2013 03:35 PM, Peter Dyballa wrote:
> unexec: not enough room for load commands for new __DATA segments
Presumably this line in unexmacosx.c needs to be changed:
static unsigned long text_seg_lowest_offset = 0x10000000;
I'd try changing it to (say) 0x20000000, and then see what
Emacs says is the "Lowest offset of all sections in __TEXT segment".
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13528; Package
emacs.
(Wed, 23 Jan 2013 10:44:01 GMT)
Full text and
rfc822 format available.
Message #26 received at 13528 <at> debbugs.gnu.org (full text, mbox):
Am 23.01.2013 um 02:57 schrieb Paul Eggert:
> On 01/22/2013 03:35 PM, Peter Dyballa wrote:
>> unexec: not enough room for load commands for new __DATA segments
>
> Presumably this line in unexmacosx.c needs to be changed:
>
> static unsigned long text_seg_lowest_offset = 0x10000000;
>
> I'd try changing it to (say) 0x20000000, and then see what
> Emacs says is the "Lowest offset of all sections in __TEXT segment".
This change leads to the same failure. The requested value ranges from
0x1218 (from my tries with Xaw3d variant and GCC 4.2, yesterday) up to
0x20a0 (NS variant with GCC 4.0, last summer). The last (failed)
compilation reports 0x139c.
--
Greetings
Pete
If my theory of relativity is proven successful, Germany will claim me
as a German, and France will declare that I am a citizen of the world.
Should my theory prove untrue, France will say that I am a German, and
Germany will declare that I am a Jew.
– Albert Einstein, 1929
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13528; Package
emacs.
(Wed, 23 Jan 2013 23:43:01 GMT)
Full text and
rfc822 format available.
Message #29 received at 13528 <at> debbugs.gnu.org (full text, mbox):
I have two package managers installed on my Mac, Fink and MacPorts, to install all the necessary and up-to-date libraries and software. Until now I was using libraries from Fink. An hour ago I configured, after a 'make distclean', to use MacPorts – and GNU Emacs builds as X client with wide ints. So I am considering that Fink is a bit defective…
Rebuilding dozens of packages can take days presumingly!
--
Greetings
Pete
"Evolution" o __o _o _
°\___o /0~ -\<, ^\___ /=\\_/-%
oo~_______ /\ /\______/ \_________O/ O_______________o===>-->O--o____
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13528; Package
emacs.
(Thu, 24 Jan 2013 21:05:02 GMT)
Full text and
rfc822 format available.
Message #32 received at 13528 <at> debbugs.gnu.org (full text, mbox):
Am 22.01.2013 um 23:29 schrieb Peter Dyballa:
> I did not try that patch yet – because I was compiling GNU Emacs
> from the same code basis as yesterday, now without the bootstrap
> option. And it builds with -Os, and if fails when building the
> bootstrap targets with -Os!
I found the reason for the different behaviour: 'make bootstrap' seems
to throw away the Makefile(s) built by configure and it then runs
config.status. Without setting PATH the wrong utilities are found and
the built can become a mix of system, Fink, and MacPorts software.
This cannot work.
To 'make bootstrap' I'll have to rename Fink's /sw or MacPorts' /opt –
which also means that I won't have access to all compilers installed.
--
Greetings
Pete
Hard Disk, n.:
A device that allows users to delete vast quantities of data with
simple mnemonic commands.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13528; Package
emacs.
(Fri, 25 Jan 2013 16:49:02 GMT)
Full text and
rfc822 format available.
Message #35 received at 13528 <at> debbugs.gnu.org (full text, mbox):
Am 22.01.2013 um 23:29 schrieb Peter Dyballa:
> I did not try that patch yet – because I was compiling GNU Emacs
> from the same code basis as yesterday, now without the bootstrap
> option. And it builds with -Os, and if fails when building the
> bootstrap targets with -Os!
I have indeed undone all patches to src/unexmacosx.c. Within the
clearly set build environments for configure, make, make install GNU
Emacs builds without problems. I updated the sources and still no
problem. The real problem is that 'make bootstrap' does not honour the
previous configure step and tries something that is bound to fail. If
this behaviour continues, the sequence of make distclean, configure,
make, make install seems to be a valid work-around.
My bug report was wrong: I did not see what 'make bootstrap' was
really performing.
--
Greetings
Pete
The human brain operates at only 10% of its capacity. The rest is
overhead for the operating system.
Reply sent
to
Paul Eggert <eggert <at> cs.ucla.edu>:
You have taken responsibility.
(Fri, 08 Feb 2013 16:26:01 GMT)
Full text and
rfc822 format available.
Notification sent
to
Peter Dyballa <Peter_Dyballa <at> Freenet.DE>:
bug acknowledged by developer.
(Fri, 08 Feb 2013 16:26:01 GMT)
Full text and
rfc822 format available.
Message #40 received at 13528-done <at> debbugs.gnu.org (full text, mbox):
On 01/25/2013 08:45 AM, Peter Dyballa wrote:
> My bug report was wrong: I did not see what 'make bootstrap' was really performing.
OK, thanks for following up; marking this as done.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Sat, 09 Mar 2013 12:24:03 GMT)
Full text and
rfc822 format available.
This bug report was last modified 12 years and 156 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.