Re: emacs-19.34 segfaults when built with Xfree 4.3.0 (glibc2.3.x,gcc 3.2)

Re: emacs-19.34 segfaults when built with Xfree 4.3.0 (glibc2.3.x,gcc 3.2)

[Hin-Tak Leung]

This is going more and more off-topic. My initial post was fairly
specific, and the one reply I got (asking why I don't use a more
current version) was already somewhat off-topic, because I did
describe my system in much detail and it would have been obvious even
at that point I had a (not yet disclosed) reason not to use a
more current version.

But unless of course, you would rather me switching to xemacs-21 instead...

(cemacs still continue to work under it, as the emacs/xemacs split
occurred before version 19, and the xemacs folks are less agressive
in making incompatible changes - which unfortunately is also the
reason of xemacs's bloatedness; however I believe MULE is going into
xemacs-24 or thereabout's so the issue will need to be addressed one day,
even if I switch to xemacs).

FWIW, I did search through the archive for "Fatal Error(11)".
And it seems to be the message for a general memory access error,
similar to the gcc's SIG 11 (probably identical to...), or
the rather uninformative "segmentation fault" whenever any program dies;
and fatal error 11 can occur under a lot of totally unrelated conditions,
but mostly to do with how undump works, memory aligment, etc.

So my guess is that it is probably going to be very sensitive
to how my glibc, Xfree86, or my gcc were configured and built and
any patches were applied to them; and there *might* be a chance
that a future system upgrade *might* magically fixes it.

In any case, the reality is that I only need emacs-19 to work in
the "-nw" enviroment for cemacs, and figuring out why it
segfaults under Xfree86 is a somewhat academic issue... but
I would still like an answer, an explanation, or (gasp) a
possible fix.

OTOH, if I really want a "currently supported" emacs for my purpose,
I could switch to xemacs-21 immediately and that would give me
a couple of years to look for other alternatives...

Thien-Thi Nguyen wrote:
> Hin-Tak Leung <hintak_leung@yahoo.co.uk> writes:
> 
>    Now back to my question: why emacs 19.34 segfault when built against
>    glibc-2.3 and Xfree 4.3.0? And please stick to the question... - and
>    please do not ask why I don't switch to xemacs, or use MULE.
> 
> in this case probably no one can answer your question w/o your investing
> effort into debugging the matter locally.  as well, probably few people
> are interested in helping you if you scold them.
> 
> of course, there is the option of hiring someone to work on this problem
> for you, in which case you can treat them as befits the conventional (in
> your business sphere) employer / employee relationship, and clearly set
> out in a written contract.  you may consult the etc/SERVICES file to
> find someone in your vicinity, or further away on the net.
> 
> thi
> 

Re: emacs-19.34 segfaults when built with Xfree 4.3.0 (glibc2.3.x,gcc 3.2)

[Thien-Thi Nguyen]

Hin-Tak Leung <hintak_leung@yahoo.co.uk> writes:

   but I would still like an answer, an explanation, or (gasp) a
   possible fix.

you are getting answers.  you are getting (oblique) explanations.  if
these are not to your liking, what adaptability can you demonstrate to
elicit the preferred results?

thi

Re: emacs-19.34 segfaults when built with Xfree 4.3.0(glibc2.3.x,gcc 3.2)

[Hin-Tak Leung]

(Sigh) This is getting more and more off-topic. You know, earlier posts
to similar questions (why does it segfault, "fatal error 11")
in the archive had instead concentrated
on the issue at hand e.g. in the archive around Jun 2002
there was an explicit patch (which I already use to get the
compilation going), and other people over the past 10 years' archive
had suggested running gdb on core dumps, doing a strace, etc on the
"Fatal Error 11" problem. So far neither you nor
"supposedly helpful" samuel had even suggested either gdb or strace.
or trying to get a core dump.

If you want my adaptability, I guess I would like to offer
a gdb back trace or something like that eventually, when
I get round to do it. Can you help debugging a gdb back trace?

(I would really like a straight forward "yes" or "no", rather
than going into further philosophical discussions).

Thien-Thi Nguyen wrote:
> Hin-Tak Leung <hintak_leung@yahoo.co.uk> writes:
> 
>    but I would still like an answer, an explanation, or (gasp) a
>    possible fix.
> 
> you are getting answers.  you are getting (oblique) explanations.  if
> these are not to your liking, what adaptability can you demonstrate to
> elicit the preferred results?
> 
> thi
> 

