3:06 p.m.
Damon Lipparelli <lipp(a)primus.com> writes:
As with the previous release, I can't build with MULE enabled.
I'm not
sure what I'm supposed to have where anymore. I've got mule-base 1.28
installed. I've attached my "Installation" file and the stack trace I
get when I try to run xemacs.
Ok, I guess we have to hurry, if we want to fix this before the
release. Glenn Barry from Sun reported a similar problem when building
b64 with mule.
When do you get this crash? During the build (in temacs) or after a
successful build of xemacs?
What compiler should XEmacs be built with? gcc -g -O3
-Wall -Wno-switch
please use src/gdbbinit as you ~/.gdbinit file and use the 'pobj'
command to print the 'obj' variable in stack frames 3-8.
#0 0xef0748e8 in kill ()
#1 0x95748 in fatal_error_signal (sig=11) at emacs.c:262
#2 <signal handler called>
#3 0x4c424 in mark_object (obj=541561856) at alloc.c:3170
#4 0x6f21c in mark_char_table (obj=2, markobj=0x4c310 <mark_object>)
^^^^^^
Ouch, I doubt we have a valid object at address 2! :-(
at chartab.c:145
#5 0x4c4a0 in mark_object (obj=541825024) at alloc.c:3180
#6 0x4c684 in mark_object (obj=4970372) at alloc.c:3234
#7 0x4c600 in mark_object (obj=3956736) at alloc.c:3216
#8 0x4e598 in garbage_collect_1 () at alloc.c:4493
thanks.
Gunnar
P.S.: if anybody is interested here is part of Glenn's backtrace:
where
=>[1] _kill(0x0, 0xb, 0xa064901c, 0x0, 0xfeb31f98, 0xddb64), at 0xfeb16870
[2] fatal_error_signal(0x6464c0, 0x6464b4, 0x619800, 0x61dd20, 0x61d800, 0xa0649004), at
0xddb64
---- called from signal handler with signal 11 (SIGSEGV) ------
[3] mark_object(), at 0x7244c
[4] mark_char_table(0x87e000, 0x7230c, 0x87e004, 0x2, 0xffffc00, 0x5f800), at 0x99fe8
[5] mark_object(0x61d800, 0x87e000, 0x5fb30, 0x4818f8, 0x5fb50, 0x4849a8), at 0x724bc
[6] mark_object(0x60000000, 0x87822c, 0x5fb30, 0x4818f8, 0x5fb50, 0x4849a8), at 0x726d4
[7] mark_object(0x64b31c, 0x64a000, 0x5fb30, 0x4818f8, 0x5fb50, 0x4849a8), at 0x7265c
[8] garbage_collect_1(0x6406b8, 0x612c00, 0x47937c, 0x1, 0x640400, 0x30), at 0x76a84
[9] Feval(0x61db84, 0x61df3c, 0x615b30, 0x61b800, 0xa06afedc, 0x5fb30), at 0xf48a8
--
Gunnar Evermann
Speech, Vision & Robotics Group
Engineering Department
Cambridge University
5:37 p.m.
New subject: Argh! What am I missing with MULE build? (21.0-b64 + Solaris 2.5 .1 + EGCS 1.1.1)
>>>> "Gunnar" == Gunnar Evermann
<ge204(a)eng.cam.ac.uk> writes:
Gunnar> Damon Lipparelli <lipp(a)primus.com> writes:
> As with the previous release, I can't build with MULE
enabled.
> I'm not sure what I'm supposed to have where anymore. I've got
> mule-base 1.28 installed. I've attached my "Installation" file
> and the stack trace I get when I try to run xemacs.
Gunnar> Ok, I guess we have to hurry, if we want to fix this
Gunnar> before the release. Glenn Barry from Sun reported a
Gunnar> similar problem when building b64 with mule.
I think this is fixed in 21.0.65. I had the same problem with .64 on
Solaris 2.5.1 and GCC 2.8.1. By the time I had time to mess with it
again, .65 came out, so I build that. I thought that maybe the problem
was GCC 2.8.1, so I built against 2.7.2.2, which worked fine. I then
compiled it against 2.8.1, and that worked fine as well. I am using
mule.
Gunnar> Gunnar
This is stack trace I had. I got as far as composing a message about
it, but never got around to sending it. Sorry.
Segmentation Fault - core dumped
make[1]: *** [update-elc.stamp] Error 139
make[1]: Leaving directory `/apps/src/Xemacs/xemacs-21.0.64/src'
make: *** [src] Error 2
#0 0xef0f471c in kill ()
#1 0x9996c in fatal_error_signal (sig=11) at emacs.c:262
#2 <signal handler called>
#3 0x50c80 in mark_object (obj=544122368) at alloc.c:3170
#4 0x737ac in mark_char_table (obj=2, markobj=0x50b78 <mark_object>)
#at chartab.c:145
#5 0x50cfc in mark_object (obj=544380928) at alloc.c:3180
#6 0x50eec in mark_object (obj=7481948) at alloc.c:3234
#7 0x50e60 in mark_object (obj=5136384) at alloc.c:3216
#8 0x52e2c in garbage_collect_1 () at alloc.c:4493
#9 0x9eacc in Feval (form=1082870476) at eval.c:2919
#10 0x173a8c in readevalloop (readcharfun=545688064,
Regards,
Andy
3:49 a.m.
New subject: Argh! What am I missing with MULE build? (21.0-b64 + Solaris 2.5 .1 + EGCS 1.1.1)
>>>> "A" == Andrew S Howell
<andy(a)tibco.com> writes:
>>>> "Gunnar" == Gunnar Evermann
<ge204(a)eng.cam.ac.uk> writes:
Gunnar> Damon Lipparelli
<lipp(a)primus.com> writes:
>> As with the previous release, I can't build with MULE
enabled.
>> I'm not sure what I'm supposed to have where anymore. I've got
>> mule-base 1.28 installed. I've attached my "Installation" file
>> and the stack trace I get when I try to run xemacs.
Gunnar> Ok, I guess we have to hurry, if we want to fix this
Gunnar> before the release. Glenn Barry from Sun reported a
Gunnar> similar problem when building b64 with mule.
A> I think this is fixed in 21.0.65. I had the same problem with .64 on
A> Solaris 2.5.1 and GCC 2.8.1. By the time I had time to mess with it
A> again, .65 came out, so I build that. I thought that maybe the problem
A> was GCC 2.8.1, so I built against 2.7.2.2, which worked fine. I then
A> compiled it against 2.8.1, and that worked fine as well. I am using
A> mule.
Memory corruption bugs tend to `disappear' if you change ANYTHING.
Martin
3:50 p.m.
New subject: Argh! What am I missing with MULE build? (21.0-b64 + Solaris 2.5 .1 + EGCS 1.1.1)
>>>> "Martin" == Martin Buchholz
<martin(a)xemacs.org> writes:
>>>> "A" == Andrew S Howell
<andy(a)tibco.com> writes:
A> I think this is fixed in 21.0.65. I had the same problem with
A> .64 on Solaris 2.5.1 and GCC 2.8.1. By the time I had time to
A> mess with it again, .65 came out, so I build that. I thought
A> that maybe the problem was GCC 2.8.1, so I built against
A> 2.7.2.2, which worked fine. I then compiled it against 2.8.1,
A> and that worked fine as well. I am using mule.
Martin> Memory corruption bugs tend to `disappear' if you change
Martin> ANYTHING.
Martin,
Much to my chagrin, you were right. I went back and
re-compiled and installed 2.0.64 from a cleanly untared dist and it
worked fine, for both for gcc 2.7.2.2 and 2.8.1.0. The previous try,
I had done a "make dist clean" and tried with and without untaring the
xemacs-sumo-1999-03-01.tar.ga and xemacs-mule-1999-03-01.tar.gz and it
had died several times.
Not sure what else I had changed, but obviously something... I guess I
won't be the hero (:
I want a "Sony Watchman" , ya know, that little video camera you wear
on your head so you can rewind the tape and find out what it is you really
did :)
Regards,
Andy
3:32 a.m.
New subject: Argh! What am I missing with MULE build? (21.0-b64 + Solaris 2.5 .1 + EGCS 1.1.1)
>>>> "G" == Gunnar Evermann
<ge204(a)eng.cam.ac.uk> writes:
G> please use src/gdbbinit as you ~/.gdbinit file and use the 'pobj'
G> command to print the 'obj' variable in stack frames 3-8.
> #0 0xef0748e8 in kill ()
> #1 0x95748 in fatal_error_signal (sig=11) at emacs.c:262
> #2 <signal handler called>
> #3 0x4c424 in mark_object (obj=541561856) at alloc.c:3170
> #4 0x6f21c in mark_char_table (obj=2, markobj=0x4c310 <mark_object>)
G> ^^^^^^
G> Ouch, I doubt we have a valid object at address 2! :-(
> at chartab.c:145
> #5 0x4c4a0 in mark_object (obj=541825024) at alloc.c:3180
> #6 0x4c684 in mark_object (obj=4970372) at alloc.c:3234
> #7 0x4c600 in mark_object (obj=3956736) at alloc.c:3216
> #8 0x4e598 in garbage_collect_1 () at alloc.c:4493
We still have a memory corruption bug that is going to be a challenge
to track down. In addition to using src/gdbinit, It might help to use
the watchpoint feature in your debugger, if available. Also,
judicious use of always_gc might be useful. This bug will be tough to
find, but you'll be a hero!
Martin
9392
days inactive
9393
days old
4 comments
3 participants
participants (3)
-
Andrew S. Howell -
Gunnar Evermann -
Martin Buchholz