Peter,
Thanks for the prompt reply!
On 2008-01-28 02:04:02 -1000 Peter Dyballa <[EMAIL PROTECTED]>
wrote:
>
> Am 28.01.2008 um 10:41 schrieb Chris Hall:
>
>> I did find something via Google relating to CCDOSPY (the file being
>> byte
>> compiled when ../src/emacs seg faults)
>
>
> AFAIR unexmacosx.c was changed for the latest release particularly
> for Mac
> OS X reasons. I have in emacs-23.0.0_NS-9.0rc3/src unexmacosx.c.orig
> and
> unexmacosx.c. You could try to save unexmacosx.c as
> unexmacosx.c-not_working
> and enable unexmacosx.c.orig, which is from RC1. Could be this
> works. And if
> not, there is another unexmacosx.c from RC2a ...
I wish it could have been this easy, but I am running Debian Linux
i386, and judging by the time stamps for the files in ../src, rather
than 'unexmacosx.c', instead 'unexelf.c' was built -- which seems
absolutely the proper file for my machine environment.
So, from the command line I tried ../src/emacs (with no other
arguments) -- it seg faulted.
So, I tried the same thing, this time using gdb (but I first had to
'su -c "echo 0 >/proc/sys/vm/vdso_enabled"' so gdb would work properly
on my kernel. *sigh*).
But I *think* some useful information resulted.
After some trial and error, here is my initial gdb session.
===========================================
~/GNUstep/Build/emacs-23.0.0_NS-9.0rc3/nextstep$ gdb ../src/emacs
GNU gdb 6.3-debian
Copyright 2004 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-linux"...Using host libthread_db
library "/lib/tls/libthread_db.so.1".
(gdb) run -batch --no-init-file --no-site-file --multibyte -f
batch-byte-compile quail/CCDOSPY.el
Starting program:
/home/cjh/GNUstep/Build/emacs-23.0.0_NS-9.0rc3/src/emacs -batch
--no-init-file --no-site-file --multibyte -f batch-byte-compile
quail/CCDOSPY.el
[Thread debugging using libthread_db enabled]
[New Thread -1222926208 (LWP 23067)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1222926208 (LWP 23067)]
Ffuncall (nargs=3, args=0xbf253060) at eval.c:2949
2949 {
(gdb) bt 15
#0 Ffuncall (nargs=3, args=0xbf253060) at eval.c:2949
#1 0x08197a1e in call2 (fn=0, arg1=138835841, arg2=140451101) at
eval.c:2837
#2 0x08195e8b in Fsignal (error_symbol=138835841, data=140451101) at
eval.c:1663
#3 0x081960a6 in xsignal (error_symbol=140451101, data=140451101) at
eval.c:1736
#4 0x0819610e in xsignal1 (error_symbol=140451101, arg=140451101) at
eval.c:1753
#5 0x08197ca7 in Ffuncall (nargs=3, args=0xbf253190) at eval.c:3096
#6 0x08197a1e in call2 (fn=0, arg1=138835841, arg2=140451093) at
eval.c:2837
#7 0x08195e8b in Fsignal (error_symbol=138835841, data=140451093) at
eval.c:1663
#8 0x081960a6 in xsignal (error_symbol=140451101, data=140451101) at
eval.c:1736
#9 0x0819610e in xsignal1 (error_symbol=140451101, arg=140451101) at
eval.c:1753
#10 0x08197ca7 in Ffuncall (nargs=3, args=0xbf2532c0) at eval.c:3096
#11 0x08197a1e in call2 (fn=0, arg1=138835841, arg2=140451085) at
eval.c:2837
#12 0x08195e8b in Fsignal (error_symbol=138835841, data=140451085) at
eval.c:1663
#13 0x081960a6 in xsignal (error_symbol=140451101, data=140451101) at
eval.c:1736
#14 0x0819610e in xsignal1 (error_symbol=140451101, arg=140451101) at
eval.c:1753
(More stack frames follow...)
(gdb) bt -5
#137711 0x0819b79e in Flength (sequence=138836081) at fns.c:183
#137712 0x0819cc05 in concat (nargs=1, args=0xbfa4f340,
target_type=Lisp_Cons, last_special=0)
at fns.c:567
#137713 0x0819c2db in Fcopy_sequence (arg=138441645) at fns.c:496
#137714 0x081d2a51 in set_initial_environment () at callproc.c:1668
#137715 0x0811cacf in main (argc=8, argv=0xbfa4f704) at emacs.c:1576
(gdb)
================================================
I am no expert, but at this point, it sure looks to me like there is
"infinite" loop chewing up the stack -- there are nearly 138K stack
frames, and AFAICT other than the "outer" 5 at the very start, they
are that loop. :)
(I visually verified about 11,000 stack frames -- all the same loop).
If I try 'bt -6' to see what gets called from 'FLength', well, gdb seg
faults.
Its been a long time since I did C -- for the past few years its been
Lisp, Guile Scheme and Squeak Smalltalk -- and I've never "really"
used gdb. I must say I'm pretty impressed with it -- it knows when it
sees ObjC!
Anyway, a few more hours fooling around yielded this:
=================================================
[EMAIL PROTECTED]:~/GNUstep/Build/emacs-23.0.0_NS-9.0rc3/nextstep$ gdb
../src/emacs
GNU gdb 6.3-debian
Copyright 2004 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-linux"...Using host libthread_db
library "/lib/tls/libthread_db.so.1".
(gdb) set args -batch --no-init-file --no-site-file --multibyte -f
batch-byte-compile quail/CCDOSPY.el
(gdb) break eval.c:3096
Breakpoint 1 at 0x8197c93: file eval.c, line 3096.
(gdb) start
Breakpoint 2 at 0x811c116: file emacs.c, line 829.
Starting program:
/home/cjh/GNUstep/Build/emacs-23.0.0_NS-9.0rc3/src/emacs -batch
--no-init-file --no-site-file --multibyte -f batch-byte-compile
quail/CCDOSPY.el
[Thread debugging using libthread_db enabled]
[New Thread -1222307712 (LWP 23243)]
[Switching to Thread -1222307712 (LWP 23243)]
main (argc=8, argv=0xbfa476f4) at emacs.c:829
829 stack_base = &dummy;
(gdb) continue
Continuing.
Breakpoint 1, Ffuncall (nargs=3, args=0xbfa47140) at eval.c:3096
3096 xsignal1 (Qinvalid_function, original_fun);
(gdb) bt
#0 Ffuncall (nargs=3, args=0xbfa47140) at eval.c:3096
#1 0x08197a1e in call2 (fn=0, arg1=138835649, arg2=138441661) at
eval.c:2837
#2 0x08195e8b in Fsignal (error_symbol=138835649, data=138441661) at
eval.c:1663
#3 0x081960a6 in xsignal (error_symbol=2, data=2) at eval.c:1736
#4 0x08196145 in xsignal2 (error_symbol=2, arg1=2, arg2=2) at
eval.c:1760
#5 0x08180a21 in wrong_type_argument (predicate=2, value=0) at
data.c:122
#6 0x0819b79e in Flength (sequence=138836081) at fns.c:183
#7 0x0819cc05 in concat (nargs=1, args=0xbfa47330,
target_type=Lisp_Cons, last_special=0)
at fns.c:567
#8 0x0819c2db in Fcopy_sequence (arg=138441645) at fns.c:496
#9 0x081d2a51 in set_initial_environment () at callproc.c:1668
#10 0x0811cacf in main (argc=8, argv=0xbfa476f4) at emacs.c:1576
(gdb) frame 9
#9 0x081d2a51 in set_initial_environment () at callproc.c:1668
1668 Vinitial_environment = Fcopy_sequence
(Vprocess_environment);
(gdb) info locals
envp = (char **) 0xbfa477c0
(gdb) print *envp
$1 = 0x0
(gdb) list
1663 for (envp = environ; *envp; envp++)
1664 Vprocess_environment = Fcons (build_string (*envp),
1665 Vprocess_environment);
1666 /* Ideally, the `copy' shouldn't be necessary, but it
seems it's frequent
1667 to use `delete' and friends on process-environment.
*/
1668 Vinitial_environment = Fcopy_sequence
(Vprocess_environment);
1669 }
1670 }
1671
1672 void
=====================================================
If I am reading this correctly, '*envp' is nil upon first entry, yet
the loop still executes thus starting the "infinite" loop.
What may be even more interesting is this (from the same gdb session):
=====================================================
(gdb) set var $envp = environ
(gdb) print *$envp
$9 = 0xbfa486a2 "SSH_AGENT_PID=7861"
(gdb) set $envp = ++$envp
(gdb) print *$envp
$10 = 0xbfa486b5 "TERM_PROGRAM=GNUstep_Terminal"
(gdb) set $envp = ++$envp
(gdb) print *$envp
$11 = 0xbfa486d3 "GNUSTEP_IS_FLATTENED=yes"
======================================================
So, IIUC, the 'environ' call is working just fine on my machine inside
of gdb, but _not_ from within function 'set_initial_environment()' in
the ../src/emacs.
Here is the source of that function:
=====================================================
void
set_initial_environment ()
{
register char **envp;
#ifndef CANNOT_DUMP
if (initialized)
#endif
{
for (envp = environ; *envp; envp++)
Vprocess_environment = Fcons (build_string (*envp),
Vprocess_environment);
/* Ideally, the `copy' shouldn't be necessary, but it seems it's
frequent
to use `delete' and friends on process-environment. */
Vinitial_environment = Fcopy_sequence (Vprocess_environment);
}
}
=====================================================
A little grepping and Emacs TAGS goodness leads us to this in
'config.h:969':
=====================================================
/* If we're using NeXTstep, define some consequences. */
#ifdef HAVE_NS
#define HAVE_WINDOW_SYSTEM
#define MULTI_KBOARD
#define HAVE_MOUSE
#ifdef GNUSTEP
#define CANNOT_DUMP
#endif
/* PENDING: These are used tor the Carbon port only. */
/* #undef MAC_OS */
/* #undef MAC_OSX */
#endif
======================================================
So:
a) I _am_ using GNUstep, thus CANNOT_DUMP _is_ defined.
b) Thus, the 'if (initialized)' is not getting compiled.
Any Emacs hackers here have any ideas?
Thanks,
Chris Hall
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Emacs-app-dev- mailing list
Emacs-app-dev-@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emacs-app-dev-