Re: emacs-19.34 segfaults when built with Xfree 4.3.0(glibc2.3.x,gcc 3.2)

[Thien-Thi Nguyen]

Hin-Tak Leung <hintak_leung@yahoo.co.uk> writes:

   So far neither you nor "supposedly helpful" samuel had even
   suggested either gdb or strace.  or trying to get a core
   dump.

it looks like you have stumbled upon this debugging approach on
your own, in any case, w/o needless prompting.  that's good to
see!

   If you want my adaptability, I guess I would like to offer
   a gdb back trace or something like that eventually, when
   I get round to do it. Can you help debugging a gdb back trace?

   (I would really like a straight forward "yes" or "no", rather
   than going into further philosophical discussions).

well i would really like to say "yes" or "no" straight-forwardly
rather than having to debug your PR problems first, but all i
can offer at this time are these questions: (1) how can anyone
definitively answer anything on something you have not yet
revealed?  (2) what is the root cause of any problem besides
philosophical misalignment of some sort?

thi

Re: emacs-19.34 segfaults when built with Xfree 4.3.0(glibc2.3.x,gcc 3.2)

[Hin-Tak Leung]

(Sigh). I would have been a lot happier if one of you had
replied with "get me a gdb back strace" than having to digress
to lengthy philosphical discussion on reasons to use an
older version, or resorting to foul languages.

As I said, I would prefer a "yes" or "no" to the gdb debug
question. It isn't to difficult to answer either:
(1) "possibly, depending on how deep the problem is; can't promise"
(2) "Sorry no, no eperience with gdb whatsoever"

But you are trying to draw into philosophical discussion again.
(I guess that's still better than the "get a f*cking life"
or "cheeky f*cker" replies)

I suppose the inclusion of MULE and breaking backward
compatibility is the root cause - and my not wanting to use it.
But this is somewhat irrelevant. Other people may have other
reasons for wanting to run an old copy of emacs on current
systems, and a solution may be useful to others. The
preference to use cemacs versus MULE may be a very
small minority, but I don't think the same can be said about
emacs 19 versus emacs 21 in general. In a way, MULE has
exactly the same strength and weakness as the general emacs
"Swiss Army Knife" philosophy: it is useful for linguists
who want to do a lot of languages within a single document,
but it doesn't work particularly well for any one given
language. And a 30MB MULE installation versus 50kB cemacs -
a trimmed emacs 19 installation in parallel/addition to
emacs 21 is only 10MB.

If I had sounded impatient, I had not resort to verbal
violence as some others did.

Thien-Thi Nguyen wrote:
> Hin-Tak Leung <hintak_leung@yahoo.co.uk> writes:
> 
>    So far neither you nor "supposedly helpful" samuel had even
>    suggested either gdb or strace.  or trying to get a core
>    dump.
> 
> it looks like you have stumbled upon this debugging approach on
> your own, in any case, w/o needless prompting.  that's good to
> see!
> 
>    If you want my adaptability, I guess I would like to offer
>    a gdb back trace or something like that eventually, when
>    I get round to do it. Can you help debugging a gdb back trace?
> 
>    (I would really like a straight forward "yes" or "no", rather
>    than going into further philosophical discussions).
> 
> well i would really like to say "yes" or "no" straight-forwardly
> rather than having to debug your PR problems first, but all i
> can offer at this time are these questions: (1) how can anyone
> definitively answer anything on something you have not yet
> revealed?  (2) what is the root cause of any problem besides
> philosophical misalignment of some sort?
> 
> thi
> 

Re: emacs-19.34 segfaults when built with Xfree 4.3.0(glibc2.3.x,gcc 3.2)

[Thien-Thi Nguyen]

Hin-Tak Leung <hintak_leung@yahoo.co.uk> writes:

   (Sigh). I would have been a lot happier if one of you had
   replied with "get me a gdb back strace" than having to digress
   to lengthy philosphical discussion on reasons to use an
   older version, or resorting to foul languages.

