Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!

Full Text Bug Listing

[ebuild   R   ] app-editors/emacs-22.1-r1  USE="X alsa gif gtk* hesiod jpeg
motif png sound spell tiff xpm -Xaw3d -gzip-el -source -toolkit-scroll-bars" 0
kB

Fails to build on HPPA:

Loading replace...
Loading abbrev...
Loading buff-menu...
Loading fringe...
Loading image...
Loading international/fontset...
Loading dnd...
Loading mwheel...
Loading tool-bar...
Loading x-dnd...
((56871 . 10049) (11616 . 0) (620 . 66) 79304 166484 (68 . 8) (18 . 12) (5582 .
2041))
Loading emacs-lisp/float-sup...
((56901 . 10019) (11620 . 0) (620 . 66) 79359 166484 (69 . 9) (18 . 12) (5584 .
2039))
Loading vc-hooks...
Loading ediff-hook...
Loading tooltip...
((58206 . 8714) (11762 . 0) (621 . 65) 80654 166535 (71 . 7) (18 . 12) (5655 .
1
968))
make[1]: *** [emacs] Segmentation fault
make[1]: Leaving directory
`/mnt/alt/portage-tmp/portage/app-editors/emacs-22.1-
r1/work/emacs-22.1/src'
make: *** [src] Error 2
 *
 * ERROR: app-editors/emacs-22.1-r1 failed.
 * Call stack:
 *   ebuild.sh, line 1654:   Called dyn_compile
 *   ebuild.sh, line 990:   Called qa_call 'src_compile'
 *   ebuild.sh, line 44:   Called src_compile
 *   emacs-22.1-r1.ebuild, line 140:   Called die
 *
 * emake failed
 * If you need support, post the topmost build error, and the call stack if
rele
vant.
 * A complete build log is located at
'/keeps/gentoo/emergelogs/elmer/app-editor
s:emacs-22.1-r1:20070924-181729.log'.

dmesg shows it is ./temacs that is segfaulting:

[534960.984000] do_page_fault() pid=10294 command='temacs' type=15
address=0x000
01221
[534960.984000]
[534960.984000]      YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
[534960.984000] PSW: 00000000000001001111111100001111 Not tainted
[534960.984000] r00-03  0004ff0f 00001001 4170bda7 0030c468
[534960.984000] r04-07  00000001 00000004 000000b0 00311468
[534960.984000] r08-11  00311468 00311468 00311468 00311468
[534960.984000] r12-15  00310468 40020000 00330458 00330508
[534960.984000] r16-19  00000000 0030c468 00311468 00000001
[534960.984000] r20-23  00000006 00000000 00000001 417c0b8c
[534960.984000] r24-27  00000001 00000001 00000004 001b9c68
[534960.984000] r28-31  00000000 00000000 fb06f8c0 4170bdb7
[534960.984000] sr00-03  00000000 00000000 00000000 00000024
[534960.984000] sr04-07  00000024 00000024 00000024 00000024
[534960.984000]
[534960.984000]       VZOUICununcqcqcqcqcqcrmunTDVZOUI
[534960.984000] FPSR: 00001100001111010011100000000000
[534960.984000] FPER1: 00000000
[534960.984000] fr00-03  0c3d380000000000 0000000000000000 0000000000000000
0000
000000000000
[534960.984000] fr04-07  3fe999999999999a 3fed4723aafff36a 3c91a62633145c07
3ff0
000000000000
[534960.984000] fr08-11  3ff0000000000000 0000000000000000 0000000000000000
3ff9
21fb54442d18
[534960.984000] fr12-15  00328cab10635810 00534b631017de08 40023a5000000080
11b6
420000000000
[534960.984000] fr16-19  ffffff9c105d3810 0000000f11b64208 0000000b00000000
1060
77f3106077f2
[534960.984000] fr20-23  105f901000000000 5555555510172258 40186ed8000000e1
4018
27d4b827fa19
[534960.984000] fr24-27  ffffffff00000000 3ff5bf0a8b145769 3ec04ea635580000
beb7
f7d1cf79abca
[534960.984000] fr28-31  3e3ee67e8938c386 3ff000e008000000 3ff0000000000000
3ff0
000000000000
[534960.984000]
[534960.984000] IASQ: 00000024 00000024 IAOQ: 4170bdbf 4170bdc3
[534960.984000]  IIR: 483f0440    ISR: 00000024  IOR: 00001221
[534960.984000]  CPU:        0   CR30: 20784000 CR31: 1065c000
[534960.984000]  ORIG_R28: 00000001
[534960.984000]  IAOQ[0]: 0x4170bdbc
[534960.984000]  IAOQ[1]: 0x4170bdc0
[534960.984000]  RP(r2): 0x4170bda4

Created an attachment (id=131818) [details]
emerge --info

Created an attachment (id=131819) [details]
app-editors:emacs-22.1-r1:20070924-181729.log.gz (gzipped build log)

Does one of emacs-cvs-22.1.50-r1 or emacs-cvs-22.1.50_p20070829 build properly?

(In reply to comment #3)
> Does one of emacs-cvs-22.1.50-r1 or emacs-cvs-22.1.50_p20070829 build properly?

 jer, could you please check so we have less to investigate?

(In reply to comment #3)
> Does one of emacs-cvs-22.1.50-r1 or emacs-cvs-22.1.50_p20070829 build properly?

Both build properly with USE=-gtk, and both fail with USE=gtk.

The last message we see in the build log (attachment #131819 [details]) is the output of
a successful garbage collection, line 216 of loadup.el. Next message would be
"Finding pointers to doc strings..." output in line 253. So the problem should
be somewhere in between.

The only thing that could be related to gtk is in line 228 where
precompute-menubar-bindings is called, which in turn calls x-popup-menu.

Could you run "./temacs -batch -l loadup dump" (in ${S}/src) again under gdb,
to get a stack trace?

Actually it doesn't seem to fail outside of the sandbox:

elmer
/mnt/alt/portage-tmp/portage/app-editors/emacs-cvs-22.1.50-r1/work/emacs-22/src
# ./temacs -batch -l loadup dump
Loading loadup.el (source)...
Using load-path
(/mnt/alt/portage-tmp/portage/app-editors/emacs-cvs-22.1.50-r1/work/emacs-22/lisp)
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 env (source)...
Loading cus-start (source)...
Loading international/mule (source)...
Loading international/mule-conf.el (source)...
Loading format (source)...
Loading bindings (source)...
Loading files.el (source)...
Loading cus-face.el (source)...
Loading faces.el (source)...
(require cl) while preparing to dump
elmer /mnt/alt/portage-tmp/portage/app-editors/emacs-cvs-22.1.50-r1/work/

(In reply to comment #7)
> Actually it doesn't seem to fail outside of the sandbox:

The Emacs ebuilds have SANDBOX_ON=0, so that shouldn't be the reason.
Have you already tried with "emake -j1"?

(In reply to comment #8)
> Have you already tried with "emake -j1"?

Same result.

(In reply to comment #8)
> > Actually it doesn't seem to fail outside of the sandbox:
> 
> The Emacs ebuilds have SANDBOX_ON=0, so that shouldn't be the reason.

Actually, there might be a difference due a different environment, for example
the DISPLAY variable. Could you unset DISPLAY and try the following again:

(In reply to comment #6)
> Could you run "./temacs -batch -l loadup dump" (in ${S}/src) again under gdb,
> to get a stack trace?

Created an attachment (id=134890) [details]
gdb bt full

Reported upstream: <http://permalink.gmane.org/gmane.emacs.bugs/16893>

From: Richard Stallman <rms@gnu.org>
Reply-to: rms@gnu.org
To: Ulrich Mueller <ulm@gentoo.org>
CC: bug-gnu-emacs@gnu.org, jer@gentoo.org, emacs@gentoo.org
Subject: Re: Emacs 22.1 --with-x-toolkit=gtk build failure on HPPA
Date: Thu, 01 Nov 2007 22:06:33 -0400

This sort of problem can only be debugged by people
with that sort of machine available.  If someone sends
us a fix, we can install it, but that is all we can do.

(In reply to comment #13)
> This sort of problem can only be debugged by people with that sort
> of machine available.

Therefore reassigning to HPPA team.

Is this still an issue? I'm asking because you've marked 22.1-r3 stable...

(In reply to comment #15)
> Is this still an issue? I'm asking because you've marked 22.1-r3 stable...

+       epatch "${FILESDIR}/${P}-format-int.patch"

With that being the difference, I don't think it would be enough to fix some
random HPPA/GTK+ problem. With USE=-gtk, emacs-22 builds and works fine.

You'll be very sure to notice when this is not an issue anymore...

But hppa/2007.0/desktop sets USE=gtk, right? I was just wondering why 22.1-r3
was stabilised (we had asked for 21.4-r14 only) if it cannot be built in the
default configuration.

Of course it would be better if we could fix this bug, but I don't see how the
Emacs team could help at the moment. The stack trace shows that something goes
very wrong, but doesn't point to any specific place.

A major difference between USE=-gtk and USE=gtk is also that the program is
threaded for the latter, and different routines for memory allocation are used.

# Jeroen Roovers <jer@gentoo.org> (26 Nov 2007)
# emacs doesn't build with USE=gtk (bug #193703)
>=app-editors/emacs-22 gtk

Until this bug is resolved.

This patch to the ebuild seems to fix it. It's compiler optimisations again, it
seems (note that I previously tested with -O2). If you OK this patch I will
commit it:


jeroen@astrid /keeps/gentoo/cvs/gentoo-x86/app-editors/emacs $ cvs diff
emacs-22.1-r3.ebuild
Index: emacs-22.1-r3.ebuild
===================================================================
RCS file: /var/cvsroot/gentoo-x86/app-editors/emacs/emacs-22.1-r3.ebuild,v
retrieving revision 1.2
diff -u -B -r1.2 emacs-22.1-r3.ebuild
--- emacs-22.1-r3.ebuild        26 Nov 2007 00:25:47 -0000      1.2
+++ emacs-22.1-r3.ebuild        26 Nov 2007 21:28:01 -0000
@@ -83,7 +83,11 @@
        ALLOWED_FLAGS=""
        strip-flags
        unset LDFLAGS
-       replace-flags -O[3-9] -O2
+       if use hppa; then
+               replace-flags -O[3-9] -O
+       else
+               replace-flags -O[3-9] -O2
+       fi
        sed -i -e "s/-lungif/-lgif/g" configure* src/Makefile* || die

        local myconf

> If you OK this patch I will commit it:

Go ahead. But, one minor point:

> +       if use hppa; then
> +               replace-flags -O[3-9] -O

This should be "replace-flags -O[2-9] -O".

(In reply to comment #20)
> > If you OK this patch I will commit it:
> 
> Go ahead. But, one minor point:
[...]
> This should be "replace-flags -O[2-9] -O".

That's not so minor. :)

Fixed in CVS. p.u.mask removed.

/

> BugsThisDependsOn  	  	203543

What lets you assume that this is the same issue?
The incorrect branching in bug 203543 happens for -O1, while the Emacs problem
occured for -O[2-3].

(In reply to comment #23)
> > BugsThisDependsOn  	  	203543
> 
> What lets you assume that this is the same issue?

What suggests that I do? For all I care, this bug needed to be reopened in
order to inventorise gcc -O bugs. Connecting it to the gcc branching bug would
certainly help for now even if we would need to re-categorise this bug later.

> The incorrect branching in bug 203543 happens for -O1, while the Emacs problem
> occured for -O[2-3].

Yes, but there may be more behind it than that, and ruling that out now would
be silly.

That didn't fix it.

Is this still an issue in app-editors/emacs-cvs-22.2.91?

We are approaching the last pretests for 22.3 so this might be the last chance
to fix the bug for Emacs 22.

22.3 did work for me.

Can you confirm it's all good ?

app-editors/emacs-cvs-23.0.94 still fails.

With this patch, suggested by ulm on IRC, the build doesn't fail but hangs:

--- src/s/gnu-linux.h.orig      2009-05-23 05:43:48.000000000 +0200
+++ src/s/gnu-linux.h   2009-05-28 01:00:24.000000000 +0200
@@ -258,7 +258,7 @@
 #if defined __i386__ || defined __sparc__ || defined __mc68000__ \
     || defined __alpha__ || defined __mips__ || defined __s390__ \
     || defined __arm__ || defined __powerpc__ || defined __amd64__ \
-    || defined __ia64__ || defined __sh__
+    || defined __ia64__ || defined __sh__ || defined __hppa__
 #define GC_SETJMP_WORKS 1
 #define GC_MARK_STACK GC_MAKE_GCPROS_NOOPS
 #ifdef __mc68000__

at:

Checking
/mnt/alt/portage-tmp/portage/app-editors/emacs-cvs-23.0.94/work/emacs-23.0.94/leim/quail/viqr.el
...
Checking
/mnt/alt/portage-tmp/portage/app-editors/emacs-cvs-23.0.94/work/emacs-23.0.94/leim/quail/ECDICT.el
...
Saving file
/mnt/alt/portage-tmp/portage/app-editors/emacs-cvs-23.0.94/work/emacs-23.0.94/leim/leim-list.el...
Wrote
/mnt/alt/portage-tmp/portage/app-editors/emacs-cvs-23.0.94/work/emacs-23.0.94/leim/leim-list.el
Updating
/mnt/alt/portage-tmp/portage/app-editors/emacs-cvs-23.0.94/work/emacs-23.0.94/leim/leim-list.el
... done
sed -n '/^[^;]/ p' <
/mnt/alt/portage-tmp/portage/app-editors/emacs-cvs-23.0.94/work/emacs-23.0.94/leim/leim-ext.el
>> leim-list.el
make[1]: Leaving directory
`/mnt/alt/portage-tmp/portage/app-editors/emacs-cvs-23.0.94/work/emacs-23.0.94/leim'
Compiling
/mnt/alt/portage-tmp/portage/app-editors/emacs-cvs-23.0.94/work/emacs-23.0.94/lisp/mh-e/mh-letter.el