although it is encouraging that you know yourself well enough to say
this, i confess to not feeling comfortable ordering you about like an
employee.  these lengthy discussions surely would be better replaced by
some concrete information (as "concrete" as information can be ;-), it
seems you're saying.  the reasons for using this version (or any version
for that matter) are not really germaine to debugging the problem, you
also note.

   As I said, I would prefer a "yes" or "no" to the gdb debug
   question. It isn't to difficult to answer either:
   (1) "possibly, depending on how deep the problem is; can't promise"
   (2) "Sorry no, no eperience with gdb whatsoever"

what if some people on the list respond (1) and some people respond
(2) -- what have you gained and/or lost by this exercise?

   But you are trying to draw into philosophical discussion again.
   (I guess that's still better than the "get a f*cking life"
   or "cheeky f*cker" replies)

a personal quirk, no doubt: all discussion is philosophical to me, even
those involving hard bits of free software artifact (both pre- and post-
core dump ;-).

   If I had sounded impatient, I had not resort to verbal
   violence as some others did.

sometimes the sudden move is easy to interpret as both violent and
beautiful, and sometimes funny and sometimes sad.  where there is room
for interpretation there is room for misunderstanding (and bugs!).

thi

Re: emacs-19.34 segfaults when built with Xfree 4.3.0(glibc2.3.x,gcc 3.2)

[Hin-Tak Leung]

Here is the long awaited gdb back trace and strace. It seems to die
at the same place that emacs-21/AIX dies if it is run over a slow
dial-up connection (there were two different patches for that, one of
them by Mr Stallman himself no less, if I remember correctly)
- probably not related. Thought I'd mention this just in case.
==========================
 > gdb emacs-19.34
GNU gdb 5.3
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-slackware-linux"...
(gdb) run
Starting program: /usr/local/bin/emacs-19.34

Program received signal SIGSEGV, Segmentation fault.
0x400908b3 in XtInitializeWidgetClass () from /usr/X11R6/lib/libXt.so.6
(gdb) bt
#0  0x400908b3 in XtInitializeWidgetClass () from /usr/X11R6/lib/libXt.so.6
#1  0x400916a2 in _XtCreateWidget () from /usr/X11R6/lib/libXt.so.6
#2  0x400917c5 in XtCreateWidget () from /usr/X11R6/lib/libXt.so.6
#3  0x08075141 in x_window ()
#4  0x08076228 in Fx_create_frame ()
#5  0x080c65cb in Ffuncall ()
#6  0x080db3f3 in Fbyte_code ()
#7  0x080c6a8a in funcall_lambda ()
#8  0x080c64dc in Ffuncall ()
#9  0x080db3f3 in Fbyte_code ()
#10 0x080c6a8a in funcall_lambda ()
#11 0x080c64dc in Ffuncall ()
#12 0x080db3f3 in Fbyte_code ()
#13 0x080c6a8a in funcall_lambda ()
#14 0x080c64dc in Ffuncall ()
#15 0x080db3f3 in Fbyte_code ()
#16 0x080c6a8a in funcall_lambda ()
#17 0x080c64dc in Ffuncall ()
#18 0x080db3f3 in Fbyte_code ()
#19 0x080c6a8a in funcall_lambda ()
#20 0x080c687e in apply_lambda ()
#21 0x080c5564 in Feval ()
#22 0x0807fa43 in top_level_2 ()
#23 0x080c47ac in internal_condition_case ()
#24 0x0807fa80 in top_level_1 ()
#25 0x080c431b in internal_catch ()
#26 0x0807f9ae in command_loop ()
#27 0x0807f623 in recursive_edit_1 ()
#28 0x0807f6f8 in Frecursive_edit ()
#29 0x0807e5e5 in main ()
#30 0x40240bb4 in __libc_start_main () from /lib/libc.so.6
(gdb)
=================
The last few lines of strace:
=================
open("/usr/X11R6/lib/X11/icons/default/index.theme", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0755, st_size=27, ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x401c3000
read(3, "[Icon Theme]\nInherits=core\n", 4096) = 27
close(3)                                = 0
munmap(0x401c3000, 4096)                = 0
--- SIGSEGV (Segmentation fault) ---
rt_sigaction(SIGSEGV, {SIG_DFL}, {0x807dbf0, [], SA_RESTART|0x4000000}, 8) = 0
getpgrp()                               = 11004
ioctl(0, 0x540f, [11004])               = 0
write(2, "Fatal error (11).", 17)       = 17
rt_sigaction(SIGIO, {SIG_IGN}, {0x80845b0, [], SA_RESTART|0x4000000}, 8) = 0
rt_sigprocmask(SIG_UNBLOCK, [SEGV 35 43 44 45 46 47 52 53 60 61], [SEGV], 8) = 0
getpid()                                = 11005
kill(11005, SIGSEGV)                    = 0
--- SIGSEGV (Segmentation fault) ---
+++ killed by SIGSEGV +++
================================

Thien-Thi Nguyen wrote:
> Hin-Tak Leung <hintak_leung@yahoo.co.uk> writes:
> 
>    (Sigh). I would have been a lot happier if one of you had
>    replied with "get me a gdb back strace" than having to digress
>    to lengthy philosphical discussion on reasons to use an
>    older version, or resorting to foul languages.
> 
> although it is encouraging that you know yourself well enough to say
> this, i confess to not feeling comfortable ordering you about like an
> employee.  these lengthy discussions surely would be better replaced by
> some concrete information (as "concrete" as information can be ;-), it
> seems you're saying.  the reasons for using this version (or any version
> for that matter) are not really germaine to debugging the problem, you
> also note.
> 
>    As I said, I would prefer a "yes" or "no" to the gdb debug
>    question. It isn't to difficult to answer either:
>    (1) "possibly, depending on how deep the problem is; can't promise"
>    (2) "Sorry no, no eperience with gdb whatsoever"
> 
> what if some people on the list respond (1) and some people respond
> (2) -- what have you gained and/or lost by this exercise?
> 
>    But you are trying to draw into philosophical discussion again.
>    (I guess that's still better than the "get a f*cking life"
>    or "cheeky f*cker" replies)
> 
> a personal quirk, no doubt: all discussion is philosophical to me, even
> those involving hard bits of free software artifact (both pre- and post-
> core dump ;-).
> 
>    If I had sounded impatient, I had not resort to verbal
>    violence as some others did.
> 
> sometimes the sudden move is easy to interpret as both violent and
> beautiful, and sometimes funny and sometimes sad.  where there is room
> for interpretation there is room for misunderstanding (and bugs!).
> 
> thi
> 

Re: emacs-19.34 segfaults when built with Xfree 4.3.0(glibc2.3.x,gcc 3.2)

[Kai Großjohann]

Hin-Tak Leung <hintak_leung@yahoo.co.uk> writes:

> Program received signal SIGSEGV, Segmentation fault.
> 0x400908b3 in XtInitializeWidgetClass () from /usr/X11R6/lib/libXt.so.6
> (gdb) bt
> #0  0x400908b3 in XtInitializeWidgetClass () from /usr/X11R6/lib/libXt.so.6
> #1  0x400916a2 in _XtCreateWidget () from /usr/X11R6/lib/libXt.so.6

Interesting.  It dies deep inside the toolkit.

What happens if you compile Emacs without a toolkit?  (I'm trying to
find out if the toolkit is the problem.)
-- 
This line is not blank.

Re: emacs-19.34 segfaults when built with Xfree 4.3.0 (glibc2.3.x,gcc 3.2)

[Tomoyuki Murakami]

Hi all,

From: Hin-Tak Leung                                        
Subject: Re: emacs-19.34 segfaults when built with Xfree 4.3.0
            (glibc2.3.x,gcc 3.2)                                       
Date: Mon, 12 May 2003 23:11:46 +0100                               

> Here is the long awaited gdb back trace and strace. It seems to die
> at the same place that emacs-21/AIX dies if it is run over a slow
> dial-up connection (there were two different patches for that, one of
> them by Mr Stallman himself no less, if I remember correctly)
> - probably not related. Thought I'd mention this just in case.

The same core dump happens on my environment,
    FreeBSD 5.1R
    XFree86 4.3.0
    Emacs 21.3

So I would try debugging, re-configure XFree86 with  
   #define  DebugLibXt YES
on host.def, and linking debug-enabled libXt (libXt_d.a) to emacs.

And, then, the core dump does not happen any more !
I don't know why. 
It seems that static binary emacs doesn't crash at this point.

To make emacs statically,

$ CC="gcc -static" ./configure your-system-type ...

plus I needed CFLAGS="-DNO_ABORT" to avoid compile error.

----
Tomo.