(In reply to comment #19)
> -       replace-flags -O[3-9] -O2
> +       if use hppa; then
> +               replace-flags -O[3-9] -O
> +       else
> +               replace-flags -O[3-9] -O2
> +       fi

I've noticed that for some reason emacs-23.1.ebuild (which was copied from
emacs-cvs-23.0.96.ebuild) doesn't do this flag replacement. Probably it should,
but I don't remember the history.

@hppa: Can you test app-editors/emacs-23.1 with USE=gtk?

Created an attachment (id=201040) [details]
app-editors:emacs-23.1:20090809-141014.log.gz [hppa,success]

(In reply to comment #30)
> (In reply to comment #19)
> > -       replace-flags -O[3-9] -O2
> > +       if use hppa; then
> > +               replace-flags -O[3-9] -O
> > +       else
> > +               replace-flags -O[3-9] -O2
> > +       fi
> 
> I've noticed that for some reason emacs-23.1.ebuild (which was copied from
> emacs-cvs-23.0.96.ebuild) doesn't do this flag replacement. Probably it should,
> but I don't remember the history.
> 
> @hppa: Can you test app-editors/emacs-23.1 with USE=gtk?

Seems to have worked out quite well.

So the problem is gone in 23.1, and for 22.3 there is a workaround in place.
Therefore closing.