Discussion:
Building Emacs-cvs on Cygwin
(too old to reply)
Angelo Graziosi
1970-01-01 00:00:00 UTC
Permalink
I often try to build emacs-cvs in this way:
Eli Zaretskii
2006-09-20 03:29:36 UTC
Permalink
Date: Wed, 20 Sep 2006 01:49:56 +0200 (MET DST)
-------------------------------------------------------------
$ gdb --args ../src/bootstrap-emacs.exe -batch --no-site-file --multibyte
Please run this from the `src' directory, since it includes a .gdbinit
file which will greatly help in debugging Emacs.
GNU gdb 6.5.50.20060706-cvs (cygwin-special)
Copyright (C) 2006 Free Software Foundation, Inc.
...
This GDB was configured as "i686-pc-cygwin"...(no debugging symbols found)
^^^^^^^^^^^^^^^^^^^^^^^^^^^
That is no good: your Emacs binary is somehow stripped, so it will be
very hard to debug it. Please modify your build procedure so that
Emacs is not stripped.
(gdb) r
Starting program: /tmp/emacs/src/bootstrap-emacs.exe -batch --no-site-file
--multibyte -l autoload --eval \(setq\ generated-autoload-file\
\"/tmp/emacs/lisp/loaddefs.el\"\) -f batch-update-autoloads
/tmp/emacs/lisp/. /tmp/emacs/lisp/./calc
/tmp/emacs/lisp/./calendar /tmp/emacs/lisp/./emacs-lisp
/tmp/emacs/lisp/./emulation /tmp/emacs/lisp/./erc /tmp/emacs/lisp/./eshell /tmp/emacs/lisp/./gnus
/tmp/emacs/lisp/./international /tmp/emacs/lisp/./language
/tmp/emacs/lisp/./mail /tmp
/emacs/lisp/./mh-e /tmp/emacs/lisp/./net /tmp/emacs/lisp/./obsolete
/tmp/emacs/lisp/./play /tmp/emacs/lisp/./progmodes /tmp/emacs/lisp/./term
/tmp/emacs/lisp/./textmodes /tmp/emacs/lisp/./url
[3]+ Stopped gdb --args ../src/bootstrap-emacs.exe -batch
Why ``Stopped''? Did you type something to stop the job?
Angelo Graziosi
1970-01-01 00:00:00 UTC
Permalink
Post by Eli Zaretskii
GNU gdb 6.5.50.20060706-cvs (cygwin-special)
Copyright (C) 2006 Free Software Foundation, Inc.
...
This GDB was configured as "i686-pc-cygwin"...(no debugging symbols found)
^^^^^^^^^^^^^^^^^^^^^^^^^^^
I think this refers to GDB (even with CFLAGS='-g' I obtain it, see below)
Post by Eli Zaretskii
That is no good: your Emacs binary is somehow stripped, so it will be
very hard to debug it. Please modify your build procedure so that
Emacs is not stripped.
/tmp/emacs/lisp/./textmodes /tmp/emacs/lisp/./url
[3]+ Stopped gdb --args ../src/bootstrap-emacs.exe -batch
Why ``Stopped''? Did you type something to stop the job?
Absolutely : NO !

I have typed only 'r'

(gdb) r


Now there is what I have done (I have copy/pasted) following your
suggestions:
==========================================================================
$ cd emacs
$ CFLAGS='-g' ./configure
$ CFLAGS='-g' make bootstrap 2>&1 | tee ../build-emacs-cvs.log

...
$ make[2]: Entering directory `/tmp/emacs/lisp'
wd=/tmp/emacs/lisp; subdirs=`(cd $wd; find . -type d -print)`; for file in
$subdirs; do case $file in */Old | */RCS | */CVS | */CVS/* | */.* | */.*/*
| */=* ) ;; *) wins="$wins $wd/$file" ;; esac; done; \
for file in $wins; do \
/tmp/emacs/lisp/../update-subdirs $file; \
done;
wd=/tmp/emacs/lisp; subdirs=`(cd $wd; find . -type d -print)`; for file in
$subdirs; do case $file in */Old | */RCS | */CVS | */CVS/* | */.* | */.*/*
| */=* ) ;; *) wins="$wins $wd/$file" ;; esac; done; \
echo Directories: $wins; \
../src/bootstrap-emacs.exe -batch --no-site-file --multibyte -l
autoload --eval '(setq generated-autoload-file
"/tmp/emacs/lisp/loaddefs.el")' -f batch-update-autoloads $wins
Directories: /tmp/emacs/lisp/. /tmp/emacs/lisp/./calc
/tmp/emacs/lisp/./calendar /tmp/emacs/lisp/./emacs-lisp
/tmp/emacs/lisp/./emulation /tmp/emacs/lisp/./erc /tmp/emacs/lisp/./eshell
/tmp/emacs/lisp/./gnus /tmp/emacs/lisp/./international
/tmp/emacs/lisp/./language /tmp/emacs/lisp/./mail /tmp/emacs/lisp/./mh-e
/tmp/emacs/lisp/./net /tmp/emacs/lisp/./obsolete /tmp/emacs/lisp/./play
/tmp/emacs/lisp/./progmodes /tmp/emacs/lisp/./term
/tmp/emacs/lisp/./textmodes /tmp/emacs/lisp/./url
Fatal error (6)/bin/sh: line 2: 1388 Aborted (core
dumped) ../src/bootstrap-emacs.exe -batch --no-site-file --multibyte -l
autoload --eval '(setq generated-autoload-file
"/tmp/emacs/lisp/loaddefs.el")' -f batch-update-autoloads $wins
make[2]: *** [autoloads] Error 134
make[2]: Leaving directory `/tmp/emacs/lisp'
make[1]: *** [bootstrap-build] Error 2
make[1]: Leaving directory `/tmp/emacs'
make: *** [bootstrap] Error 2

$ cd src

$ gdb --args ../src/bootstrap-emacs.exe -batch --no-site-file --multibyte
-l autoload --eval '(setq generated-autoload-file
"/tmp/emacs/lisp/loaddefs.el")' -f batch-update-autoloads
/tmp/emacs/lisp/. /tmp/emacs/lisp/./calc /tmp/emacs/lisp/./calendar
/tmp/emacs/lisp/./emacs-lisp /tmp/emacs/lisp/./emulation
/tmp/emacs/lisp/./erc /tmp/emacs/lisp/./eshell /tmp/emacs/lisp/./gnus
/tmp/emacs/lisp/./international /tmp/emacs/lisp/./language
/tmp/emacs/lisp/./mail /tmp/emacs/lisp/./mh-e /tmp/emacs/lisp/./net
/tmp/emacs/lisp/./obsolete /tmp/emacs/lisp/./play
/tmp/emacs/lisp/./progmodes /tmp/emacs/lisp/./term
/tmp/emacs/lisp/./textmodes /tmp/emacs/lisp/./url
GNU gdb 6.5.50.20060706-cvs (cygwin-special)
Copyright (C) 2006 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 "i686-pc-cygwin"...(no debugging symbols found)
^^^^^^^^^^^^^^^^^^^^^^^^^^
DISPLAY = :0.0
TERM = xterm
/tmp/emacs/src/.gdbinit:1089: Error in sourced command file:
No struct type named Lisp_Symbol.
(gdb) r
Starting program: /tmp/emacs/src/bootstrap-emacs.exe -geometry 80x40+0+0
Loaded symbols for /c/WINDOWS/system32/ntdll.dll
Loaded symbols for /c/WINDOWS/system32/kernel32.dll
Loaded symbols for /usr/X11R6/bin/cygICE-6.dll
Loaded symbols for /usr/bin/cygwin1.dll
Loaded symbols for /c/WINDOWS/system32/advapi32.dll
Loaded symbols for /c/WINDOWS/system32/rpcrt4.dll
Loaded symbols for /usr/X11R6/bin/cygSM-6.dll
Loaded symbols for /usr/X11R6/bin/cygX11-6.dll
Loaded symbols for /usr/X11R6/bin/cygXaw3d-7.dll
Loaded symbols for /usr/X11R6/bin/cygXext-6.dll
Loaded symbols for /usr/X11R6/bin/cygXmu-6.dll
Loaded symbols for /usr/X11R6/bin/cygXt-6.dll
Loaded symbols for /usr/X11R6/bin/cygXpm-4.dll
Loaded symbols for /usr/bin/cygncurses-8.dll
Loaded symbols for /usr/bin/cygjpeg-62.dll
Loaded symbols for /usr/bin/cygpng12.dll
Loaded symbols for /usr/bin/cygz.dll
Loaded symbols for /usr/bin/cygtiff-5.dll
Loaded symbols for /usr/bin/cygungif-4.dll

[1]+ Stopped gdb --args ../src/bootstrap-emacs.exe -batch
--no-site-file --multibyte -l autoload --eval '(setq
generated-autoload-file "/tmp/emacs/lisp/loaddefs.el")' -f
batch-update-autoloads /tmp/emacs/lisp/. /tmp/emacs/lisp/./calc
/tmp/emacs/lisp/./calendar /tmp/emacs/lisp/./emacs-lisp
/tmp/emacs/lisp/./emulation /tmp/emacs/lisp/./erc /tmp/emacs/lisp/./eshell
/tmp/emacs/lisp/./gnus /tmp/emacs/lisp/./international
/tmp/emacs/lisp/./language /tmp/emacs/lisp/./mail /tmp/emacs/lisp/./mh-e
/tmp/emacs/lisp/./net /tmp/emacs/lisp/./obsolete /tmp/emacs/lisp/./play
/tmp/emacs/lisp/./progmodes /tmp/emacs/lisp/./term
/tmp/emacs/lisp/./textmodes /tmp/emacs/lisp/./url
$

i.e. it exit (?) from GDB but:

$ ps
PID PPID PGID WINPID TTY UID STIME COMMAND
I 2288 1 2288 2288 con 1003 10:07:16 /usr/bin/bash
3060 2288 3060 3076 con 1003 10:07:33 /usr/bin/sh
3088 3060 3060 3104 con 1003 10:07:33
/usr/X11R6/bin/xinit
3116 3088 3116 3136 con 1003 10:07:33
/usr/X11R6/bin/XWin
3304 3088 3304 3332 con 1003 10:07:41 /usr/bin/urxvt-X
3428 3304 3428 3448 0 1003 10:07:42 /usr/bin/bash
2616 2288 2616 2656 con 1003 10:14:38
/c/Programmi/Crimson Editor/cedt
S 4068 3428 4068 1504 0 1003 10:46:39 /usr/bin/gdb
2712 1 2712 2712 con 1003 10:46:46
/tmp/emacs/src/bootstrap-emacs
4060 3428 4060 3616 0 1003 10:46:48 /usr/bin/ps

==========================================================================


Note the 'no debugging symbols found'.



Cheers,

Angelo.
Eli Zaretskii
2006-09-20 21:08:48 UTC
Permalink
Date: Wed, 20 Sep 2006 11:05:54 +0200 (MET DST)
Post by Eli Zaretskii
This GDB was configured as "i686-pc-cygwin"...(no debugging symbols found)
^^^^^^^^^^^^^^^^^^^^^^^^^^^
I think this refers to GDB
No, I don't think so.
(even with CFLAGS='-g' I obtain it, see below)
Maybe the binary gets stripped somehow, I don't know. Or maybe it's
some problem with GCC/GDB in the Cygwin ports. Please try this
in the Emacs `src' directory:

gdb ./bootstrap-emacs.exe

If it still says "no debugging symbols", you need to find out why is
this happening, because it's impossible to debug a program without
debugging symbols.
Post by Eli Zaretskii
[3]+ Stopped gdb --args ../src/bootstrap-emacs.exe -batch
Why ``Stopped''? Did you type something to stop the job?
Absolutely : NO !
I have typed only 'r'
Then maybe there's another problem with the Cygwin GDB.
Fatal error (6)/bin/sh: line 2: 1388 Aborted (core
dumped)
seems to indicate that the program that crashed is /bin/sh, the ported
Bash, not Emacs. Can you verify that it's the shell that crashes
(e.g., by looking at the PID)?

Another thing to try is downgrade to the previous version of Cygwin.
Andreas Schwab
2006-09-20 22:02:13 UTC
Permalink
Post by Eli Zaretskii
Post by Angelo Graziosi
Fatal error (6)/bin/sh: line 2: 1388 Aborted (core
dumped)
seems to indicate that the program that crashed is /bin/sh,
No, it doesn't. The shell just tells you that process 1388 has died of
SIGABRT (and you stripped the part that contains the command that
crashed).

Andreas.
--
Andreas Schwab, SuSE Labs, ***@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Richard Stallman
2006-09-21 01:59:43 UTC
Permalink
Post by Eli Zaretskii
This GDB was configured as "i686-pc-cygwin"...(no debugging symbols found)
^^^^^^^^^^^^^^^^^^^^^^^^^^^
I think this refers to GDB (even with CFLAGS='-g' I obtain it, see below)

It refers to the program you are debugging. GDB has already tried to
read that executable, and failed.

/tmp/emacs/src/.gdbinit:1089: Error in sourced command file:
No struct type named Lisp_Symbol.

Further proof of the same problem.
Angelo Graziosi
1970-01-01 00:00:00 UTC
Permalink
Hi Eli,

after my last replay
(http://lists.gnu.org/archive/html/emacs-devel/2006-09/msg00829.html) I
have deleted the Emacs build directory, re-unpacked the same CVS source (I
make a tar.bz2 after every cvs download) and newly:

./configure
make bootstrap

and this time the build has (mysteriously) passed the critical point until
the end !

But the build is unstable: after a few second Emacs segment fault.

Now I have updated from CVS and a new build is running. For the moment I
can't try your last suggestions.

Regarding the Cygwin downgrade, I remeber that also with previous version
of Cygwin and snapshot there were similar problem.

Only with the CVS source Aug 15 ans Sep 04 I was able to complete the
build and they works.


Cheers,

Angelo.
Post by Eli Zaretskii
gdb ./bootstrap-emacs.exe
If it still says "no debugging symbols", you need to find out why is
this happening, because it's impossible to debug a program without
debugging symbols.
Post by Angelo Graziosi
Post by Eli Zaretskii
[3]+ Stopped gdb --args ../src/bootstrap-emacs.exe -batch
Why ``Stopped''? Did you type something to stop the job?
Absolutely : NO !
I have typed only 'r'
Then maybe there's another problem with the Cygwin GDB.
Post by Angelo Graziosi
Fatal error (6)/bin/sh: line 2: 1388 Aborted (core
dumped)
seems to indicate that the program that crashed is /bin/sh, the ported
Bash, not Emacs. Can you verify that it's the shell that crashes
(e.g., by looking at the PID)?
Another thing to try is downgrade to the previous version of Cygwin.
Eli Zaretskii
2006-09-21 03:31:41 UTC
Permalink
Date: Thu, 21 Sep 2006 00:41:25 +0200 (MET DST)
./configure
make bootstrap
and this time the build has (mysteriously) passed the critical point until
the end !
But the build is unstable: after a few second Emacs segment fault.
Does this happen even if you leave Emacs to run without doing anything
in Emacs? Or does it happen only if you do your normal work in Emacs?

In any case, can you run Emacs under GDB and show the backtrace when
it crashes?
Angelo Graziosi
1970-01-01 00:00:00 UTC
Permalink
Post by Eli Zaretskii
Does this happen even if you leave Emacs to run without doing anything
in Emacs?
Yes it does, in less then one minute.
Post by Eli Zaretskii
In any case, can you run Emacs under GDB and show the backtrace when
it crashes?
Yes I have tried with the following results (copy/pasted):


-------------------------------------------------------------------
***@homepc /usr/local/emacs-22.0.50/bin
$ ./emacs

(after a few seconds that it started and displyed some files)

Fatal error (11) <== in some cases
Segmentation fault <== always

***@homepc /usr/local/emacs-22.0.50/bin
$

***@homepc /usr/local/emacs-22.0.50/bin
$ ls -lrt
total 31292
-rwxr-xr-x 1 Angelo Administrators 100892 Sep 21 16:35 etags.exe
-rwxr-xr-x 1 Angelo Administrators 103360 Sep 21 16:35 ctags.exe
-rwxr-xr-x 1 Angelo Administrators 25681 Sep 21 16:35 emacsclient.exe
-rwxr-xr-x 1 Angelo Administrators 18983 Sep 21 16:35 b2m.exe
-rwxr-xr-x 1 Angelo Administrators 52222 Sep 21 16:35 ebrowse.exe
-rwxr-xr-x 1 Angelo Administrators 4055 Sep 21 16:35 rcs-checkin
-rwxr-xr-x 1 Angelo Administrators 7204 Sep 21 16:35 grep-changelog
-rwxr-xr-x 2 Angelo Administrators 15858176 Sep 21 16:35 emacs.exe
-rwxr-xr-x 2 Angelo Administrators 15858176 Sep 21 16:35 emacs-22.0.50.exe

***@homepc /usr/local/emacs-22.0.50/bin
$ gdb ./emacs
GNU gdb 6.5.50.20060706-cvs (cygwin-special)
Copyright (C) 2006 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 "i686-pc-cygwin"...(no debugging symbols found)

(gdb) r
Starting program: /usr/local/emacs-22.0.50/bin/emacs.exe
Loaded symbols for /c/WINDOWS/system32/ntdll.dll
Loaded symbols for /c/WINDOWS/system32/kernel32.dll
Loaded symbols for /usr/X11R6/bin/cygICE-6.dll
Loaded symbols for /usr/bin/cygwin1.dll
Loaded symbols for /c/WINDOWS/system32/advapi32.dll
Loaded symbols for /c/WINDOWS/system32/rpcrt4.dll
Loaded symbols for /usr/X11R6/bin/cygSM-6.dll
Loaded symbols for /usr/X11R6/bin/cygX11-6.dll
Loaded symbols for /usr/X11R6/bin/cygXaw3d-7.dll
Loaded symbols for /usr/X11R6/bin/cygXext-6.dll
Loaded symbols for /usr/X11R6/bin/cygXmu-6.dll
Loaded symbols for /usr/X11R6/bin/cygXt-6.dll
Loaded symbols for /usr/X11R6/bin/cygXpm-4.dll
Loaded symbols for /usr/bin/cygncurses-8.dll
Loaded symbols for /usr/bin/cygjpeg-62.dll
Loaded symbols for /usr/bin/cygpng12.dll
Loaded symbols for /usr/bin/cygz.dll
Loaded symbols for /usr/bin/cygtiff-5.dll
Loaded symbols for /usr/bin/cygungif-4.dll

[1]+ Stopped gdb ./emacs

***@homepc /usr/local/emacs-22.0.50/bin

***@homepc /usr/local/emacs-22.0.50/bin
$ ps
PID PPID PGID WINPID TTY UID STIME COMMAND
I 2268 1 2268 2268 con 1003 10:09:56 /usr/bin/bash
3036 2268 3036 3052 con 1003 10:10:10 /usr/bin/sh
3068 3036 3036 3084 con 1003 10:10:11
/usr/X11R6/bin/xinit
3096 3068 3096 3112 con 1003 10:10:11
/usr/X11R6/bin/XWin
3284 3068 3284 3312 con 1003 10:10:19 /usr/bin/urxvt-X
3404 3284 3404 3424 0 1003 10:10:21 /usr/bin/bash
S 2144 3404 2144 2036 0 1003 17:09:38 /usr/bin/gdb
1812 1 1812 1812 con 1003 17:09:44
/usr/local/emacs-22.0.50/bin/emacs
3892 3404 3892 3104 0 1003 17:12:17 /usr/bin/ps

-------------------------------------------------------------------


As you see, the same behaviour of previous posts.


Angelo.
Eli Zaretskii
2006-09-22 13:19:49 UTC
Permalink
Date: Fri, 22 Sep 2006 00:20:43 +0200 (MET DST)
This GDB was configured as "i686-pc-cygwin"...(no debugging symbols found)
We need to solve this ``no debugging symbols found'' problem. Can you
please post the transcript of the entire configure+build procedure, or
(better) look there for the command that stripped the symbols from the
binary?

The ``normal'' build should invoke GCC with the -g option, and should
NOT use the -s option to GCC or the linker in the command that links
temacs.exe. This should produce temacs.exe with debugging symbols,
and then dumping emacs.exe should produce emacs.exe with debugging
symbols.

What happens if you type "gdb ./temacs.exe", does it also say ``no
debugging symbols found''?
(gdb) r
"r -Q" is better, as it doesn't load any init files.
Starting program: /usr/local/emacs-22.0.50/bin/emacs.exe
Loaded symbols for /c/WINDOWS/system32/ntdll.dll
Loaded symbols for /c/WINDOWS/system32/kernel32.dll
Loaded symbols for /usr/X11R6/bin/cygICE-6.dll
Loaded symbols for /usr/bin/cygwin1.dll
Loaded symbols for /c/WINDOWS/system32/advapi32.dll
Loaded symbols for /c/WINDOWS/system32/rpcrt4.dll
Loaded symbols for /usr/X11R6/bin/cygSM-6.dll
Loaded symbols for /usr/X11R6/bin/cygX11-6.dll
Loaded symbols for /usr/X11R6/bin/cygXaw3d-7.dll
Loaded symbols for /usr/X11R6/bin/cygXext-6.dll
Loaded symbols for /usr/X11R6/bin/cygXmu-6.dll
Loaded symbols for /usr/X11R6/bin/cygXt-6.dll
Loaded symbols for /usr/X11R6/bin/cygXpm-4.dll
Loaded symbols for /usr/bin/cygncurses-8.dll
Loaded symbols for /usr/bin/cygjpeg-62.dll
Loaded symbols for /usr/bin/cygpng12.dll
Loaded symbols for /usr/bin/cygz.dll
Loaded symbols for /usr/bin/cygtiff-5.dll
Loaded symbols for /usr/bin/cygungif-4.dll
[1]+ Stopped gdb ./emacs
Can you type "fg" at this point, to get back into GDB?

If that works, can you type "bt" inside GDB and get a meaningful
traceback?
Angelo Graziosi
1970-01-01 00:00:00 UTC
Permalink
Post by Eli Zaretskii
We need to solve this ``no debugging symbols found'' problem. Can you
please post the transcript of the entire configure+build procedure, or
(better) look there for the command that stripped the symbols from the
binary?
I have looked but found anything, so I have attached
Build_Emacs-CVS.tar.bz2 which contains :

build-emacs-cvs.sh
build-emacs-cvs.log
.emacs-cvs

The first is the script to build Emacs-CVS and that produces the .log file
of the building (configure included), the last is the initialization file
(.emacs).
Post by Eli Zaretskii
The ``normal'' build should invoke GCC with the -g option, and should
NOT use the -s option to GCC or the linker in the command that links
temacs.exe. This should produce temacs.exe with debugging symbols,
and then dumping emacs.exe should produce emacs.exe with debugging
symbols.
What happens if you type "gdb ./temacs.exe", does it also say ``no
debugging symbols found''?
I will try this at the next build (tomorrow), I have deleted the building
tree.
Post by Eli Zaretskii
(gdb) r
"r -Q" is better, as it doesn't load any init files.
Starting program: /usr/local/emacs-22.0.50/bin/emacs.exe
...
Post by Eli Zaretskii
Loaded symbols for /usr/bin/cygtiff-5.dll
Loaded symbols for /usr/bin/cygungif-4.dll
[1]+ Stopped gdb ./emacs
Can you type "fg" at this point, to get back into GDB?
Yes (oh yes, fg!); this is the result
-------------------------------------------------------
[1]+ Stopped gdb ./emacs.exe

***@homepc /usr/local/emacs-22.0.50/bin
$ fg
gdb ./emacs.exe
---Type <return> to continue, or q <return> to quit---

warning: NOD32 protected [MSAFD Tcpip [TCP/IP]]
warning: NOD32 protected [MSAFD Tcpip [UDP/IP]]
warning: NOD32 protected [MSAFD Tcpip [RAW/IP]]
warning: NOD32 protected [RSVP UDP Service Provider]
warning: NOD32 protected [RSVP TCP Service Provider]
---Type <return> to continue, or q <return> to quit---

-------------------------------------------------------

A this point Emacs starts and for the moment it seems to works.
Post by Eli Zaretskii
If that works, can you type "bt" inside GDB and get a meaningful
traceback?
I think NO, I haven't any GDB prompt. In any case I have typed 'bt'
without results:

-----------------------------------------------------

...
warning: NOD32 protected [RSVP TCP Service Provider]
---Type <return> to continue, or q <return> to quit---

bt


-----------------------------------------------------

I can continue to type <Return> with the only result to add lines.

After a few minutes that anything happened, I have decided to close Emacs
(click on 'x' button of the window):

--------------------------------------------------------
---Type <return> to continue, or q <return> to quit---

bt



Program exited normally.
(gdb)
(gdb) bt
No stack.
(gdb)
No stack.
(gdb)
No stack.
(gdb) bt
No stack.
(gdb)

--------------------------------------------------------

After this I have repeated using

(gdb) -r


so that also the init file is loaded. For the moment same behaviour
without seg. fault.

I will observe for a longer time the behaviour of Emacs under GDB.


Thanks,

Angelo.
Angelo Graziosi
1970-01-01 00:00:00 UTC
Permalink
Post by Eli Zaretskii
If that works, can you type "bt" inside GDB and get a meaningful
traceback?
Post by Angelo Graziosi
After this I have repeated using
(gdb) -r
so that also the init file is loaded. For the moment same behaviour
without seg. fault.
Wrong ! When I clicked on Emacs window (thinking it was running) I found:
-----------------------------------------------------------------
...
---Type <return> to continue, or q <return> to quit---














q

Program received signal SIGSEGV, Segmentation fault.
0x200f201c in mark_object ()
(gdb)
(gdb)
(gdb)
(gdb)
(gdb)
(gdb)
(gdb)
(gdb)
(gdb)
(gdb)
(gdb)
(gdb)
(gdb)
(gdb)
(gdb) q
The program is running. Exit anyway? (y or n) n
Not confirmed.
(gdb) bt
#0 0x200f201c in mark_object ()
#1 0x200f28ef in Fgarbage_collect ()
#2 0x201063d3 in Feval ()
#3 0x201051f5 in internal_condition_case_1 ()
#4 0x200a47a2 in menu_item_eval_property ()
#5 0x200b0d4e in get_keyelt ()
#6 0x200b13a3 in access_keymap ()
#7 0x200a5496 in tool_bar_items ()
#8 0x2001d51f in update_tool_bar ()
#9 0x2002bc8f in prepare_menu_bars ()
#10 0x2002c8ec in redisplay_internal ()
#11 0x2002d08a in redisplay_preserve_echo_area ()
#12 0x200a7aec in detect_input_pending_run_timers ()
#13 0x2013a0f5 in wait_reading_process_output ()
#14 0x200a8e40 in read_char ()
#15 0x200ab88d in read_key_sequence ()
#16 0x200ad3d1 in command_loop_1 ()
#17 0x2010542f in internal_condition_case ()
#18 0x200a0a8e in command_loop_2 ()
#19 0x201050ef in internal_catch ()
#20 0x200a08a3 in command_loop ()
#21 0x200a0944 in recursive_edit_1 ()
#22 0x200a0a20 in Frecursive_edit ()
---Type <return> to continue, or q <return> to quit---
#23 0x2009fd9d in main ()
(gdb)

-----------------------------------------------------------------


Cheers,

Angelo.
Angelo Graziosi
1970-01-01 00:00:00 UTC
Permalink
Post by Eli Zaretskii
Date: Wed, 20 Sep 2006 11:05:54 +0200 (MET DST)
Post by Eli Zaretskii
This GDB was configured as "i686-pc-cygwin"...(no debugging symbols found)
^^^^^^^^^^^^^^^^^^^^^^^^^^^
I think this refers to GDB
No, I don't think so.
It refers to the program you are debugging. GDB has already tried to
read that executable, and failed.
No struct type named Lisp_Symbol.
Further proof of the same problem.
Considere the following examples:

---------------------------------------------------------
$ cat hello.c
#include <stdio.h>

int main()
{
printf("Hello, World!");
return 0;
}

$ gcc -g hello.c -o hello
^^^^^

$ gdb ./hello.exe
GNU gdb 6.5.50.20060706-cvs (cygwin-special)
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
ar
welcome to change it and/or distribute copies of it under certain
condition
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for
details.
This GDB was configured as "i686-pc-cygwin"...(no debugging symbols found)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
(gdb)
---------------------------------------------------------

---------------------------------------------------------
$ cat hello.F
program hello
implicit none
write(*,*) 'Hello!'
end

$ g77 -g hello.F -o hello
^^^^^

$ gdb ./hello.exe
GNU gdb 6.5.50.20060706-cvs (cygwin-special)
Copyright (C) 2006 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 "i686-pc-cygwin"...(no debugging symbols found)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
(gdb)
---------------------------------------------------------


Or I have missed something or there is something wrong in the above if
yours conclusions are correct.


Cheers,

Angelo.
Eli Zaretskii
2006-09-23 15:15:23 UTC
Permalink
Date: Sat, 23 Sep 2006 12:33:23 +0200 (MET DST)
---------------------------------------------------------
$ cat hello.c
#include <stdio.h>
int main()
{
printf("Hello, World!");
return 0;
}
$ gcc -g hello.c -o hello
^^^^^
$ gdb ./hello.exe
GNU gdb 6.5.50.20060706-cvs (cygwin-special)
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
ar
welcome to change it and/or distribute copies of it under certain
condition
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for
details.
This GDB was configured as "i686-pc-cygwin"...(no debugging symbols found)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
(gdb)
How about the following compilation command--does it also cause GDB to
complain about debugging symbols?

gcc -gdwarf-2 -g3 hello.c -o hello

Also, if you type the following two commands after starting GDB, what
does GDB say?

(gdb) start
(gdb) info source
Richard Stallman
2006-09-24 02:10:27 UTC
Permalink
Maybe you are right, but why would GDB care whether it was compiled
with debugging symbols? And how could it know?
Angelo Graziosi
1970-01-01 00:00:00 UTC
Permalink
Post by Eli Zaretskii
Date: Sat, 23 Sep 2006 12:33:23 +0200 (MET DST)
---------------------------------------------------------
$ cat hello.c
#include <stdio.h>
int main()
{
printf("Hello, World!");
return 0;
}
$ gcc -g hello.c -o hello
^^^^^
$ gdb ./hello.exe
GNU gdb 6.5.50.20060706-cvs (cygwin-special)
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
ar
welcome to change it and/or distribute copies of it under certain
condition
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for
details.
This GDB was configured as "i686-pc-cygwin"...(no debugging symbols found)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
(gdb)
How about the following compilation command--does it also cause GDB to
complain about debugging symbols?
gcc -gdwarf-2 -g3 hello.c -o hello
NO! I does NOT!!!
Post by Eli Zaretskii
Also, if you type the following two commands after starting GDB, what
does GDB say?
(gdb) start
(gdb) info source
I have copy/pasted the result:
-----------------------------------------------------------------
$ gcc -gdwarf-2 -g3 hello.c -o hello

$ gdb ./hello.exe
GNU gdb 6.5.50.20060706-cvs (cygwin-special)
Copyright (C) 2006 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 "i686-pc-cygwin"... <== note this ====|
(gdb) start
Breakpoint 1 at 0x401075: file hello.c, line 4.
Starting program: /tmp/hello.exe
Loaded symbols for /c/WINDOWS/system32/ntdll.dll
Loaded symbols for /c/WINDOWS/system32/kernel32.dll
Loaded symbols for /usr/bin/cygwin1.dll
Loaded symbols for /c/WINDOWS/system32/advapi32.dll
Loaded symbols for /c/WINDOWS/system32/rpcrt4.dll
main () at hello.c:4
4 {
(gdb) info source
Current source file is hello.c
Compilation directory is /tmp/
Located in /tmp/hello.c
Contains 7 lines.
Source language is c.
Compiled with stabs debugging format.
Does not include preprocessor macro info.
(gdb)
-----------------------------------------------------------------


Cheers,

Angelo.
Eli Zaretskii
2006-09-23 19:17:43 UTC
Permalink
Date: Sat, 23 Sep 2006 18:49:59 +0200 (MET DST)
Post by Eli Zaretskii
How about the following compilation command--does it also cause GDB to
complain about debugging symbols?
gcc -gdwarf-2 -g3 hello.c -o hello
NO! I does NOT!!!
Good!
(gdb) info source
Current source file is hello.c
Compilation directory is /tmp/
Located in /tmp/hello.c
Contains 7 lines.
Source language is c.
Compiled with stabs debugging format.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This doesn't look right: it should have told ``with DWARF 2 debugging
format''. That's what the -gdwarf-2 switch is about. I wonder what
the heck is going on here.

Can you please add -v to the compilation command line, like this:

gcc -v -gdwarf-2 -g3 hello.c -o hello

and post here everything that is displayed by the compiler?
Angelo Graziosi
1970-01-01 00:00:00 UTC
Permalink
Post by Eli Zaretskii
Post by Angelo Graziosi
Source language is c.
Compiled with stabs debugging format.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This doesn't look right: it should have told ``with DWARF 2 debugging
format''. That's what the -gdwarf-2 switch is about. I wonder what
the heck is going on here.
gcc -v -gdwarf-2 -g3 hello.c -o hello
and post here everything that is displayed by the compiler?
This is the output:
----------------------------------------------------------------
$ gcc -v -gdwarf-2 -g3 hello.c -o hello
Reading specs from /usr/lib/gcc/i686-pc-cygwin/3.4.4/specs
Configured with: /usr/build/package/orig/test.new4/gcc-3.4.4-2/configure
--verbose --prefix=/usr --exec-prefix=/usr --sysconfdir=/etc --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
--enable-languages=c,ada,c++,d,f77,pascal,java,objc --enable-nls
--without-included-gettext --enable-version-specific-runtime-libs --without-x --enable-libgcj
--disable-java-awt --with-system-zlib --enable-interpreter --disable-libgcj-debug
--enable-threads=posix --enable-java-gc=boehm --disable-win32-registry
--enable-sjlj-exceptions
--enable-hash-synchronization --enable-libstdcxx-debug
Thread model: posix
gcc version 3.4.4 (cygming special, gdc 0.12, using dmd 0.125)
/usr/lib/gcc/i686-pc-cygwin/3.4.4/cc1.exe -quiet -v -dD -D__CYGWIN32__
-D__CYGW
IN__ -Dunix -D__unix__ -D__unix -idirafter
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../
../../../include/w32api -idirafter
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../..
/i686-pc-cygwin/lib/../../include/w32api hello.c -quiet -dumpbase hello.c
-mtune=pentiumpro -auxbase hello-gdwarf-2 -g3 -version -o
/c/DOCUME~1/Angelo/IMPOST~1/Temp/ccqUrPqN.s
ignoring nonexistent directory
"/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/include"
ignoring duplicate directory
"/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/lib/../../include/w32api"
#include "..." search starts here:
#include <...> search starts here:
/usr/local/include
/usr/lib/gcc/i686-pc-cygwin/3.4.4/include
/usr/include
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api
End of search list.
GNU C version 3.4.4 (cygming special, gdc 0.12, using dmd
0.125) (i686-pc-cygwin
)
compiled by GNU C version 3.4.4 (cygming special, gdc 0.12, using
dmd 0.125).
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/bin/as.exe
-o /c/D
OCUME~1/Angelo/IMPOST~1/Temp/ccLc4MTM.o
/c/DOCUME~1/Angelo/IMPOST~1/Temp/ccqUrPq
N.s
/usr/lib/gcc/i686-pc-cygwin/3.4.4/collect2.exe -Bdynamic
--dll-search-prefix=cy
g -o hello.exe /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../crt0.o
-L/usr/lib/gcc/
i686-pc-cygwin/3.4.4 -L/usr/lib/gcc/i686-pc-cygwin/3.4.4
-L/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../.. /c/DOCUME~1/Angelo/IMPOST~1/Temp/ccLc4MTM.o -lgcc
-lcygwin
-luser32 -lkernel32 -ladvapi32 -lshell32 -lgcc

$
----------------------------------------------------------------


Angelo.
Eli Zaretskii
2006-09-24 07:41:43 UTC
Permalink
Date: Sat, 23 Sep 2006 23:19:27 +0200 (MET DST)
Post by Eli Zaretskii
gcc -v -gdwarf-2 -g3 hello.c -o hello
and post here everything that is displayed by the compiler?
----------------------------------------------------------------
$ gcc -v -gdwarf-2 -g3 hello.c -o hello
Reading specs from /usr/lib/gcc/i686-pc-cygwin/3.4.4/specs
Configured with: /usr/build/package/orig/test.new4/gcc-3.4.4-2/configure
--verbose --prefix=/usr --exec-prefix=/usr --sysconfdir=/etc --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
--enable-languages=c,ada,c++,d,f77,pascal,java,objc --enable-nls
--without-included-gettext --enable-version-specific-runtime-libs --without-x --enable-libgcj
--disable-java-awt --with-system-zlib --enable-interpreter --disable-libgcj-debug
--enable-threads=posix --enable-java-gc=boehm --disable-win32-registry
--enable-sjlj-exceptions
--enable-hash-synchronization --enable-libstdcxx-debug
Thread model: posix
gcc version 3.4.4 (cygming special, gdc 0.12, using dmd 0.125)
/usr/lib/gcc/i686-pc-cygwin/3.4.4/cc1.exe -quiet -v -dD -D__CYGWIN32__
-D__CYGW
IN__ -Dunix -D__unix__ -D__unix -idirafter
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../
../../../include/w32api -idirafter
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../..
/i686-pc-cygwin/lib/../../include/w32api hello.c -quiet -dumpbase hello.c
-mtune=pentiumpro -auxbase hello-gdwarf-2 -g3 -version -o
/c/DOCUME~1/Angelo/IMPOST~1/Temp/ccqUrPqN.s
ignoring nonexistent directory
"/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/include"
ignoring duplicate directory
"/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/lib/../../include/w32api"
/usr/local/include
/usr/lib/gcc/i686-pc-cygwin/3.4.4/include
/usr/include
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api
End of search list.
GNU C version 3.4.4 (cygming special, gdc 0.12, using dmd
0.125) (i686-pc-cygwin
)
compiled by GNU C version 3.4.4 (cygming special, gdc 0.12, using
dmd 0.125).
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/bin/as.exe
-o /c/D
OCUME~1/Angelo/IMPOST~1/Temp/ccLc4MTM.o
/c/DOCUME~1/Angelo/IMPOST~1/Temp/ccqUrPq
N.s
/usr/lib/gcc/i686-pc-cygwin/3.4.4/collect2.exe -Bdynamic
--dll-search-prefix=cy
g -o hello.exe /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../crt0.o
-L/usr/lib/gcc/
i686-pc-cygwin/3.4.4 -L/usr/lib/gcc/i686-pc-cygwin/3.4.4
-L/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../.. /c/DOCUME~1/Angelo/IMPOST~1/Temp/ccLc4MTM.o -lgcc
-lcygwin
-luser32 -lkernel32 -ladvapi32 -lshell32 -lgcc
Thanks.

And after all this, "gdb ./hello.exe" _still_ says that hello.c was
compiled with stabs debugging info?

If so, please post this information to the Cygwin mailing list and ask
for the experts there to comment on these two problems: (1) that "gcc -g"
produces a program for which GDB says that it find no debugging
symbols, and (2) that "gcc -gdwarf-2" produces a program for which GDB
says that it was compiled with stabs debugging format, not DWARF 2
debugging format. There are hints in what GCC displays which suggest
that perhaps DWARF 2 is not supported at all by the Cygwin port of
GCC.

(This sounds like a side issue for the original problem, but I think
we need to solve this first, before we continue debugging the crash.
DWARF 2 debug info is much more powerful than stabs, especially when
looking at function call stack backtraces, so I'd like to find a way
to build Emacs with DWARF 2 debug info. And, on top of that, the
strange behavior of GCC/GDB wrt debugging symbols is something that
might mean we misunderstand some important aspect of what is going
on.)
Angelo Graziosi
1970-01-01 00:00:00 UTC
Permalink
Post by Eli Zaretskii
What happens if you type "gdb ./temacs.exe", does it also say ``no
debugging symbols found''?
The result:
-----------------------------
$ gdb ./temacs.exe
GNU gdb 6.5.50.20060706-cvs (cygwin-special)
Copyright (C) 2006 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 "i686-pc-cygwin"...(no debugging symbols found)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
DISPLAY = :0.0
TERM = xterm
/tmp/emacs/.build/src/.gdbinit:1: Error in sourced command file: <===(?)
/tmp/emacs/src/.gdbinit:1089: Error in sourced command file: <===(?)
No struct type named Lisp_Symbol. <===(?)
(gdb) r
Starting program: /tmp/emacs/.build/src/temacs.exe -geometry 80x40+0+0
Loaded symbols for /c/WINDOWS/system32/ntdll.dll
Loaded symbols for /c/WINDOWS/system32/kernel32.dll
Loaded symbols for /usr/X11R6/bin/cygICE-6.dll
Loaded symbols for /usr/bin/cygwin1.dll
Loaded symbols for /c/WINDOWS/system32/advapi32.dll
Loaded symbols for /c/WINDOWS/system32/rpcrt4.dll
Loaded symbols for /usr/X11R6/bin/cygSM-6.dll
Loaded symbols for /usr/X11R6/bin/cygX11-6.dll
Loaded symbols for /usr/X11R6/bin/cygXaw3d-7.dll
Loaded symbols for /usr/X11R6/bin/cygXext-6.dll
Loaded symbols for /usr/X11R6/bin/cygXmu-6.dll
Loaded symbols for /usr/X11R6/bin/cygXt-6.dll
Loaded symbols for /usr/X11R6/bin/cygXpm-4.dll
Loaded symbols for /usr/bin/cygncurses-8.dll
Loaded symbols for /usr/bin/cygjpeg-62.dll
Loaded symbols for /usr/bin/cygpng12.dll
Loaded symbols for /usr/bin/cygz.dll
Loaded symbols for /usr/bin/cygtiff-5.dll
Loaded symbols for /usr/bin/cygungif-4.dll

[1]+ Stopped gdb ./temacs.exe

***@pcname /tmp/emacs/.build/src
$ fg
gdb ./temacs.exe
---Type <return> to continue, or q <return> to quit---

warning: NOD32 protected [MSAFD Tcpip [TCP/IP]]
warning: NOD32 protected [MSAFD Tcpip [UDP/IP]]
warning: NOD32 protected [MSAFD Tcpip [RAW/IP]]
warning: NOD32 protected [RSVP UDP Service Provider]
warning: NOD32 protected [RSVP TCP Service Provider]
---Type <return> to continue, or q <return> to quit---

-----------------------------



At this point it seems to hang and I must kill GDB.

But if I use "(gdb) start" then:
----------------------------------
...
DISPLAY = :0.0
TERM = xterm
/tmp/emacs/.build/src/.gdbinit:1: Error in sourced command file:
/tmp/emacs/src/.gdbinit:1089: Error in sourced command file:
No struct type named Lisp_Symbol.
(gdb) start
Breakpoint 1 at 0x2009f37b
Starting program: /tmp/emacs/.build/src/temacs.exe -geometry 80x40+0+0
...
Loaded symbols for /usr/bin/cygz.dll
Loaded symbols for /usr/bin/cygtiff-5.dll
Loaded symbols for /usr/bin/cygungif-4.dll

[1]+ Stopped gdb ./temacs.exe


$ fg
gdb ./temacs.exe
---Type <return> to continue, or q <return> to quit---

0x2009f37b in main ()
(gdb) bt
#0 0x2009f37b in main ()
(gdb)
----------------------------------


Angelo.
Angelo Graziosi
1970-01-01 00:00:00 UTC
Permalink
Post by Eli Zaretskii
Date: Sat, 23 Sep 2006 18:49:59 +0200 (MET DST)
Post by Eli Zaretskii
How about the following compilation command--does it also cause GDB to
complain about debugging symbols?
gcc -gdwarf-2 -g3 hello.c -o hello
NO! I does NOT!!!
Good!
(gdb) info source
Current source file is hello.c
Compilation directory is /tmp/
Located in /tmp/hello.c
Contains 7 lines.
Source language is c.
Compiled with stabs debugging format.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This doesn't look right: it should have told ``with DWARF 2 debugging
format''. That's what the -gdwarf-2 switch is about. I wonder what
the heck is going on here.
gcc -v -gdwarf-2 -g3 hello.c -o hello
and post here everything that is displayed by the compiler?
Following this thread http://cygwin.com/ml/cygwin/2006-06/msg00855.html, I
have added -ggdb with the following result:
--------------------------------------------
$ gcc -v -ggdb -gdwarf-2 -g3 hello.c -o hello
Reading specs from /usr/lib/gcc/i686-pc-cygwin/3.4.4/specs
Configured with: /usr/build/package/orig/test.new4/gcc-3.4.4-2/configure
--verbo
se --prefix=/usr --exec-prefix=/usr --sysconfdir=/etc --libdir=/usr/lib
--libexe
cdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
--enable-languag
es=c,ada,c++,d,f77,pascal,java,objc --enable-nls
--without-included-gettext --en
able-version-specific-runtime-libs --without-x --enable-libgcj
--disable-java-aw
t --with-system-zlib --enable-interpreter --disable-libgcj-debug
--enable-thread
s=posix --enable-java-gc=boehm --disable-win32-registry
--enable-sjlj-exceptions
--enable-hash-synchronization --enable-libstdcxx-debug
Thread model: posix
gcc version 3.4.4 (cygming special, gdc 0.12, using dmd 0.125)
/usr/lib/gcc/i686-pc-cygwin/3.4.4/cc1.exe -quiet -v -dD -D__CYGWIN32__
-D__CYGW
IN__ -Dunix -D__unix__ -D__unix -idirafter
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../
../../../include/w32api -idirafter
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../..
/i686-pc-cygwin/lib/../../include/w32api hello.c -quiet -dumpbase hello.c
-mtune
=pentiumpro -auxbase hello-ggdb -gdwarf-2 -g3 -version -o
/c/DOCUME~1/Angelo/IMP
OST~1/Temp/ccNuDw40.s
ignoring nonexistent directory
"/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i6
86-pc-cygwin/include"
ignoring duplicate directory
"/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686
-pc-cygwin/lib/../../include/w32api"
#include "..." search starts here:
#include <...> search starts here:
/usr/local/include
/usr/lib/gcc/i686-pc-cygwin/3.4.4/include
/usr/include
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api
End of search list.
GNU C version 3.4.4 (cygming special, gdc 0.12, using dmd
0.125) (i686-pc-cygwin
)
compiled by GNU C version 3.4.4 (cygming special, gdc 0.12, using
dmd 0.
125).
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/bin/as.exe
-o /c/D
OCUME~1/Angelo/IMPOST~1/Temp/ccGvKaO4.o
/c/DOCUME~1/Angelo/IMPOST~1/Temp/ccNuDw4
0.s
/usr/lib/gcc/i686-pc-cygwin/3.4.4/collect2.exe -Bdynamic
--dll-search-prefix=cy
g -o hello.exe /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../crt0.o
-L/usr/lib/gcc/
i686-pc-cygwin/3.4.4 -L/usr/lib/gcc/i686-pc-cygwin/3.4.4
-L/usr/lib/gcc/i686-pc-
cygwin/3.4.4/../../.. /c/DOCUME~1/Angelo/IMPOST~1/Temp/ccGvKaO4.o -lgcc
-lcygwin
-luser32 -lkernel32 -ladvapi32 -lshell32 -lgcc



$ gdb ./hello.exe
GNU gdb 6.5.50.20060706-cvs (cygwin-special)
Copyright (C) 2006 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 "i686-pc-cygwin"...
(gdb) start
Breakpoint 1 at 0x401075: file hello.c, line 4.
Starting program: /tmp/hello.exe
Loaded symbols for /c/WINDOWS/system32/ntdll.dll
Loaded symbols for /c/WINDOWS/system32/kernel32.dll
Loaded symbols for /usr/bin/cygwin1.dll
Loaded symbols for /c/WINDOWS/system32/advapi32.dll
Loaded symbols for /c/WINDOWS/system32/rpcrt4.dll
main () at hello.c:4
4 {
(gdb) info source
Current source file is hello.c
Compilation directory is /tmp
Located in /tmp/hello.c
Contains 7 lines.
Source language is c.
Compiled with DWARF 2 debugging format.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Includes preprocessor macro info.
(gdb)
--------------------------------------------

Now it says 'Compiled with DWARF 2 debugging format.' !!!


Cheers,
Angelo.
Eli Zaretskii
2006-09-25 03:26:01 UTC
Permalink
Date: Mon, 25 Sep 2006 00:46:08 +0200 (MET DST)
Following this thread http://cygwin.com/ml/cygwin/2006-06/msg00855.html, I
Good! Although -gdwarf-2 _should_ have produced the same effect.
$ gcc -v -ggdb -gdwarf-2 -g3 hello.c -o hello
Do you get the same effect with the following command?

gcc -v -ggdb -g3 hello.c -o hello

In any case, please reconfigure Emacs to use the switches that produce
DWARF 2 debug info, and rebuild Emacs. The file INSTALL tells how to
do that (search for "CFLAGS"). Note that you will need to use these
switches both in CFLAGS and in LDFLAGS.
Angelo Graziosi
1970-01-01 00:00:00 UTC
Permalink
Post by Eli Zaretskii
Date: Mon, 25 Sep 2006 00:46:08 +0200 (MET DST)
Following this thread http://cygwin.com/ml/cygwin/2006-06/msg00855.html, I
Good! Although -gdwarf-2 _should_ have produced the same effect.
$ gcc -v -ggdb -gdwarf-2 -g3 hello.c -o hello
Do you get the same effect with the following command?
gcc -v -ggdb -g3 hello.c -o hello
NO ! It says "Compiled with stabs debugging format."
Post by Eli Zaretskii
In any case, please reconfigure Emacs to use the switches that produce
DWARF 2 debug info, and rebuild Emacs. The file INSTALL tells how to
do that (search for "CFLAGS"). Note that you will need to use these
switches both in CFLAGS and in LDFLAGS.
DONE! with the following result.



I have adapted the build script:
------------------------------------------------
...

base_dir="${PWD_DIR}"
source_dir="${base_dir}/emacs"
build_dir="${source_dir}/.build"
dest_dir="${source_dir}/.inst"

prefix_dir_name="usr/local/emacs-${rel}"
prefix_dir="/${prefix_dir_name}"

cd ${base_dir}
# echo ""
# echo "Unpacking the source..."
# tar -xjf ${PKG_DIR}/emacs-${rel}-cvs-src.tar.bz2

mkdir -p ${dest_dir} ${build_dir}

cd ${build_dir}

echo ""
echo "Configuring..."
LDFLAGS='-ggdb -gdwarf-2 -g3 -O2' \
CFLAGS='-ggdb -gdwarf-2 -g3 -O2' \
../configure --prefix=${prefix_dir}

echo ""
echo "Making the bootstrap..."
make bootstrap

make install prefix=${dest_dir}/${prefix_dir_name}

echo ""
echo "Making the binary package..."
cd ${dest_dir}

find ${prefix_dir_name} \! -type d | \ tar cjfT
${base_dir}/emacs-${rel}-cvs.tar.bz2 -
------------------------------------------------




The first thing to say is that there is an 'Abort' when 'make install...':
---------------------------------------------------------------------------
Compressing *.el ...
chmod -R a+r
/tmp/emacs/.inst/usr/local/emacs-22.0.50/share/emacs/22.0.50/leim
make[1]: Leaving directory `/tmp/emacs/.build/leim'
cd lib-src; make maybe-blessmail \
MAKE='make'
archlibdir='/tmp/emacs/.inst/usr/local/emacs-22.0.50/libexec/emacs/22.0.50/i686-pc-cygwin'
make[1]: Entering directory `/tmp/emacs/.build/lib-src'
../src/emacs -batch -l /tmp/emacs/lib-src/../lisp/mail/blessmail.el
Fatal error (6)make[1]: *** [blessmail] Aborted (core dumped)
make[1]: Leaving directory `/tmp/emacs/.build/lib-src'
make: *** [blessmail] Error 2

Making the binary package...
---------------------------------------------------------------------------




I have never got this until now, usually I have got:
-------------------------------------------------------
Compressing *.el ...
chmod -R a+r
/tmp/emacs/.inst/usr/local/emacs-22.0.50/share/emacs/22.0.50/leim
make[1]: Leaving directory `/tmp/emacs/.build/leim'
cd lib-src; make maybe-blessmail \
MAKE='make'
archlibdir='/tmp/emacs/.inst/usr/local/emacs-22.0.50/libexec/emacs/22.0.50/i686-pc-cygwin'
make[1]: Entering directory `/tmp/emacs/.build/lib-src'
../src/emacs -batch -l /tmp/emacs/lib-src/../lisp/mail/blessmail.el
Wrote /tmp/emacs/.build/lib-src/blessmail
chmod +x blessmail
Assuming /usr/spool/mail is really the mail spool directory, you should
run lib-src/blessmail
/tmp/emacs/.inst/usr/local/emacs-22.0.50/libexec/emacs/22.0.50/i686-pc-cygwin/movemail.exe
as root, to give movemail.exe appropriate permissions.
Do that after running make install.
make[1]: Leaving directory `/tmp/emacs/.build/lib-src'

Making the binary package...
-------------------------------------------------------




I have verifyed that now Emacs is 'Compiled with DWARF 2
debugging format.'

After the build was completed and the binary package result installed:
----------------------------------------------------------------------
cd /usr/local/emacs-22.0.50/bin
$ ./emacs
Fatal error (6)Aborted (core dumped)

$ cat emacs.exe.stackdump
Stack trace:
Frame Function Args
0022A8F8 7C802532 (00000594, 0000EA60, 000000A4, 0022A940)
0022AA18 61096A1C (00000000, 00000000, 00000000, 00000000)
0022AB08 6109459B (00000000, 0022AC30, 0022ABF8, 0022AAD0)
0022AB68 61094A7B (0022AB80, 00000000, 00000094, 200D3DA9)
0022AC28 61094C32 (00000D28, 00000006, 202D9801, 0022CE64)
0022AC48 61092068 (00000006, 60030000, 0022AD78, 61096ADC)
0022AD38 61017B80 (00000594, 0000EA60, 000000A4, 0022AD80)
0022AE58 61096ADC (00000000, 7C923E62, 00000208, 0022B23C)
0022AF48 6109459B (00000000, 0000021A, 00000000, 719DA6AF)
0022AFA8 61094A7B (0022AFC0, 00000000, 00000094, 0022B008)
0022B068 61094C32 (00000D28, 00000006, 0022B098, 2014D9D2)
0022B078 61092068 (00000000, 20690000, 218D0878, 202D0F20)
0022B098 2014D9D2 (206A0858, 218D0878, 00000E80, 0022B09C)
0022B0D8 2014E5C1 (FFFDD000, 00000000, 00000000, 00000000)
0022B148 2014CF2F (00003018, 0022B3A0, 0022B178, 2014D63D)
0022B158 200EFF1C (00003018, 00000000, 00000000, 71A116A3)
End of stack trace (more stack frames may be present)
----------------------------------------------------------------------




Then I tried this:
----------------------------------------------------------------------
$ gdb ./emacs
GNU gdb 6.5.50.20060706-cvs (cygwin-special)
Copyright (C) 2006 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 "i686-pc-cygwin"...
(gdb) r
Starting program: /usr/local/emacs-22.0.50/bin/emacs.exe
Loaded symbols for /c/WINDOWS/system32/ntdll.dll
Loaded symbols for /c/WINDOWS/system32/kernel32.dll
Loaded symbols for /usr/X11R6/bin/cygICE-6.dll
Loaded symbols for /usr/bin/cygwin1.dll
Loaded symbols for /c/WINDOWS/system32/advapi32.dll
Loaded symbols for /c/WINDOWS/system32/rpcrt4.dll
Loaded symbols for /usr/X11R6/bin/cygSM-6.dll
Loaded symbols for /usr/X11R6/bin/cygX11-6.dll
Loaded symbols for /usr/X11R6/bin/cygXaw3d-7.dll
Loaded symbols for /usr/X11R6/bin/cygXext-6.dll
Loaded symbols for /usr/X11R6/bin/cygXmu-6.dll
Loaded symbols for /usr/X11R6/bin/cygXt-6.dll
Loaded symbols for /usr/X11R6/bin/cygXpm-4.dll
Loaded symbols for /usr/bin/cygncurses-8.dll
Loaded symbols for /usr/bin/cygjpeg-62.dll
Loaded symbols for /usr/bin/cygpng12.dll
Loaded symbols for /usr/bin/cygz.dll
Loaded symbols for /usr/bin/cygtiff-5.dll
Loaded symbols for /usr/bin/cygungif-4.dll
warning: NOD32 protected [MSAFD Tcpip [TCP/IP]]
warning: NOD32 protected [MSAFD Tcpip [UDP/IP]]
warning: NOD32 protected [MSAFD Tcpip [RAW/IP]]
warning: NOD32 protected [RSVP UDP Service Provider]
warning: NOD32 protected [RSVP TCP Service Provider]

[1]+ Stopped gdb ./emacs


$ fg
gdb ./emacs
---Type <return> to continue, or q <return> to quit---

---------------------------------------------------------


after a few seconds:
----------------------------------------------------------
Program received signal SIGSEGV, Segmentation fault.
0x200f213c in mark_object (arg=1569454217) at /tmp/emacs/src/alloc.c:5509
5509 MARK_INTERVAL_TREE (ptr->intervals);
(gdb) bt
#0 0x200f213c in mark_object (arg=1569454217) at
/tmp/emacs/src/alloc.c:5509
#1 0x200f2a0f in Fgarbage_collect () at /tmp/emacs/src/alloc.c:5174
#2 0x201064f3 in Feval (form=570000829) at /tmp/emacs/src/eval.c:2216
#3 0x20105315 in internal_condition_case_1 (bfun=0x20106450 <Feval>,
arg=570000829, handlers=539914913,
hfun=0x200a4710 <menu_item_eval_property_1>) at
/tmp/emacs/src/eval.c:1525
#4 0x200a47a2 in menu_item_eval_property (sexpr=1569454217)
at /tmp/emacs/src/keyboard.c:7270
#5 0x200b0d4e in get_keyelt (object=540146505, autoload=1)
at /tmp/emacs/src/keymap.c:829
#6 0x200b13a3 in access_keymap (map=539846877, idx=539880097, t_ok=2,
noinherit=0, autoload=1) at /tmp/emacs/src/keymap.c:655
#7 0x200a5496 in tool_bar_items (reuse=536990456, nitems=0x22b658)
at /tmp/emacs/src/keyboard.c:7732
#8 0x2001d51f in update_tool_bar (f=0x20699600, save_match_data=0)
at /tmp/emacs/src/xdisp.c:9414
#9 0x2002bc8f in prepare_menu_bars () at /tmp/emacs/src/xdisp.c:9098
#10 0x2002c8ec in redisplay_internal (preserve_echo_area=1569454217)
at /tmp/emacs/src/xdisp.c:10935
#11 0x2002d057 in redisplay_preserve_echo_area (from_where=8)
at /tmp/emacs/src/xdisp.c:11541
#12 0x200a7aec in detect_input_pending_run_timers (do_display=1)
at /tmp/emacs/src/keyboard.c:10061
---Type <return> to continue, or q <return> to quit---
#13 0x2013a265 in wait_reading_process_output (time_limit=30, microsecs=0,
read_kbd=-1, do_display=1, wait_for_cell=539858945, wait_proc=0x0,
just_wait_proc=0) at /tmp/emacs/src/process.c:4665
#14 0x20009802 in sit_for (timeout=30, reading=1, do_display=1)
at /tmp/emacs/src/dispnew.c:6548
#15 0x200a9590 in read_char (commandflag=1, nmaps=2, maps=0x22c710,
prev_event=539858945, used_mouse_menu=0x22c758, end_time=0x0)
at /tmp/emacs/src/keyboard.c:2865
#16 0x200ab88d in read_key_sequence (keybuf=0x22c8b0, bufsize=30,
prompt=539858945, dont_downcase_last=0, can_return_switch_frame=1,
fix_current_buffer=1) at /tmp/emacs/src/keyboard.c:8956
#17 0x200ad3d1 in command_loop_1 () at /tmp/emacs/src/keyboard.c:1601
#18 0x2010554f in internal_condition_case (bfun=0x200ad220
<command_loop_1>,
handlers=539914913, hfun=0x200a6c80 <cmd_error>)
at /tmp/emacs/src/eval.c:1477
#19 0x200a0a8e in command_loop_2 () at /tmp/emacs/src/keyboard.c:1326
#20 0x2010520f in internal_catch (tag=1569454217,
func=0x200a0a60 <command_loop_2>, arg=539858945)
at /tmp/emacs/src/eval.c:1218
#21 0x200a08a3 in command_loop () at /tmp/emacs/src/keyboard.c:1305
#22 0x200a0944 in recursive_edit_1 () at /tmp/emacs/src/keyboard.c:1003
#23 0x200a0a20 in Frecursive_edit () at /tmp/emacs/src/keyboard.c:1064
#24 0x2009fd9d in main (argc=1, argv=0x202ce8c0) at
/tmp/emacs/src/emacs.c:1794
(gdb)
----------------------------------------------------------------------




Then I have retried using 'r -Q':
---------------------------------------------------------------------
$ gdb ./emacs
GNU gdb 6.5.50.20060706-cvs (cygwin-special)
Copyright (C) 2006 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 "i686-pc-cygwin"...
(gdb) r -Q
Starting program: /usr/local/emacs-22.0.50/bin/emacs.exe -Q
Loaded symbols for /c/WINDOWS/system32/ntdll.dll
Loaded symbols for /c/WINDOWS/system32/kernel32.dll
Loaded symbols for /usr/X11R6/bin/cygICE-6.dll
Loaded symbols for /usr/bin/cygwin1.dll
Loaded symbols for /c/WINDOWS/system32/advapi32.dll
Loaded symbols for /c/WINDOWS/system32/rpcrt4.dll
Loaded symbols for /usr/X11R6/bin/cygSM-6.dll
Loaded symbols for /usr/X11R6/bin/cygX11-6.dll
Loaded symbols for /usr/X11R6/bin/cygXaw3d-7.dll
Loaded symbols for /usr/X11R6/bin/cygXext-6.dll
Loaded symbols for /usr/X11R6/bin/cygXmu-6.dll
Loaded symbols for /usr/X11R6/bin/cygXt-6.dll
Loaded symbols for /usr/X11R6/bin/cygXpm-4.dll
Loaded symbols for /usr/bin/cygncurses-8.dll
Loaded symbols for /usr/bin/cygjpeg-62.dll
Loaded symbols for /usr/bin/cygpng12.dll
Loaded symbols for /usr/bin/cygz.dll
Loaded symbols for /usr/bin/cygtiff-5.dll
Loaded symbols for /usr/bin/cygungif-4.dll
warning: NOD32 protected [MSAFD Tcpip [TCP/IP]]
warning: NOD32 protected [MSAFD Tcpip [UDP/IP]]
warning: NOD32 protected [MSAFD Tcpip [RAW/IP]]
warning: NOD32 protected [RSVP UDP Service Provider]
warning: NOD32 protected [RSVP TCP Service Provider]

[1]+ Stopped gdb ./emacs

$ fg
gdb ./emacs
---Type <return> to continue, or q <return> to quit---

-------------------------------------------------------------



At this point, after 'return', I have waited more than 20 minutes!!! then
I have loaded some files and used 'M-x compile', and in a few secs:
----------------------------------------------------------------------
Program received signal SIGSEGV, Segmentation fault.
0x200f213c in mark_object (arg=1569454217) at /tmp/emacs/src/alloc.c:5509
5509 MARK_INTERVAL_TREE (ptr->intervals);
(gdb) bt
#0 0x200f213c in mark_object (arg=1569454217) at
/tmp/emacs/src/alloc.c:5509
#1 0x200f2a0f in Fgarbage_collect () at /tmp/emacs/src/alloc.c:5174
#2 0x201064f3 in Feval (form=569215053) at /tmp/emacs/src/eval.c:2216
#3 0x20105315 in
internal_condition_case_1 (bfun=0x20106450 <Feval>,
arg=569215053, handlers=539914913,
hfun=0x200a4710 <menu_item_eval_property_1>) at
/tmp/emacs/src/eval.c:1525
#4 0x200a47a2 in menu_item_eval_property (sexpr=1569454217)
at /tmp/emacs/src/keyboard.c:7270
#5 0x200b0d4e in get_keyelt (object=540146505, autoload=1)
at /tmp/emacs/src/keymap.c:829
#6 0x200b13a3 in access_keymap (map=539846877, idx=539880097, t_ok=2,
noinherit=0, autoload=1) at /tmp/emacs/src/keymap.c:655
#7 0x200a5496 in tool_bar_items (reuse=536990456, nitems=0x22b648)
at /tmp/emacs/src/keyboard.c:7732
#8 0x2001d51f in update_tool_bar (f=0x20699600, save_match_data=0)
at /tmp/emacs/src/xdisp.c:9414
#9 0x2002bc8f in prepare_menu_bars () at /tmp/emacs/src/xdisp.c:9098
#10 0x2002c8ec in redisplay_internal (preserve_echo_area=1569454217)
at /tmp/emacs/src/xdisp.c:10935
#11 0x2002d057 in redisplay_preserve_echo_area (from_where=8)
at /tmp/emacs/src/xdisp.c:11541
#12 0x200a7aec in detect_input_pending_run_timers (do_display=1)
at /tmp/emacs/src/keyboard.c:10061
---Type <return> to continue, or q <return> to quit---
#13 0x2013a265 in wait_reading_process_output (time_limit=30, microsecs=0,
read_kbd=-1, do_display=1, wait_for_cell=539858945, wait_proc=0x0,
just_wait_proc=0) at /tmp/emacs/src/process.c:4665
#14 0x20009802 in sit_for (timeout=30, reading=1, do_display=1)
at /tmp/emacs/src/dispnew.c:6548
#15 0x200a9590 in read_char (commandflag=1, nmaps=2, maps=0x22c700,
prev_event=539858945, used_mouse_menu=0x22c748, end_time=0x0)
at /tmp/emacs/src/keyboard.c:2865
#16 0x200ab88d in read_key_sequence (keybuf=0x22c8a0, bufsize=30,
prompt=539858945, dont_downcase_last=0, can_return_switch_frame=1,
fix_current_buffer=1) at /tmp/emacs/src/keyboard.c:8956
#17 0x200ad3d1 in command_loop_1 () at /tmp/emacs/src/keyboard.c:1601
#18 0x2010554f in internal_condition_case (bfun=0x200ad220
<command_loop_1>,
handlers=539914913, hfun=0x200a6c80 <cmd_error>)
at /tmp/emacs/src/eval.c:1477
#19 0x200a0a8e in command_loop_2 () at /tmp/emacs/src/keyboard.c:1326
#20 0x2010520f in internal_catch (tag=1569454217,
func=0x200a0a60 <command_loop_2>, arg=539858945)
at /tmp/emacs/src/eval.c:1218
#21 0x200a08a3 in command_loop () at /tmp/emacs/src/keyboard.c:1305
#22 0x200a0944 in recursive_edit_1 () at /tmp/emacs/src/keyboard.c:1003
#23 0x200a0a20 in Frecursive_edit () at /tmp/emacs/src/keyboard.c:1064
#24 0x2009fd9d in main (argc=2, argv=0x202ce8c0) at
/tmp/emacs/src/emacs.c:1794
(gdb)
---------------------------------------------------------------------



Angelo.
Eli Zaretskii
2006-09-25 19:57:47 UTC
Permalink
Date: Mon, 25 Sep 2006 14:56:59 +0200 (MET DST)
Post by Eli Zaretskii
Good! Although -gdwarf-2 _should_ have produced the same effect.
Post by Angelo Graziosi
$ gcc -v -ggdb -gdwarf-2 -g3 hello.c -o hello
Do you get the same effect with the following command?
gcc -v -ggdb -g3 hello.c -o hello
NO ! It says "Compiled with stabs debugging format."
Weird... but anyway, at least you have now a way to produce an Emacs
with DWARF 2 debug info.
Program received signal SIGSEGV, Segmentation fault.
0x200f213c in mark_object (arg=1569454217) at /tmp/emacs/src/alloc.c:5509
5509 MARK_INTERVAL_TREE (ptr->intervals);
(gdb) bt
#0 0x200f213c in mark_object (arg=1569454217) at
/tmp/emacs/src/alloc.c:5509
#1 0x200f2a0f in Fgarbage_collect () at /tmp/emacs/src/alloc.c:5174
It dies in garbage collection. Can you try debugging this using the
techniques described in etc/DEBUG (search for "GC")?

Failing that, the only idea I have is to try and find the CVS commit
that causes the crashes. I think you said that CVS of Sep 4 did
build; if that is true, you should be able to find the offending set
of changes by successive bisections of the time period since then.
The -D switch to CVS will allow you to check-out the tree that was
current on a certain date. It's almost certain that the problem was
caused by some change in the src directory, so you could consider only
the changes in src, at least initially.

One other idea is to try "emacs -nw", to see if the crashes are
somehow related to the graphics display. Maybe the results will give
some ideas, I don't know.

Thanks again for working on this.
Kim F. Storm
2006-09-25 20:42:53 UTC
Permalink
Post by Angelo Graziosi
gdb ./emacs
----------------------------------------------------------
#0 0x200f213c in mark_object (arg=1569454217) at /tmp/emacs/src/alloc.c:5509
#1 0x200f2a0f in Fgarbage_collect () at /tmp/emacs/src/alloc.c:5174
#2 0x201064f3 in Feval (form=570000829) at /tmp/emacs/src/eval.c:2216
#3 0x20105315 in internal_condition_case_1 (bfun=0x20106450 <Feval>,
arg=570000829, handlers=539914913,
hfun=0x200a4710 <menu_item_eval_property_1>) at
/tmp/emacs/src/eval.c:1525
#4 0x200a47a2 in menu_item_eval_property (sexpr=1569454217)
at /tmp/emacs/src/keyboard.c:7270
#5 0x200b0d4e in get_keyelt (object=540146505, autoload=1)
at /tmp/emacs/src/keymap.c:829
#6 0x200b13a3 in access_keymap (map=539846877, idx=539880097, t_ok=2,
noinherit=0, autoload=1) at /tmp/emacs/src/keymap.c:655
#7 0x200a5496 in tool_bar_items (reuse=536990456, nitems=0x22b658)
at /tmp/emacs/src/keyboard.c:7732
#8 0x2001d51f in update_tool_bar (f=0x20699600, save_match_data=0)
at /tmp/emacs/src/xdisp.c:9414
#9 0x2002bc8f in prepare_menu_bars () at /tmp/emacs/src/xdisp.c:9098
At this point, after 'return', I have waited more than 20 minutes!!! then
So might be something that you load ...
Post by Angelo Graziosi
----------------------------------------------------------------------
#0 0x200f213c in mark_object (arg=1569454217) at /tmp/emacs/src/alloc.c:5509
#1 0x200f2a0f in Fgarbage_collect () at /tmp/emacs/src/alloc.c:5174
#2 0x201064f3 in Feval (form=569215053) at /tmp/emacs/src/eval.c:2216
#3 0x20105315 in
internal_condition_case_1 (bfun=0x20106450 <Feval>,
arg=569215053, handlers=539914913,
hfun=0x200a4710 <menu_item_eval_property_1>) at
/tmp/emacs/src/eval.c:1525
#4 0x200a47a2 in menu_item_eval_property (sexpr=1569454217)
at /tmp/emacs/src/keyboard.c:7270
#5 0x200b0d4e in get_keyelt (object=540146505, autoload=1)
at /tmp/emacs/src/keymap.c:829
#6 0x200b13a3 in access_keymap (map=539846877, idx=539880097, t_ok=2,
noinherit=0, autoload=1) at /tmp/emacs/src/keymap.c:655
#7 0x200a5496 in tool_bar_items (reuse=536990456, nitems=0x22b648)
at /tmp/emacs/src/keyboard.c:7732
#8 0x2001d51f in update_tool_bar (f=0x20699600, save_match_data=0)
at /tmp/emacs/src/xdisp.c:9414
#9 0x2002bc8f in prepare_menu_bars () at /tmp/emacs/src/xdisp.c:9098
The strange thing here is that the crash happens in the same context both times,
that it is the same sexpr which is being evalled when it happens, _and_ it is
that very same object (sexpr) which is being marked in both cases.

So we need to track down what that object is and where it came from.

Can you try to debug that using the following gdb commands:

p arg
xpr

(and if possible, expand on the value depending on what type of object it is).



Also, can you try to disable the tool-bar and see if the problem still happens.
--
Kim F. Storm <***@cua.dk> http://www.cua.dk
Angelo Graziosi
1970-01-01 00:00:00 UTC
Permalink
Eli, Kim,

I would be very happy to follow the indications you give me, but, as I
wrote, I am not very familiar with GDB so it is very hard for me to follow
deeply your suggestions.
Post by Eli Zaretskii
Post by Angelo Graziosi
Program received signal SIGSEGV, Segmentation fault.
0x200f213c in mark_object (arg=1569454217) at /tmp/emacs/src/alloc.c:5509
5509 MARK_INTERVAL_TREE (ptr->intervals);
(gdb) bt
#0 0x200f213c in mark_object (arg=1569454217) at
/tmp/emacs/src/alloc.c:5509
#1 0x200f2a0f in Fgarbage_collect () at /tmp/emacs/src/alloc.c:5174
It dies in garbage collection. Can you try debugging this using the
techniques described in etc/DEBUG (search for "GC")?
See above!
Post by Eli Zaretskii
Failing that, the only idea I have is to try and find the CVS commit
that causes the crashes. I think you said that CVS of Sep 4 did
build; if that is true, you should be able to find the offending set
of changes by successive bisections of the time period since then.
The -D switch to CVS will allow you to check-out the tree that was
current on a certain date. It's almost certain that the problem was
caused by some change in the src directory, so you could consider only
the changes in src, at least initially.
If I have well understood, I should use:


cvs -D20060901 -z3 \
-d:pserver:***@cvs.savannah.gnu.org:/cvsroot/emacs co -P emacs

to download the CVS source of Sep 01. If the build works, I should try
with Sep 10, for example; if it does not work I should try Sep 05 and so
on...
Post by Eli Zaretskii
One other idea is to try "emacs -nw", to see if the crashes are
somehow related to the graphics display. Maybe the results will give
some ideas, I don't know.
If I run './emacs -nw' in the directory where the exe was made
(/tmp/emacs/.build/src) and from bash-Cygwin.bat, I have

$ ./emacs.exe -nw
Fatal error (6)Aborted (core dumped)

but in the same window+dir:
---------------------------------------
$ gdb ./emacs.exe
GNU gdb 6.5.50.20060706-cvs (cygwin-special)
Copyright (C) 2006 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 "i686-pc-cygwin"...
Environment variable "DISPLAY" not defined.
TERM = cygwin
Breakpoint 1 at 0x2009e476: file /tmp/emacs/src/emacs.c, line 464.
Breakpoint 2 at 0x200b7e09: file /tmp/emacs/src/sysdep.c, line 1395.
(gdb) r
---------------------------------------



it starts and does not seem to have problem. Typing C-x C-c the minibufer
says 'C-x C-g undefined' ? I can quit using F-10-File-Exit-Emacs.


If I start './emacs &' fro that directory (/tmp/emacs/.build/src) and from
an X-window (urxvt) it hangs and I must kill it to reuse the window.
The same using gdb.

The previous reports regarded emacs started from the installation
directory (/usr/local/emacs-22.0.50/bin).
Post by Eli Zaretskii
p arg
xpr
(and if possible, expand on the value depending on what type of object
it is).
See the head of this replay.
Post by Eli Zaretskii
Also, can you try to disable the tool-bar and see if the problem still
happens.
Now comes something interesting. If you mean

'Options - (Show)/Hide - toolbar'

Emacs, './emacs &', from the build dir /tmp/emacs/.build/src, from X
(urxvt), after "Options - (Show)/Hide - toolbar" is still running (it is
about 1 hour).




Thanks for the suggestions,

Angelo.
Eli Zaretskii
2006-09-26 03:22:29 UTC
Permalink
Date: Tue, 26 Sep 2006 02:06:17 +0200 (MET DST)
I would be very happy to follow the indications you give me, but, as I
wrote, I am not very familiar with GDB so it is very hard for me to follow
deeply your suggestions.
Well, Kim just asked you to type 2 GDB commands, one after the other.
That shouldn't be hard to follow, and might just give us enough clues
to find the culprit.

For those two commands to work, you need to start GDB from the Emacs
src directory, so that GDB reads the .gdbinit file there.
cvs -D20060901 -z3 \
to download the CVS source of Sep 01. If the build works, I should try
with Sep 10, for example; if it does not work I should try Sep 05 and so
on...
Yes.
Angelo Graziosi
1970-01-01 00:00:00 UTC
Permalink
Post by Eli Zaretskii
Well, Kim just asked you to type 2 GDB commands, one after the other.
That shouldn't be hard to follow, and might just give us enough clues
to find the culprit.
Obviously, I will do everything I can.
Post by Eli Zaretskii
For those two commands to work, you need to start GDB from the Emacs
src directory, so that GDB reads the .gdbinit file there.
As I have written in the last replay, I cannot run Emacs from that
directory:
-------------------------------------------------------------------
cd /tmp/emacs/.build/src
$ gdb ./emacs
GNU gdb 6.5.50.20060706-cvs (cygwin-special)
Copyright (C) 2006 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 "i686-pc-cygwin"...
DISPLAY = :0.0
TERM = xterm
Breakpoint 1 at 0x2009e476: file /tmp/emacs/src/emacs.c, line 464.
Breakpoint 2 at 0x200b7e89: file /tmp/emacs/src/sysdep.c, line 1395.
(gdb)
(gdb) r -Q
Starting program: /tmp/emacs/.build/src/emacs.exe -Q
Loaded symbols for /c/WINDOWS/system32/ntdll.dll
Loaded symbols for /c/WINDOWS/system32/kernel32.dll
Loaded symbols for /usr/X11R6/bin/cygICE-6.dll
Loaded symbols for /usr/bin/cygwin1.dll
Loaded symbols for /c/WINDOWS/system32/advapi32.dll
Loaded symbols for /c/WINDOWS/system32/rpcrt4.dll
Loaded symbols for /usr/X11R6/bin/cygSM-6.dll
Loaded symbols for /usr/X11R6/bin/cygX11-6.dll
Loaded symbols for /usr/X11R6/bin/cygXaw3d-7.dll
Loaded symbols for /usr/X11R6/bin/cygXext-6.dll
Loaded symbols for /usr/X11R6/bin/cygXmu-6.dll
Loaded symbols for /usr/X11R6/bin/cygXt-6.dll
Loaded symbols for /usr/X11R6/bin/cygXpm-4.dll
Loaded symbols for /usr/bin/cygncurses-8.dll
Loaded symbols for /usr/bin/cygjpeg-62.dll
Loaded symbols for /usr/bin/cygpng12.dll
Loaded symbols for /usr/bin/cygz.dll
Loaded symbols for /usr/bin/cygtiff-5.dll
Loaded symbols for /usr/bin/cygungif-4.dll
warning: NOD32 protected [MSAFD Tcpip [TCP/IP]]
warning: NOD32 protected [MSAFD Tcpip [UDP/IP]]
warning: NOD32 protected [MSAFD Tcpip [RAW/IP]]
warning: NOD32 protected [RSVP UDP Service Provider]
warning: NOD32 protected [RSVP TCP Service Provider]
-------------------------------------------------------------------




At this point it hangs, Emacs does not appear, the urxvt window does not
answer (for example, the scroll does not work) : I can only kill GDB (ps -
kill...)

After killed in that window appears:
-------------------------------------------------------------------
Program received signal SIGSEGV, Segmentation fault.
[Switching to thread 2148.0xb90]
---Type <return> to continue, or q <return> to quit---


$ <==== PROMPT =========
-------------------------------------------------------------------



If I install Emacs in the prefix directory, I can start Emacs as described
yesterday.
Post by Eli Zaretskii
p arg
xpr
I have tried:
------------------------------------------------------------
cd /usr/local/emacs-22.0.50/bin
$ gdb ./emacs
GNU gdb 6.5.50.20060706-cvs (cygwin-special)
Copyright (C) 2006 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 "i686-pc-cygwin"...
(gdb) r
Starting program: /usr/local/emacs-22.0.50/bin/emacs.exe
Loaded symbols for /c/WINDOWS/system32/ntdll.dll
Loaded symbols for /c/WINDOWS/system32/kernel32.dll
Loaded symbols for /usr/X11R6/bin/cygICE-6.dll
Loaded symbols for /usr/bin/cygwin1.dll
Loaded symbols for /c/WINDOWS/system32/advapi32.dll
Loaded symbols for /c/WINDOWS/system32/rpcrt4.dll
Loaded symbols for /usr/X11R6/bin/cygSM-6.dll
Loaded symbols for /usr/X11R6/bin/cygX11-6.dll
Loaded symbols for /usr/X11R6/bin/cygXaw3d-7.dll
Loaded symbols for /usr/X11R6/bin/cygXext-6.dll
Loaded symbols for /usr/X11R6/bin/cygXmu-6.dll
Loaded symbols for /usr/X11R6/bin/cygXt-6.dll
Loaded symbols for /usr/X11R6/bin/cygXpm-4.dll
Loaded symbols for /usr/bin/cygncurses-8.dll
Loaded symbols for /usr/bin/cygjpeg-62.dll
Loaded symbols for /usr/bin/cygpng12.dll
Loaded symbols for /usr/bin/cygz.dll
Loaded symbols for /usr/bin/cygtiff-5.dll
Loaded symbols for /usr/bin/cygungif-4.dll
warning: NOD32 protected [MSAFD Tcpip [TCP/IP]]
warning: NOD32 protected [MSAFD Tcpip [UDP/IP]]
warning: NOD32 protected [MSAFD Tcpip [RAW/IP]]
warning: NOD32 protected [RSVP UDP Service Provider]
warning: NOD32 protected [RSVP TCP Service Provider]

[1]+ Stopped gdb ./emacs

***@homepc /usr/local/emacs-22.0.50/bin
$ fg
gdb ./emacs
---Type <return> to continue, or q <return> to quit---


Program received signal SIGSEGV, Segmentation fault.
0x200f213c in mark_object (arg=1569454217) at /tmp/emacs/src/alloc.c:5509
5509 MARK_INTERVAL_TREE (ptr->intervals);
(gdb) p arg
$1 = 1569454217
(gdb) xpr
Undefined command: "xpr". Try "help"
------------------------------------------------------------

Perhaps xpr is a mis-typed command, I have also tried with 'sexpr',
'expr', 'ptr' but with the same result.
Post by Eli Zaretskii
Also, can you try to disable the tool-bar and see if the problem still
happens.
when I start Emacs as I do normally, i.e. after installed in prefix,

$ emacs-cvs &

(where emacs-cvs is a link in /usr/local/bin to
/usr/local/emacs-22.0.50/bin/emacs.exe)

and soon I hide the tool-bar (Options-Show/Hide), then I can work with it
for hours without problem, with more than 20 buffers loaded, using M-x
compile, C-s (search), M-% (search and replace)....while building e new
Emacs-CVS, running other C/C++/Fortran programs etc.




Angelo.
Eli Zaretskii
2006-09-26 20:10:23 UTC
Permalink
Date: Tue, 26 Sep 2006 14:48:40 +0200 (MET DST)
Post by Eli Zaretskii
For those two commands to work, you need to start GDB from the Emacs
src directory, so that GDB reads the .gdbinit file there.
As I have written in the last replay, I cannot run Emacs from that
Sorry, I forgot.

It is strange that changing a directory has this effect, but here are
a few possibilities to work around the problem. All of the following
possibilities assume you start from the `src' directory:

1) gdb ./emacs.exe

2) gdb /usr/local/emacs-22.0.50/bin/emacs.exe

3) cd /usr/local/emacs-22.0.50/bin
gdb ./emacs.exe
(gdb) source /tmp/emacs/.build/src/.gdbinit

If none of the above helps get rid of the hang, try to edit the file
src/.gdbinit so that it is left only with definitions of commands
(each definition is a block that starts with "define" and ends with
"end") and their documentation (blocks that start with "document"),
and remove everything else.
(gdb) xpr
Undefined command: "xpr". Try "help"
------------------------------------------------------------
Perhaps xpr is a mis-typed command
No, it's a command defined in src/.gdbinit. If you don't start GDB
from the src directory and don't "source" that file from within GDB,
this command will be unknown to GDB.
Post by Eli Zaretskii
Also, can you try to disable the tool-bar and see if the problem still
happens.
when I start Emacs as I do normally, i.e. after installed in prefix,
$ emacs-cvs &
(where emacs-cvs is a link in /usr/local/bin to
/usr/local/emacs-22.0.50/bin/emacs.exe)
and soon I hide the tool-bar (Options-Show/Hide), then I can work with it
for hours without problem, with more than 20 buffers loaded, using M-x
compile, C-s (search), M-% (search and replace)....while building e new
Emacs-CVS, running other C/C++/Fortran programs etc.
Interesting. So without the tool bar it never crashes, no matter how
long you leave it?
Angelo Graziosi
1970-01-01 00:00:00 UTC
Permalink
Post by Eli Zaretskii
It is strange that changing a directory has this effect, but here are
a few possibilities to work around the problem. All of the following
1) gdb ./emacs.exe
2) gdb /usr/local/emacs-22.0.50/bin/emacs.exe
3) cd /usr/local/emacs-22.0.50/bin
gdb ./emacs.exe
(gdb) source /tmp/emacs/.build/src/.gdbinit
If none of the above helps get rid of the hang, try to edit the file
src/.gdbinit so that it is left only with definitions of commands
(each definition is a block that starts with "define" and ends with
"end") and their documentation (blocks that start with "document"),
and remove everything else.
I will try your suggestions.

In any case there are other strange things.

This morning (20060926 about 10:00 am) I have downloaded a new CVS source
of Emacs and have made e new build using the debug options we discussed
(CFLAGS='-ggdb -gdwarf-2 -g3 -O2'). Then I have installed
(prefix=/usr/local/emacs-22.0.50) it.

Obviously it does not work in the build dir but I can start it as usually
with an adeguate link

$ emacs-cvs &

(/usr/local/bin/emacs-cvs -> /usr/local/emacs-22.0.50/bin/emacs.exe)

I have worked with it without problem, also with tool-bar On! I haven't
observed any crash.

Seeing this i decided to make a new build without debug options
(CFLAGS='-O2')...installed etc... :

$ emacs-cvs &

works only if 'cd /usr/local'. If it is given in any other directory Emacs
core dumps!
Post by Eli Zaretskii
Interesting. So without the tool bar it never crashes, no matter how
long you leave it?
All the time (hours) I worked with it I haven't seen any crash.


Angelo.
Eli Zaretskii
2006-09-27 03:35:10 UTC
Permalink
Date: Wed, 27 Sep 2006 00:18:29 +0200 (MET DST)
In any case there are other strange things.
This morning (20060926 about 10:00 am) I have downloaded a new CVS source
of Emacs and have made e new build using the debug options we discussed
(CFLAGS='-ggdb -gdwarf-2 -g3 -O2'). Then I have installed
(prefix=/usr/local/emacs-22.0.50) it.
Obviously it does not work in the build dir but I can start it as usually
with an adeguate link
$ emacs-cvs &
(/usr/local/bin/emacs-cvs -> /usr/local/emacs-22.0.50/bin/emacs.exe)
I have worked with it without problem, also with tool-bar On! I haven't
observed any crash.
Seeing this i decided to make a new build without debug options
$ emacs-cvs &
works only if 'cd /usr/local'. If it is given in any other directory Emacs
core dumps!
It sounds like memory corruption of some kind. They frequently
exhibit such strange patterns. Until we resolve this, I'd suggest not
to rebuild the latest version, so that the bug doesn't move too much.
Angelo Graziosi
1970-01-01 00:00:00 UTC
Permalink
Post by Eli Zaretskii
It is strange that changing a directory has this effect, but here are
a few possibilities to work around the problem. All of the following
1) gdb ./emacs.exe
2) gdb /usr/local/emacs-22.0.50/bin/emacs.exe
3) cd /usr/local/emacs-22.0.50/bin
gdb ./emacs.exe
(gdb) source /tmp/emacs/.build/src/.gdbinit
It is .gdbinit that causes the problem. I have tried 1)...3) but only if I
rename .gdbinit (for example save.gdbinit) I can run Emacs from GDB
whatever is the directory.
Post by Eli Zaretskii
If none of the above helps get rid of the hang, try to edit the file
src/.gdbinit so that it is left only with definitions of commands
(each definition is a block that starts with "define" and ends with
"end") and their documentation (blocks that start with "document"),
and remove everything else.
I will try.


Angelo.
Eli Zaretskii
2006-09-27 18:22:44 UTC
Permalink
Date: Wed, 27 Sep 2006 18:52:58 +0200 (MET DST)
It is .gdbinit that causes the problem. I have tried 1)...3) but only if I
rename .gdbinit (for example save.gdbinit) I can run Emacs from GDB
whatever is the directory.
Post by Eli Zaretskii
If none of the above helps get rid of the hang, try to edit the file
src/.gdbinit so that it is left only with definitions of commands
(each definition is a block that starts with "define" and ends with
"end") and their documentation (blocks that start with "document"),
and remove everything else.
I will try.
And if that doesn't help either, please try to find what part in
.gdbinit causes the problem (e.g., by deleting parts of it and trying
to run Emacs under GDB).
Angelo Graziosi
1970-01-01 00:00:00 UTC
Permalink
Post by Eli Zaretskii
If none of the above helps get rid of the hang, try to edit the file
src/.gdbinit so that it is left only with definitions of commands
(each definition is a block that starts with "define" and ends with
"end") and their documentation (blocks that start with "document"),
and remove everything else.
Done!

This is the result:
------------------------------------------------------------------
cd /tmp/emacs/.build/src

$ gdb ./emacs.exe
GNU gdb 6.5.50.20060706-cvs (cygwin-special)
Copyright (C) 2006 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 "i686-pc-cygwin"...
(gdb) r
Starting program: /tmp/emacs/.build/src/emacs.exe
Loaded symbols for /c/WINDOWS/system32/ntdll.dll
Loaded symbols for /c/WINDOWS/system32/kernel32.dll
Loaded symbols for /usr/X11R6/bin/cygICE-6.dll
Loaded symbols for /usr/bin/cygwin1.dll
Loaded symbols for /c/WINDOWS/system32/advapi32.dll
Loaded symbols for /c/WINDOWS/system32/rpcrt4.dll
Loaded symbols for /usr/X11R6/bin/cygSM-6.dll
Loaded symbols for /usr/X11R6/bin/cygX11-6.dll
Loaded symbols for /usr/X11R6/bin/cygXaw3d-7.dll
Loaded symbols for /usr/X11R6/bin/cygXext-6.dll
Loaded symbols for /usr/X11R6/bin/cygXmu-6.dll
Loaded symbols for /usr/X11R6/bin/cygXt-6.dll
Loaded symbols for /usr/X11R6/bin/cygXpm-4.dll
Loaded symbols for /usr/bin/cygncurses-8.dll
Loaded symbols for /usr/bin/cygjpeg-62.dll
Loaded symbols for /usr/bin/cygpng12.dll
Loaded symbols for /usr/bin/cygz.dll
Loaded symbols for /usr/bin/cygtiff-5.dll
Loaded symbols for /usr/bin/cygungif-4.dll
warning: NOD32 protected [MSAFD Tcpip [TCP/IP]]
warning: NOD32 protected [MSAFD Tcpip [UDP/IP]]
warning: NOD32 protected [MSAFD Tcpip [RAW/IP]]
warning: NOD32 protected [RSVP UDP Service Provider]
warning: NOD32 protected [RSVP TCP Service Provider]

[1]+ Stopped gdb ./emacs.exe


$ fg
gdb ./emacs.exe
---Type <return> to continue, or q <return> to quit---
----------------------------------------------------------------


after a few minutes
----------------------------------------------------------------
Program received signal SIGSEGV, Segmentation fault.
0x200f217c in mark_object (arg=1569454217) at /tmp/emacs/src/alloc.c:5509
5509 MARK_INTERVAL_TREE (ptr->intervals);
(gdb) bt
#0 0x200f217c in mark_object (arg=1569454217) at
/tmp/emacs/src/alloc.c:5509
#1 0x200f2a4f in Fgarbage_collect () at /tmp/emacs/src/alloc.c:5174
#2 0x20106533 in Feval (form=572762717) at /tmp/emacs/src/eval.c:2216
#3 0x20105355 in internal_condition_case_1 (bfun=0x20106490 <Feval>,
arg=572762717, handlers=539914913,
hfun=0x200a4710 <menu_item_eval_property_1>) at
/tmp/emacs/src/eval.c:1525
#4 0x200a47a2 in menu_item_eval_property (sexpr=1569454217)
at /tmp/emacs/src/keyboard.c:7270
#5 0x200b0d4e in get_keyelt (object=540146505, autoload=1)
at /tmp/emacs/src/keymap.c:829
#6 0x200b13a3 in access_keymap (map=539846877, idx=539880097, t_ok=2,
noinherit=0, autoload=1) at /tmp/emacs/src/keymap.c:655
#7 0x200a5496 in tool_bar_items (reuse=536990456, nitems=0x22b698)
at /tmp/emacs/src/keyboard.c:7732
#8 0x2001d51f in update_tool_bar (f=0x21933e00, save_match_data=0)
at /tmp/emacs/src/xdisp.c:9414
#9 0x2002bc8f in prepare_menu_bars () at /tmp/emacs/src/xdisp.c:9098
#10 0x2002c8ec in redisplay_internal (preserve_echo_area=1569454217)
at /tmp/emacs/src/xdisp.c:10935
#11 0x2002d08a in redisplay_preserve_echo_area (from_where=8)
at /tmp/emacs/src/xdisp.c:11545
#12 0x200a7aec in detect_input_pending_run_timers (do_display=1)
at /tmp/emacs/src/keyboard.c:10061
---Type <return> to continue, or q <return> to quit---
#13 0x2013a2a5 in wait_reading_process_output (time_limit=0, microsecs=0,
read_kbd=-1, do_display=1, wait_for_cell=539858945, wait_proc=0x0,
just_wait_proc=0) at /tmp/emacs/src/process.c:4665
#14 0x200a8e40 in read_char (commandflag=1, nmaps=2, maps=0x22c710,
prev_event=539858945, used_mouse_menu=0x22c758, end_time=0x0)
at /tmp/emacs/src/keyboard.c:3988
#15 0x200ab88d in read_key_sequence (keybuf=0x22c8b0, bufsize=30,
prompt=539858945, dont_downcase_last=0, can_return_switch_frame=1,
fix_current_buffer=1) at /tmp/emacs/src/keyboard.c:8956
#16 0x200ad3d1 in command_loop_1 () at /tmp/emacs/src/keyboard.c:1601
#17 0x2010558f in internal_condition_case (bfun=0x200ad220
<command_loop_1>,
handlers=539914913, hfun=0x200a6c80 <cmd_error>)
at /tmp/emacs/src/eval.c:1477
#18 0x200a0a8e in command_loop_2 () at /tmp/emacs/src/keyboard.c:1326
#19 0x2010524f in internal_catch (tag=1569454217,
func=0x200a0a60 <command_loop_2>, arg=539858945)
at /tmp/emacs/src/eval.c:1218
#20 0x200a08a3 in command_loop () at /tmp/emacs/src/keyboard.c:1305
#21 0x200a0944 in recursive_edit_1 () at /tmp/emacs/src/keyboard.c:1003
#22 0x200a0a20 in Frecursive_edit () at /tmp/emacs/src/keyboard.c:1064
#23 0x2009fd9d in main (argc=1, argv=0x202ce840) at
/tmp/emacs/src/emacs.c:1794

(gdb) p arg

$1 = 1569454217

(gdb) xpr

Lisp_Symbol
$2 = (struct Lisp_Symbol *) 0x7d8bf888
Cannot access memory at address 0x7d8bf88c
(gdb)
------------------------------------------------------------------



Angelo.
Angelo Graziosi
1970-01-01 00:00:00 UTC
Permalink
Post by Eli Zaretskii
And if that doesn't help either, please try to find what part in
.gdbinit causes the problem (e.g., by deleting parts of it and trying
to run Emacs under GDB).
I have tried with the following result.

The problem is localized between lines


1072 # People get bothered when...
..... .....

1110 end


I have subdivided them in three blocks:

A == (1072 - 1094)
B == (1095 - 1095)
C == (1096 - 1110)

The results are summarized by the following table:

A B C | Result

0 0 0 | H
0 0 1 | H
0 1 0 | H
0 1 1 | H
1 0 0 | H
1 0 1 | H
1 1 0 | E
1 1 1 | W

Where

'1' means that the lines of that block are short-circuited (with a '#'), '

'0' the line remains as in the original .gdbinit

'H' the result hangs, i.e.
-------------------------------------------------------
...
Loaded symbols for /usr/bin/cygtiff-5.dll
Loaded symbols for /usr/bin/cygungif-4.dll
warning: NOD32 protected [MSAFD Tcpip [TCP/IP]]
warning: NOD32 protected [MSAFD Tcpip [UDP/IP]]
warning: NOD32 protected [MSAFD Tcpip [RAW/IP]]
warning: NOD32 protected [RSVP UDP Service Provider]
warning: NOD32 protected [RSVP TCP Service Provider]


IT HANGS, I must kill it


Program received signal SIGSEGV, Segmentation fault.
[Switching to thread 4068.0xc50]
---Type <return> to continue, or q <return> to quit---Killed

-------------------------------------------------------


'E' .gdbinit has errors and it seems ignored, i.e.
------------------------------------------------------
....
This GDB was configured as "i686-pc-cygwin"...
DISPLAY = :0.0
TERM = xterm
/tmp/emacs/.build/src/.gdbinit:1: Error in sourced command file:
/tmp/emacs/src/.gdbinit:1096: Error in sourced command file:
No breakpoint number 0.

------------------------------------------------------



'W' starting Emacs with GDB works,
----------------------------------------------------------------
cd /tmp/emacs/.build/src

$ gdb ./emacs.exe
GNU gdb 6.5.50.20060706-cvs (cygwin-special)
Copyright (C) 2006 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 "i686-pc-cygwin"...
DISPLAY = :0.0
TERM = xterm
(gdb) r
Starting program: /tmp/emacs/.build/src/emacs.exe -geometry 80x40+0+0
Loaded symbols for /c/WINDOWS/system32/ntdll.dll
Loaded symbols for /c/WINDOWS/system32/kernel32.dll
Loaded symbols for /usr/X11R6/bin/cygICE-6.dll
Loaded symbols for /usr/bin/cygwin1.dll
Loaded symbols for /c/WINDOWS/system32/advapi32.dll
Loaded symbols for /c/WINDOWS/system32/rpcrt4.dll
Loaded symbols for /usr/X11R6/bin/cygSM-6.dll
Loaded symbols for /usr/X11R6/bin/cygX11-6.dll
Loaded symbols for /usr/X11R6/bin/cygXaw3d-7.dll
Loaded symbols for /usr/X11R6/bin/cygXext-6.dll
Loaded symbols for /usr/X11R6/bin/cygXmu-6.dll
Loaded symbols for /usr/X11R6/bin/cygXt-6.dll
Loaded symbols for /usr/X11R6/bin/cygXpm-4.dll
Loaded symbols for /usr/bin/cygncurses-8.dll
Loaded symbols for /usr/bin/cygjpeg-62.dll
Loaded symbols for /usr/bin/cygpng12.dll
Loaded symbols for /usr/bin/cygz.dll
Loaded symbols for /usr/bin/cygtiff-5.dll
Loaded symbols for /usr/bin/cygungif-4.dll
warning: NOD32 protected [MSAFD Tcpip [TCP/IP]]
warning: NOD32 protected [MSAFD Tcpip [UDP/IP]]
warning: NOD32 protected [MSAFD Tcpip [RAW/IP]]
warning: NOD32 protected [RSVP UDP Service Provider]
warning: NOD32 protected [RSVP TCP Service Provider]

[1]+ Stopped gdb ./emacs.exe

$ fg
gdb ./emacs.exe
---Type <return> to continue, or q <return> to quit---


AFTER A FEW MINUTES


Program received signal SIGSEGV, Segmentation fault.
0x200f217c in mark_object (arg=1569454217) at /tmp/emacs/src/alloc.c:5509
5509 MARK_INTERVAL_TREE (ptr->intervals);

(gdb) bt
#0 0x200f217c in mark_object (arg=1569454217) at
/tmp/emacs/src/alloc.c:5509
#1 0x200f2a4f in Fgarbage_collect () at /tmp/emacs/src/alloc.c:5174
#2 0x20106533 in Feval (form=568921741) at /tmp/emacs/src/eval.c:2216
#3 0x20105355 in internal_condition_case_1 (bfun=0x20106490 <Feval>,
arg=568921741, handlers=539914913,
hfun=0x200a4710 <menu_item_eval_property_1>) at
/tmp/emacs/src/eval.c:1525
#4 0x200a47a2 in menu_item_eval_property (sexpr=1569454217)
at /tmp/emacs/src/keyboard.c:7270
#5 0x200b0d4e in get_keyelt (object=540146505, autoload=1)
at /tmp/emacs/src/keymap.c:829
#6 0x200b13a3 in access_keymap (map=539846877, idx=539880097, t_ok=2,
noinherit=0, autoload=1) at /tmp/emacs/src/keymap.c:655
#7 0x200a5496 in tool_bar_items (reuse=536990456, nitems=0x22b688)
at /tmp/emacs/src/keyboard.c:7732
#8 0x2001d51f in update_tool_bar (f=0x2192d000, save_match_data=0)
at /tmp/emacs/src/xdisp.c:9414
#9 0x2002bc8f in prepare_menu_bars () at /tmp/emacs/src/xdisp.c:9098
#10 0x2002c8ec in redisplay_internal (preserve_echo_area=1569454217)
at /tmp/emacs/src/xdisp.c:10935
#11 0x2002d08a in redisplay_preserve_echo_area (from_where=8)
at /tmp/emacs/src/xdisp.c:11545
#12 0x200a7aec in detect_input_pending_run_timers (do_display=1)
at /tmp/emacs/src/keyboard.c:10061
---Type <return> to continue, or q <return> to quit---
#13 0x2013a2a5 in wait_reading_process_output (time_limit=0, microsecs=0,
read_kbd=-1, do_display=1, wait_for_cell=539858945, wait_proc=0x0,
just_wait_proc=0) at /tmp/emacs/src/process.c:4665
#14 0x200a8e40 in read_char (commandflag=1, nmaps=2, maps=0x22c700,
prev_event=539858945, used_mouse_menu=0x22c748, end_time=0x0)
at /tmp/emacs/src/keyboard.c:3988
#15 0x200ab88d in read_key_sequence (keybuf=0x22c8a0, bufsize=30,
prompt=539858945, dont_downcase_last=0, can_return_switch_frame=1,
fix_current_buffer=1) at /tmp/emacs/src/keyboard.c:8956
#16 0x200ad3d1 in command_loop_1 () at /tmp/emacs/src/keyboard.c:1601
#17 0x2010558f in internal_condition_case (bfun=0x200ad220
<command_loop_1>,
handlers=539914913, hfun=0x200a6c80 <cmd_error>)
at /tmp/emacs/src/eval.c:1477
#18 0x200a0a8e in command_loop_2 () at /tmp/emacs/src/keyboard.c:1326
#19 0x2010524f in internal_catch (tag=1569454217,
func=0x200a0a60 <command_loop_2>, arg=539858945)
at /tmp/emacs/src/eval.c:1218
#20 0x200a08a3 in command_loop () at /tmp/emacs/src/keyboard.c:1305
#21 0x200a0944 in recursive_edit_1 () at /tmp/emacs/src/keyboard.c:1003
#22 0x200a0a20 in Frecursive_edit () at /tmp/emacs/src/keyboard.c:1064
#23 0x2009fd9d in main (argc=3, argv=0x202ce900) at
/tmp/emacs/src/emacs.c:1794

(gdb) p arg
$1 = 1569454217

(gdb) xpr
Lisp_Symbol
$2 = (struct Lisp_Symbol *) 0x7d8bf888
Cannot access memory at address 0x7d8bf88c
(gdb)

----------------------------------------------------------------


I want to flag that on Cygwin mailing list there are peoples that have
similar problems with GDB
(http://cygwin.com/ml/cygwin/2006-09/msg00534.html).


Angelo.
Eli Zaretskii
2006-09-30 09:30:01 UTC
Permalink
Date: Thu, 28 Sep 2006 12:18:00 +0200 (MET DST)
The problem is localized between lines
1072 # People get bothered when...
..... .....
1110 end
This is somewhat tangential to the real problem at hand, but as long
as we are talking about this: what happens if you remove all that
block from .gdbinit, type "gdb ./emacs.exe" in the src directory, and
then manually type the commands in the offending block, one after the
other? I'm particularly interested to know whether you see any error
messages from GDB, and if so, which line causes these messages.
(gdb) xpr
Lisp_Symbol
$2 = (struct Lisp_Symbol *) 0x7d8bf888
Cannot access memory at address 0x7d8bf88c
(gdb)
Kim, any clever ideas, before we ask Angelo to look in last_marked[]
array etc.?
I want to flag that on Cygwin mailing list there are peoples that have
similar problems with GDB
(http://cygwin.com/ml/cygwin/2006-09/msg00534.html).
Yes, I've seen that thread, but I don't see any useful (i.e., that
explain what's going on and why) responses to the problem it reported.
Kim F. Storm
2006-09-30 23:34:37 UTC
Permalink
Post by Eli Zaretskii
Date: Thu, 28 Sep 2006 12:18:00 +0200 (MET DST)
The problem is localized between lines
1072 # People get bothered when...
..... .....
1110 end
This is somewhat tangential to the real problem at hand, but as long
as we are talking about this: what happens if you remove all that
block from .gdbinit, type "gdb ./emacs.exe" in the src directory, and
then manually type the commands in the offending block, one after the
other? I'm particularly interested to know whether you see any error
messages from GDB, and if so, which line causes these messages.
(gdb) xpr
Lisp_Symbol
$2 = (struct Lisp_Symbol *) 0x7d8bf888
Cannot access memory at address 0x7d8bf88c
(gdb)
Kim, any clever ideas, before we ask Angelo to look in last_marked[]
array etc.?
Turning off the toolbar makes the crash go away, so I suspect a GC
problem with building the tool-bar string.

It could be a specific tool-bar binding in one of the keymaps that
triggers the bug.

Could we try to dump global-map, and all active local maps and look
for tool-bar items (using eval) in them ?

Does Cygwin use GCPROs or stack marking?
Post by Eli Zaretskii
I want to flag that on Cygwin mailing list there are peoples that have
similar problems with GDB
(http://cygwin.com/ml/cygwin/2006-09/msg00534.html).
Yes, I've seen that thread, but I don't see any useful (i.e., that
explain what's going on and why) responses to the problem it reported.
--
Kim F. Storm <***@cua.dk> http://www.cua.dk
Eli Zaretskii
2006-10-01 10:28:43 UTC
Permalink
Date: Sun, 01 Oct 2006 01:34:37 +0200
Could we try to dump global-map, and all active local maps and look
for tool-bar items (using eval) in them ?
Does Cygwin use GCPROs or stack marking?
Please instruct Angelo how to find the answers to these questions.
Angelo Graziosi
1970-01-01 00:00:00 UTC
Permalink
Post by Eli Zaretskii
Date: Thu, 28 Sep 2006 12:18:00 +0200 (MET DST)
The problem is localized between lines
1072 # People get bothered when...
..... .....
1110 end
This is somewhat tangential to the real problem at hand, but as long
as we are talking about this: what happens if you remove all that
block from .gdbinit, type "gdb ./emacs.exe" in the src directory, and
then manually type the commands in the offending block, one after the
^^^^^^^^^^^^^^^^^^^^^^^^^^
????
Post by Eli Zaretskii
other? I'm particularly interested to know whether you see any error
messages from GDB, and if so, which line causes these messages.
This is not clear:

- I remove the blocks A,B,C from .gdbinit
- then start gdb ./emacs...
- then add a line at time of the removed blocks: Add to .gdbinit or at GDB
prompt ?


As I wrote, removing the block C causes GDB sayd .gdbinit has errors.


Cheers

Angelo.
Post by Eli Zaretskii
(gdb) xpr
Lisp_Symbol
$2 = (struct Lisp_Symbol *) 0x7d8bf888
Cannot access memory at address 0x7d8bf88c
(gdb)
Kim, any clever ideas, before we ask Angelo to look in last_marked[]
array etc.?
I want to flag that on Cygwin mailing list there are peoples that have
similar problems with GDB
(http://cygwin.com/ml/cygwin/2006-09/msg00534.html).
Yes, I've seen that thread, but I don't see any useful (i.e., that
explain what's going on and why) responses to the problem it reported.
Eli Zaretskii
2006-09-30 14:47:28 UTC
Permalink
Date: Sat, 30 Sep 2006 12:16:17 +0200 (MET DST)
Post by Eli Zaretskii
This is somewhat tangential to the real problem at hand, but as long
as we are talking about this: what happens if you remove all that
block from .gdbinit, type "gdb ./emacs.exe" in the src directory, and
then manually type the commands in the offending block, one after the
^^^^^^^^^^^^^^^^^^^^^^^^^^
????
Post by Eli Zaretskii
other? I'm particularly interested to know whether you see any error
messages from GDB, and if so, which line causes these messages.
- I remove the blocks A,B,C from .gdbinit
- then start gdb ./emacs...
- then add a line at time of the removed blocks: Add to .gdbinit or at GDB
prompt ?
Type the commands at the GDB prompt one by one, in the order they
appear in the original .gdbinit.
Angelo Graziosi
1970-01-01 00:00:00 UTC
Permalink
Post by Eli Zaretskii
Date: Sat, 30 Sep 2006 12:16:17 +0200 (MET DST)
Post by Eli Zaretskii
This is somewhat tangential to the real problem at hand, but as long
as we are talking about this: what happens if you remove all that
block from .gdbinit, type "gdb ./emacs.exe" in the src directory, and
then manually type the commands in the offending block, one after the
^^^^^^^^^^^^^^^^^^^^^^^^^^
????
Post by Eli Zaretskii
other? I'm particularly interested to know whether you see any error
messages from GDB, and if so, which line causes these messages.
- I remove the blocks A,B,C from .gdbinit
- then start gdb ./emacs...
- then add a line at time of the removed blocks: Add to .gdbinit or at GDB
prompt ?
Type the commands at the GDB prompt one by one, in the order they
appear in the original .gdbinit.
As I thinked,
---------------------------------------------------------------------
cd /tmp/emacs/.build/src
$ gdb ./emacs.exe
GNU gdb 6.5.50.20060706-cvs (cygwin-special)
Copyright (C) 2006 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 "i686-pc-cygwin"...
DISPLAY = :0.0
TERM = xterm
(gdb) xgetptr Vsystem_type
(gdb) if ($ptr != 0)
Post by Eli Zaretskii
set $tem = (struct Lisp_Symbol *) $ptr
xgetptr $tem->xname
set $tem = (struct Lisp_String *) $ptr
set $tem = (char *) $tem->data
if $tem[0] == 'w' && $tem[1] == 'i' && $tem[2] == 'n' && $tem[3] == 'd'
break w32_abort
else
break abort
end
end
Breakpoint 1 at 0x2009e476: file /tmp/emacs/src/emacs.c, line 464.
(gdb) tbreak init_sys_modes
Breakpoint 2 at 0x200b7e89: file /tmp/emacs/src/sysdep.c, line 1395.
(gdb) commands
Type commands for when breakpoint 2 is hit, one per line.
End with a line saying just "end".
Post by Eli Zaretskii
silent
xgetptr Vwindow_system
set $tem = (struct Lisp_Symbol *) $ptr
xgetptr $tem->xname
set $tem = (struct Lisp_String *) $ptr
set $tem = (char *) $tem->data
if $tem[0] == 'x' && $tem[1] == '\0'
break x_error_quitter
end
continue
end
(gdb)


---------------------------------------------------------------------


Cheers,

Angelo.
Eli Zaretskii
2006-10-01 16:54:28 UTC
Permalink
Date: Sat, 30 Sep 2006 18:49:05 +0200 (MET DST)
Post by Eli Zaretskii
Type the commands at the GDB prompt one by one, in the order they
appear in the original .gdbinit.
As I thinked,
Can you explain what you thought?

Anyway, this is not the main problem, so I'll drop this side issue for
now. Thanks.
Angelo Graziosi
1970-01-01 00:00:00 UTC
Permalink
Hi Eli,

While conserving the tree of previous build of Emacs so that we can try to
debug its segm. faults, I have tried a new build fram a new CVS downloaded
after:

2006-09-30 Eli Zaretskii <***@gnu.org>

* configure: Regenerated.

But when 'make install' there are the following problems:
--------------------------------------------------------
...
cd leim; make install
make[1]: Entering directory `/tmp/emacs/.build/leim'
...
/bin/sh: line
0: cd: /tmp/emacs/.inst/usr/local/emacs-22.0.50/share/emacs/22.0.50/leim: No
such file or directory
/bin/sh: line 5: /tmp/emacs/leim/mkinstalldirs: No such file or directory
Copying leim files to
/tmp/emacs/.inst/usr/local/emacs-22.0.50/share/emacs/22.0.50/leim ...
/bin/sh: line
13: cd: /tmp/emacs/.inst/usr/local/emacs-22.0.50/share/emacs/22.0.50/leim: No
such file or directory
leim-list.el
quail/
quail/4Corner.el
tar: quail/4Corner.el: Cannot open: Permission denied
tar: Skipping to next header
quail/4Corner.elc
tar: quail/4Corner.elc: Cannot open: Permission denied
tar: Skipping to next header
quail/ARRAY30.el
tar: quail/ARRAY30.el: Cannot open: Permission denied
tar: Skipping to next header
quail/ARRAY30.elc
tar: quail/ARRAY30.elc: Cannot open: Permission denied
tar: Skipping to next header

... Many ...

tar: quail: file changed as we read it
tar: Error exit delayed from previous errors
/bin/sh: line
16: cd: /tmp/emacs/.inst/usr/local/emacs-22.0.50/share/emacs/22.0.50/leim: No
such file or directory
quail/CVS/
quail/CVS/Entries
...

--------------------------------------------------------

In the ChangeLog I note
-----------------------------------------------------------------
2006-09-28 Kenichi Handa <***@m17n.org>

* configure.in (locallisppath): Don't include leim dir.
(lisppath): Include leim dir.
------------------------------------------------------------------


Could it be the cause ?


Cheers,

Angelo.
Giorgos Keramidas
2006-10-02 00:30:34 UTC
Permalink
Post by Angelo Graziosi
Hi Eli,
While conserving the tree of previous build of Emacs so that we can try to
debug its segm. faults, I have tried a new build fram a new CVS downloaded
* configure: Regenerated.
--------------------------------------------------------
...
cd leim; make install
make[1]: Entering directory `/tmp/emacs/.build/leim'
...
/bin/sh: line
0: cd: /tmp/emacs/.inst/usr/local/emacs-22.0.50/share/emacs/22.0.50/leim: No
such file or directory
/bin/sh: line 5: /tmp/emacs/leim/mkinstalldirs: No such file or directory
Copying leim files to
/tmp/emacs/.inst/usr/local/emacs-22.0.50/share/emacs/22.0.50/leim ...
/bin/sh: line
13: cd: /tmp/emacs/.inst/usr/local/emacs-22.0.50/share/emacs/22.0.50/leim: No
such file or directory
leim-list.el
I had to add `mkinstalldirs' to leim/ too to make Emacs build
successfully from a snapshot obtained from CVS at:

% $ hg tip
% changeset: 76412:6d04f2749c12
% tag: tip
% user: eliz
% date: Sun Oct 01 17:11:58 2006 +0000
% summary: *** empty log message ***
%
% $

The diff from the local Mercurial tree I use to keep my own changes is:

%%%
# HG changeset patch
# User Giorgos Keramidas <***@ceid.upatras.gr>
# Date 1159748821 -10800
# Node ID dc7359535a0eb4664d13cff02c848b614ddb0dc1
# Parent 73911f55ac5ecf415cc729f549ad9a47f61ffe57
Add `mkinstalldirs' to leim/ too, now that it needs it.

diff -r 73911f55ac5e -r dc7359535a0e leim/mkinstalldirs
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/leim/mkinstalldirs Mon Oct 02 03:27:01 2006 +0300
@@ -0,0 +1,38 @@
+#! /bin/sh
+# mkinstalldirs --- make directory hierarchy
+# Author: Noah Friedman <***@prep.ai.mit.edu>
+# Created: 1993-05-16
+# Public domain
+
+errstatus=0
+
+for file
+do
+ set fnord `echo ":$file" | sed -ne 's/^:\//#/;s/^://;s/\// /g;s/^#/\//;p'`
+ shift
+
+ pathcomp=
+ for d
+ do
+ pathcomp="$pathcomp$d"
+ case "$pathcomp" in
+ -* ) pathcomp=./$pathcomp ;;
+ esac
+
+ if test ! -d "$pathcomp"; then
+ echo "mkdir $pathcomp" 1>&2
+
+ mkdir "$pathcomp" || lasterr=$?
+
+ if test ! -d "$pathcomp"; then
+ errstatus=$lasterr
+ fi
+ fi
+
+ pathcomp="$pathcomp/"
+ done
+done
+
+exit $errstatus
+
+# mkinstalldirs ends here
%%%
Kenichi Handa
2006-10-02 12:53:07 UTC
Permalink
Post by Angelo Graziosi
Hi Eli,
While conserving the tree of previous build of Emacs so that we can try to
debug its segm. faults, I have tried a new build fram a new CVS downloaded
* configure: Regenerated.
--------------------------------------------------------
...
cd leim; make install
make[1]: Entering directory `/tmp/emacs/.build/leim'
...
/bin/sh: line
0: cd: /tmp/emacs/.inst/usr/local/emacs-22.0.50/share/emacs/22.0.50/leim: No
such file or directory
/bin/sh: line 5: /tmp/emacs/leim/mkinstalldirs: No such file or directory
Oops, sorry, it's my fault. I've just installed the
attached change.

---
Kenichi Handa
***@m17n.org


Index: Makefile.in
===================================================================
RCS file: /cvsroot/emacs/emacs/leim/Makefile.in,v
retrieving revision 1.76
retrieving revision 1.77
diff -u -r1.76 -r1.77
--- Makefile.in 28 Sep 2006 05:46:00 -0000 1.76
+++ Makefile.in 2 Oct 2006 12:39:18 -0000 1.77
@@ -221,7 +221,7 @@
rm -rf ${INSTALLDIR}/leim-list.el; \
rm -rf ${INSTALLDIR}/quail ${INSTALLDIR}/ja-dic ; \
else \
- ${srcdir}/mkinstalldirs ${INSTALLDIR}; \
+ ${srcdir}/${dot}${dot}/mkinstalldirs ${INSTALLDIR}; \
fi; \
echo "Copying leim files to ${INSTALLDIR} ..." ; \
if [ x`(cd ${srcdir} && /bin/pwd)` = x`(/bin/pwd)` ] ; then \
Giorgos Keramidas
2006-10-02 13:39:36 UTC
Permalink
Post by Kenichi Handa
Post by Angelo Graziosi
Hi Eli,
While conserving the tree of previous build of Emacs so that we can try to
debug its segm. faults, I have tried a new build fram a new CVS downloaded
* configure: Regenerated.
--------------------------------------------------------
...
cd leim; make install
make[1]: Entering directory `/tmp/emacs/.build/leim'
...
/bin/sh: line
0: cd: /tmp/emacs/.inst/usr/local/emacs-22.0.50/share/emacs/22.0.50/leim: No
such file or directory
/bin/sh: line 5: /tmp/emacs/leim/mkinstalldirs: No such file or directory
Oops, sorry, it's my fault. I've just installed the
attached change.
No problem. Thanks for the quick fix :)
Post by Kenichi Handa
Index: Makefile.in
===================================================================
RCS file: /cvsroot/emacs/emacs/leim/Makefile.in,v
retrieving revision 1.76
retrieving revision 1.77
diff -u -r1.76 -r1.77
--- Makefile.in 28 Sep 2006 05:46:00 -0000 1.76
+++ Makefile.in 2 Oct 2006 12:39:18 -0000 1.77
@@ -221,7 +221,7 @@
rm -rf ${INSTALLDIR}/leim-list.el; \
rm -rf ${INSTALLDIR}/quail ${INSTALLDIR}/ja-dic ; \
else \
- ${srcdir}/mkinstalldirs ${INSTALLDIR}; \
+ ${srcdir}/${dot}${dot}/mkinstalldirs ${INSTALLDIR}; \
fi; \
echo "Copying leim files to ${INSTALLDIR} ..." ; \
if [ x`(cd ${srcdir} && /bin/pwd)` = x`(/bin/pwd)` ] ; then \
Angelo Graziosi
1970-01-01 00:00:00 UTC
Permalink
Post by Eli Zaretskii
Date: Sat, 30 Sep 2006 18:49:05 +0200 (MET DST)
Post by Eli Zaretskii
Type the commands at the GDB prompt one by one, in the order they
appear in the original .gdbinit.
As I thinked,
Can you explain what you thought?
I thinked it was the most likely but I was not sure to have right
interpreted your words.



Angelo.
Angelo Graziosi
1970-01-01 00:00:00 UTC
Permalink
There is some news regarding the behaviour of GDB and I flag this for the
sake of completeness.

I have repost the GDB problem to Cygwin list

http://cygwin.com/ml/cygwin/2006-10/msg00843.html

and this time I have got a little answer

http://cygwin.com/ml/cygwin/2006-10/msg00848.html

This help me to some conclusions

http://cygwin.com/ml/cygwin/2006-10/msg00850.html
http://cygwin.com/ml/cygwin/2006-10/msg00851.html

i.e. GCC-4.0.3, 4.3.0 (and also 3.4.4-1) works correctly with GDB but not
GCC-3.4.4-2 (exp. package in Cygwin, it applies the '24196' patch) which I
used to build hello.c and Emacs-cvs.

For some strange reason, using '-g' with GCC-3.4.4-2 does not insert the
right debug symbols in the executable.


Angelo.
Eli Zaretskii
2006-10-26 07:48:16 UTC
Permalink
Date: Thu, 26 Oct 2006 00:32:47 +0200 (MET DST)
i.e. GCC-4.0.3, 4.3.0 (and also 3.4.4-1) works correctly with GDB but not
GCC-3.4.4-2 (exp. package in Cygwin, it applies the '24196' patch) which I
used to build hello.c and Emacs-cvs.
For some strange reason, using '-g' with GCC-3.4.4-2 does not insert the
right debug symbols in the executable.
Thanks for the update.

If you bootstrap Emacs with a version of GCC that does produce the
correct debug symbols, does the original problem (Emacs crashing or
hanging) disappear? If it does not disappear, can you at least run
Emacs under GDB (perhaps upgrade your GDB as well to the latest Cygwin
port) and see where it crashes/hangs?
Richard Stallman
2006-10-26 08:53:04 UTC
Permalink
i.e. GCC-4.0.3, 4.3.0 (and also 3.4.4-1) works correctly with GDB but not
GCC-3.4.4-2 (exp. package in Cygwin, it applies the '24196' patch) which I
used to build hello.c and Emacs-cvs.

For some strange reason, using '-g' with GCC-3.4.4-2 does not insert the
right debug symbols in the executable.

If an old version has a bug that has been fixed, the solution is simple:
upgrade GCC.

Eli, would you like to document this in the appropriate place?
Perhaps etc/PROBLEMS, or wherever there are Cygwin build instructions.
Eli Zaretskii
2006-10-26 15:08:27 UTC
Permalink
Date: Thu, 26 Oct 2006 04:53:04 -0400
Eli, would you like to document this in the appropriate place?
Perhaps etc/PROBLEMS, or wherever there are Cygwin build instructions.
I'm not yet sure what to say there, since we don't yet know whether
the bootstrap worked with the newer version of GCC. What we do know
for sure is that the older version didn't produce correct debug info,
but that is only marginally relevant to Emacs, more to GDB.
Richard Stallman
2006-10-27 09:10:08 UTC
Permalink
I'm not yet sure what to say there, since we don't yet know whether
the bootstrap worked with the newer version of GCC.

You can say that newer versions give correct debugging output,
so people using GCC 3.4 should upgrade.
Angelo Graziosi
1970-01-01 00:00:00 UTC
Permalink
Post by Eli Zaretskii
If you bootstrap Emacs with a version of GCC that does produce the
correct debug symbols, does the original problem (Emacs crashing or
hanging) disappear?
I am bootstrapping with GCC-4.0.3 it take about 3 hours on my system.
=========

But what I have just done since yesterday is this.

I had a build tree (CVS 20061025 15:00) on Linux, so I have run

make distclean

then I have packed the tree and tranfered it on Window-Cygwin.

Here I have updated CVS and added a pointer to GCC-4.0.3 bin dir

export PATH=/usr/local/g95/bin:$PATH
gcc -v

in the build script for Emacs-CVS.

This script run

...
../configure --prefix=...
make
cd lisp
make autoloads EMACS=../src/emacs
make recompile EMACS=../src/emacs
cd ..
make
make install


This Emacs-CVS build seems to run without any crashing!


Angelo.
Jason Rumney
2006-10-26 08:57:52 UTC
Permalink
Post by Angelo Graziosi
This Emacs-CVS build seems to run without any crashing!
That is a good sign, but your original symptoms were very similar to a
case we had when compiling 21.3 and 21.4 with recent MingW ports of gcc.
In that case the cause was that .elc files had been written in DOS text
mode (converting \n to \r\n and terminating the file when a ^Z character
was encountered). If the problem is the same, it will only show up when
you bootstrap with that build of Emacs, since elc files compiled on
another platform will not have the same problem.
Richard Stallman
2006-10-26 10:12:00 UTC
Permalink
I had a build tree (CVS 20061025 15:00) on Linux, so I have run

I think you mean "on GNU/Linux", because that is a complete system,
comparable to Microsoft Windows.

This Emacs-CVS build seems to run without any crashing!

I guess that means the bug has been fixed by newer GCC versions.
That is good.
David Kastrup
2006-10-26 10:24:40 UTC
Permalink
Post by Angelo Graziosi
I had a build tree (CVS 20061025 15:00) on Linux, so I have run
I think you mean "on GNU/Linux", because that is a complete system,
comparable to Microsoft Windows.
Microsoft Windows is not a complete system, as it is missing most end
user applications, and is also lacking the toolbox inventory of small
utilities that are a necessary ingredient of POSIX systems.

One has to add quite a bit of GNU stuff to MS Windows before it
becomes comparably useful.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
Eli Zaretskii
2006-10-26 15:06:25 UTC
Permalink
Date: Thu, 26 Oct 2006 12:24:40 +0200
Microsoft Windows is not a complete system, as it is missing most end
user applications, and is also lacking the toolbox inventory of small
utilities that are a necessary ingredient of POSIX systems.
What exactly is missing that makes you say this?

A bare-bones Linux kernel lacks even a shell and basic commands like
ls and cp, which are all GNU programs, but MS-Windows does come with
the equivalents of these commands out of the box.
One has to add quite a bit of GNU stuff to MS Windows before it
becomes comparably useful.
``Useful'' is in the eyes of the beholder. ``Usable'' is a more
relevant issue: stripped of all GNU programs, a Linux-based system is
simply unusable, IMO.
David Kastrup
2006-10-26 15:12:03 UTC
Permalink
Post by Eli Zaretskii
Date: Thu, 26 Oct 2006 12:24:40 +0200
Microsoft Windows is not a complete system, as it is missing most
end user applications, and is also lacking the toolbox inventory of
small utilities that are a necessary ingredient of POSIX systems.
What exactly is missing that makes you say this?
A bare-bones Linux kernel
Which neither Richard nor I was talking about. Richard was clearly
talking about a GNU/Linux system, and so was I. And Richard called a
GNU/Linux system comparable to MS Windows, and I said that MS Windows
did not compare well at all in that regard.

So I don't know what straw men you are trying to beat here.
Post by Eli Zaretskii
lacks even a shell and basic commands like ls and cp, which are all
GNU programs, but MS-Windows does come with the equivalents of these
commands out of the box.
But the MS Windows versions of even those primitive commands are much
less useful, particular in scripts, than the GNU equivalents.
Post by Eli Zaretskii
One has to add quite a bit of GNU stuff to MS Windows before it
becomes comparably useful.
``Useful'' is in the eyes of the beholder. ``Usable'' is a more
relevant issue: stripped of all GNU programs, a Linux-based system
is simply unusable, IMO.
So what? Richard was not talking about just a kernel, I was not
talking about just a kernel.

What is your fixation with a bare Linux kernel?
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
Eli Zaretskii
2006-10-27 08:17:56 UTC
Permalink
Date: Thu, 26 Oct 2006 17:12:03 +0200
Post by Eli Zaretskii
What exactly is missing that makes you say this?
You didn't answer that.
Post by Eli Zaretskii
A bare-bones Linux kernel
Which neither Richard nor I was talking about.
Neither was I, sorry for the confusing wording. I later used a more
accurate (but much longer) term "GNU/Linux with all the GNU commands
removed".
But the MS Windows versions of even those primitive commands are much
less useful, particular in scripts, than the GNU equivalents.
When did you last looked at those commands? They are much more
powerful since at least 6 years ago. If you have examples of the
functionality you think is missing, let's hear them.
Post by Eli Zaretskii
``Useful'' is in the eyes of the beholder. ``Usable'' is a more
relevant issue: stripped of all GNU programs, a Linux-based system
is simply unusable, IMO.
So what? Richard was not talking about just a kernel, I was not
talking about just a kernel.
What is your fixation with a bare Linux kernel?
There is none. I didn't even use that term in the part to which you
were responding here.
David Kastrup
2006-10-27 09:04:39 UTC
Permalink
Post by Eli Zaretskii
Date: Thu, 26 Oct 2006 17:12:03 +0200
Post by Eli Zaretskii
What exactly is missing that makes you say this?
You didn't answer that.
Post by Eli Zaretskii
A bare-bones Linux kernel
Which neither Richard nor I was talking about.
Neither was I, sorry for the confusing wording. I later used a more
accurate (but much longer) term "GNU/Linux with all the GNU commands
removed".
But nobody was talking about that except you. So the problem does not
appear to be with your wording.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
Eli Zaretskii
2006-10-28 10:49:47 UTC
Permalink
Date: Fri, 27 Oct 2006 11:04:39 +0200
Post by Eli Zaretskii
Post by David Kastrup
Post by Eli Zaretskii
A bare-bones Linux kernel
Which neither Richard nor I was talking about.
Neither was I, sorry for the confusing wording. I later used a more
accurate (but much longer) term "GNU/Linux with all the GNU commands
removed".
But nobody was talking about that except you. So the problem does not
appear to be with your wording.
I no longer know what you were talking about. What you seem to say is
of no practical importance, and here's why:

GNU/Linux is called that way because without GNU programs that system
is unusable, even though more than half of what comes with the system
are not GNU programs. Richard is asking people to use the bare
"Linux" term only in conjunction with the Linux kernel, and I have no
problem with that; but that doesn't mean that the GNU/Linux system is
simply a combination of GNU programs and the Linux kernel. It is a
logical fallacy to think so. In particular, it is clear to everyone
that a kernel alone, without any programs that use that kernel or at
least have the ability to load and run a program on that kernel, is
useless.

So, IMO, in practical terms, it doesn't make sense to talk about the
Linux kernel as opposed to MS-Windows without GNU software. The
correct comparison is of a GNU/Linux system without any GNU software
vs the MS-Windows system as it comes shrink-wrapped. And that is the
comparison I made: I think that Richard was right saying that
MS-Windows comes out of the box as a complete and usable system, while
GNU/Linux without any GNU program is unusable.

You also made some incorrect statements about Windows, both about its
usability without ports of GNU software, and wrt our ability to
clearly define what is the equivalent of the Linux kernel on Windows.

The cause of Free Software is not served well by concealing the truth
behind tricky argument techniques and over-simplified statements. It
is better served by looking the hard facts in the face and stating our
principles even if the reality is not as simple as we'd wish it to be.
Richard Stallman
2006-10-29 18:45:53 UTC
Permalink
GNU/Linux is called that way because without GNU programs that system
is unusable, even though more than half of what comes with the system
are not GNU programs.

That's not the reason we cite, though.
See http://www.gnu.org/gnu/linux-and-gnu.html.
Eli Zaretskii
2006-10-29 20:19:06 UTC
Permalink
Date: Sun, 29 Oct 2006 13:45:53 -0500
GNU/Linux is called that way because without GNU programs that system
is unusable, even though more than half of what comes with the system
are not GNU programs.
That's not the reason we cite, though.
See http://www.gnu.org/gnu/linux-and-gnu.html.
What I said is my reading of what that page says.
Richard Stallman
2006-10-30 19:16:08 UTC
Permalink
Post by Eli Zaretskii
GNU/Linux is called that way because without GNU programs that system
is unusable, even though more than half of what comes with the system
are not GNU programs.
That's not the reason we cite, though.
See http://www.gnu.org/gnu/linux-and-gnu.html.
What I said is my reading of what that page says.

The page must be unclear. Off the list, can we talk to figure out why?
Eli Zaretskii
2006-10-30 20:49:08 UTC
Permalink
Date: Mon, 30 Oct 2006 14:16:08 -0500
Post by Eli Zaretskii
GNU/Linux is called that way because without GNU programs that system
is unusable, even though more than half of what comes with the system
are not GNU programs.
That's not the reason we cite, though.
See http://www.gnu.org/gnu/linux-and-gnu.html.
What I said is my reading of what that page says.
The page must be unclear. Off the list, can we talk to figure out why?
Sure.
Richard Stallman
2006-10-26 20:40:07 UTC
Permalink
Microsoft Windows is not a complete system, as it is missing most end
user applications, and is also lacking the toolbox inventory of small
utilities that are a necessary ingredient of POSIX systems.

One has to add quite a bit of GNU stuff to MS Windows before it
becomes comparably useful.

I stand corrected. Nonetheless, isn't it a lot more than a kernel?
David Kastrup
2006-10-26 20:58:27 UTC
Permalink
Post by David Kastrup
Microsoft Windows is not a complete system, as it is missing most end
user applications, and is also lacking the toolbox inventory of small
utilities that are a necessary ingredient of POSIX systems.
One has to add quite a bit of GNU stuff to MS Windows before it
becomes comparably useful.
I stand corrected. Nonetheless, isn't it a lot more than a kernel?
Yes. The lines between kernel and non-kernel are partly drawn
differently than in typical POSIX systems (for example, with the whole
graphics subsystem running in supervisor mode), and system services
and kernels are not separated in a similar way to other system (I seem
to remember that the distinction between kernel thread and daemon is
not as absolute, but might be mistaken). The basic design for Windows
NT/2000/XP (I think) is supposed to be microkernel-based to some
degree, whereas the 95/98/ME family is based on an old DOS kernel with
both 32bit and graphical extensions.

The system "as such" contains quite more than the kernel, that much is
true. It is just hard to tell what is kernel and what not: running in
supervisor mode does not really seem like the absolute criterion. And
the system "as such" has not as much "hands-on" usefulness for doing
non-trivial tasks than a typical Unix or lookalike, let alone a
GNU/Linux distribution.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
Eli Zaretskii
2006-10-26 15:12:29 UTC
Permalink
Date: Thu, 26 Oct 2006 10:21:16 +0200 (MET DST)
I had a build tree (CVS 20061025 15:00) on Linux, so I have run
make distclean
then I have packed the tree and tranfered it on Window-Cygwin.
Here I have updated CVS and added a pointer to GCC-4.0.3 bin dir
export PATH=/usr/local/g95/bin:$PATH
gcc -v
in the build script for Emacs-CVS.
This script run
...
../configure --prefix=...
make
cd lisp
make autoloads EMACS=../src/emacs
make recompile EMACS=../src/emacs
cd ..
make
make install
This Emacs-CVS build seems to run without any crashing!
This is good to know, but the above doesn't produce bootstrap-emacs at
any point and doesn't run it; it uses the *.elc files compiled on
GNU/Linux. So it sounds like the crashes are unique to
bootstrap-emacs, which means users will be able to build the released
tarball, but still leaves the question of why the bootstrap failed
unanswered.

Please see if your *.elc files produced by the bootstrap are in DOS
CRLF format, which, as Jason points out, was known to cause crashes in
the past.
Angelo Graziosi
1970-01-01 00:00:00 UTC
Permalink
Post by Jason Rumney
Post by Angelo Graziosi
This Emacs-CVS build seems to run without any crashing!
That is a good sign, but your original symptoms were very similar to a
case we had when compiling 21.3 and 21.4 with recent MingW ports of gcc.
In that case the cause was that .elc files had been written in DOS text
mode (converting \n to \r\n and terminating the file when a ^Z character
was encountered). If the problem is the same, it will only show up when
you bootstrap with that build of Emacs, since elc files compiled on
another platform will not have the same problem.
I have bootstrapped Emacs-CVS on Cygwin with GCC-4.0.3.

Then I started Emacs at 13:20 and it is still running (17:19) without
crashing.

It would be desirable that others build Emacs-CVS on Cygwin with a GCC-4
branch to confirm the above. It seems that GCC-3.4.4-2 (exp) on Cygwin is
broken with the '-g' option.

Regarding GCC-4.0.3, it does not belongs to Cygwin yet, I built it myself
(only the core, C language) because it needs to build G95.


Regarding the observations of Jason, there are a few *.elc file that some
editor (Crimson) reports as in DOS format (Emacs shows -=:--).

I have examined a few of these *.elc files and the only differences
between those produced on GNU/Linux (thanks, RMS, to have remembered me
this) and those on Windows-Cygwin are the compiling date and the name of
machines, desktop-angelo on GNU/Linux, homepc on Win-Cygwin.

At first sight it seems that the bootstrapped and the hybrid builds are
very similar.


Cheers,

Angelo.
Eli Zaretskii
2006-10-27 08:41:12 UTC
Permalink
Date: Thu, 26 Oct 2006 17:46:01 +0200 (MET DST)
I have bootstrapped Emacs-CVS on Cygwin with GCC-4.0.3.
Then I started Emacs at 13:20 and it is still running (17:19) without
crashing.
Thanks for the testing.
It would be desirable that others build Emacs-CVS on Cygwin with a GCC-4
branch to confirm the above. It seems that GCC-3.4.4-2 (exp) on Cygwin is
broken with the '-g' option.
Regarding GCC-4.0.3, it does not belongs to Cygwin yet, I built it myself
(only the core, C language) because it needs to build G95.
But you also said in an earlier message that GCC 3.4.4-1 didn't have
the -g bug. Could you please try to build with that version? If
version 3.4.4-2 is the only one to avoid, I'd like to say that
explicitly in etc/PROBLEMS, because building GCC is something most
Cygwin users will probably not wish to do.
Regarding the observations of Jason, there are a few *.elc file that some
editor (Crimson) reports as in DOS format (Emacs shows -=:--).
I have examined a few of these *.elc files and the only differences
between those produced on GNU/Linux (thanks, RMS, to have remembered me
this) and those on Windows-Cygwin are the compiling date and the name of
machines, desktop-angelo on GNU/Linux, homepc on Win-Cygwin.
Sounds like these are false hits, and that the problem mentioned by
Jason doesn't exist.
Angelo Graziosi
1970-01-01 00:00:00 UTC
Permalink
The builds with GCC-3.4.4-2 segment faults regardless if they are
bootstrapped or with the method schetched below.

The last useful build with GCC-3.4.4-2 is with CVS dated 20060906 13:50.
After this time and until 20060920 06:55 the build fails.

Then from 20060920 06:57 the build is fine but Emacs segment faults.

(I used the hybrid method because on GNU/Linux the build takes about 0.5
hours while on Cygwin it takes about 2.5 - 3.0 hours, so with this
'hybrid' build I have cutted the times).


I have examined the *.elc file, those produced on GNU/Linux and on Cygwin.

There are a few of them (e.g button.elc) that Crimson editor indicates as
in DOS format (those produced on GNU/Linux too), but when loaded with
Emacs I see only -=:-- and not (DOS).

In any case the only differences, I found, are the compile time, name of
machine, building dir. When stripped of these things they, on GNU/Linux
and Cygwin, have the same size.


Angelo.
Post by Eli Zaretskii
Date: Thu, 26 Oct 2006 10:21:16 +0200 (MET DST)
I had a build tree (CVS 20061025 15:00) on Linux, so I have run
make distclean
then I have packed the tree and tranfered it on Window-Cygwin.
Here I have updated CVS and added a pointer to GCC-4.0.3 bin dir
export PATH=/usr/local/g95/bin:$PATH
gcc -v
in the build script for Emacs-CVS.
This script run
...
../configure --prefix=...
make
cd lisp
make autoloads EMACS=../src/emacs
make recompile EMACS=../src/emacs
cd ..
make
make install
This Emacs-CVS build seems to run without any crashing!
This is good to know, but the above doesn't produce bootstrap-emacs at
any point and doesn't run it; it uses the *.elc files compiled on
GNU/Linux. So it sounds like the crashes are unique to
bootstrap-emacs, which means users will be able to build the released
tarball, but still leaves the question of why the bootstrap failed
unanswered.
Please see if your *.elc files produced by the bootstrap are in DOS
CRLF format, which, as Jason points out, was known to cause crashes in
the past.
Angelo Graziosi
1970-01-01 00:00:00 UTC
Permalink
Post by Eli Zaretskii
But you also said in an earlier message that GCC 3.4.4-1 didn't have
the -g bug. Could you please try to build with that version? If
version 3.4.4-2 is the only one to avoid, I'd like to say that
explicitly in etc/PROBLEMS, because building GCC is something most
Cygwin users will probably not wish to do.
I should try only with GCC-3.4.4-1 because I have just tried bootstrapping
the same Emacs-CVS with GCC-4.3.0 20061022 (experimental) and have
re-tried with GCC-3.4.4-2:

Only 3.4.4-2 segment fault!


Angelo.
Angelo Graziosi
1970-01-01 00:00:00 UTC
Permalink
Post by Eli Zaretskii
But you also said in an earlier message that GCC 3.4.4-1 didn't have
the -g bug. Could you please try to build with that version? If
version 3.4.4-2 is the only one to avoid, I'd like to say that
explicitly in etc/PROBLEMS, because building GCC is something most
Cygwin users will probably not wish to do.
I have boostrapped also with GCC-3.4.4-1 (curr. in Cygwin) and Emacs
segment faults.

I have observed that configuring with GCC-4.0.3 or 4.3.0 20061022
(experimental), 'configure' reports


What compiler should emacs be built with? gcc -g -O2 -Wno-pointer-sign

while with GCC-3.4.4

What compiler should emacs be built with? gcc -g -O2


but I do not think that this is the difference.

Beside this, the build with GCC-4.3.0 20061022 (experimental) has the
problem that hitting 'M-x' gives (in the minibuffer)

M-x undefined

So, for the moment, only the build with GCC-4.0.3 seems very fine on
Cygwin.

At this point it would remain to boostrap Emacs with GCC-4.1.1 (current
release from GCC site) or 4.2 (next release on GCC) but I haven't these
versions built of gcc.


Cheers

Angelo.
Eli Zaretskii
2006-10-28 12:16:08 UTC
Permalink
Date: Sat, 28 Oct 2006 02:16:04 +0200 (MET DST)
I have observed that configuring with GCC-4.0.3 or 4.3.0 20061022
(experimental), 'configure' reports
What compiler should emacs be built with? gcc -g -O2 -Wno-pointer-sign
while with GCC-3.4.4
What compiler should emacs be built with? gcc -g -O2
but I do not think that this is the difference.
It only makes a difference if you see any warnings during compilation
that complain about passing pointers to signed/unsigned data types.

Thanks for testing this.
Angelo Graziosi
2006-10-29 11:13:30 UTC
Permalink
I have bootstrapped Emacs-cvs (22.0.90) with different GCC version on
Cygwin and this is the summary of results:


GCC-3.4.4-(1/2) Segment fault

GCC-4.0.3 OK
GCC-4.1.1 OK

GCC-4.2-20061024(prerelease) M-x undefined
GCC-4.3-20061022(experim.) M-x undefined


In conclusion on Cygwin only the build with GCC-4.0.3 and 4.1.1 seem to
work fine.

Are there people that can confirm these results?

It would be very apreciated.


Thanks,

Angelo.
Maks Romih
2006-10-30 01:22:39 UTC
Permalink
Post by Angelo Graziosi
GCC-3.4.4-(1/2) Segment fault
GCC-4.0.3 OK
GCC-4.1.1 OK
GCC-4.2-20061024(prerelease) M-x undefined
GCC-4.3-20061022(experim.) M-x undefined
In conclusion on Cygwin only the build with GCC-4.0.3 and > 4.1.1 seem to
work fine.
Are there people that can confirm these results?
I can confirm the 3.4.4.1., because I've also had stackdumps when I built the emacs-22.0.50 with GCC 3.4.4.1.

Then I compiled with CFLAGS=-g to see where it breaks but it doesn't break any more, so now I happily use the debug version.

Maks.
Richard Stallman
2006-10-30 19:16:28 UTC
Permalink
Post by Angelo Graziosi
GCC-3.4.4-(1/2) Segment fault
GCC-4.0.3 OK
GCC-4.1.1 OK
GCC-4.2-20061024(prerelease) M-x undefined
GCC-4.3-20061022(experim.) M-x undefined
In conclusion on Cygwin only the build with GCC-4.0.3 and > 4.1.1 seem to
work fine.
Let's document that people should not use GCC 3.4 on Cygwin.
Where is the best place to document this?
Eric Hanchrow
2006-10-30 20:31:53 UTC
Permalink
Richard> Let's document that people should not use GCC 3.4 on
Richard> Cygwin. Where is the best place to document this?

I vote for nt/INSTALL
--
"Hoot" has its heart in the right place, but I have been
unable to locate its brain.
-- Roger Ebert
Eli Zaretskii
2006-10-30 21:05:42 UTC
Permalink
Date: Mon, 30 Oct 2006 12:31:53 -0800
Richard> Let's document that people should not use GCC 3.4 on
Richard> Cygwin. Where is the best place to document this?
I vote for nt/INSTALL
No, that's the wrong file: the problem is in the Cygwin build, which
doesn't use any of the stuff in nt/.

The right place is etc/PROBLEMS.
Eric Hanchrow
2006-10-30 21:26:19 UTC
Permalink
Eli> No, that's the wrong file: the problem is in the Cygwin
Eli> build, which doesn't use any of the stuff in nt/.

You're right.

Eli> The right place is etc/PROBLEMS.

This, however, I have doubts about: 3.4 appears to be what Cygwin
installs by default, so presumably this problem will hit most Cygwin
users. I think if the note were in INSTALL, people would be more
likely to see it.

Regardless, I think the INSTALL file could be improved a smidgen, with
this change:

--- INSTALL 26 Jul 2006 19:19:06 -0700 1.115
+++ INSTALL 30 Oct 2006 13:25:59 -0800
@@ -200,7 +200,7 @@

DETAILED BUILDING AND INSTALLATION:

-(This is for a Unix or Unix-like system. For MS-DOS and Windows 3.X,
+(This is for a Unix or Unix-like system, including Cygwin. For MS-DOS and Windows 3.X,
see below; search for MSDOG. For Windows 9X, Windows ME, Windows NT,
and Windows 2000, see the file nt/INSTALL. For the Mac, see the file
mac/INSTALL.)
--
Always code as if the guy who ends up maintaining your code will
be a violent psychopath who knows where you live.
-- John F. Woods
Jason Rumney
2006-10-30 21:44:42 UTC
Permalink
Post by Eric Hanchrow
Richard> Let's document that people should not use GCC 3.4 on
Richard> Cygwin. Where is the best place to document this?
I vote for nt/INSTALL
That is the wrong place for instructions for the Cygwin build. The
Cygwin build does not use the windows specific files in the nt
subdirectory, and people who know Cygwin would not expect it to, since
Cygwin is not Windows, it is a POSIX emulation environment.

etc/PROBLEMS seems more appropriate.
Jari Aalto
2006-11-05 10:52:16 UTC
Permalink
Post by Jason Rumney
Post by Eric Hanchrow
Richard> Let's document that people should not use GCC 3.4 on
Richard> Cygwin. Where is the best place to document this?
I vote for nt/INSTALL
That is the wrong place for instructions for the Cygwin build. The
Cygwin build does not use the windows specific files in the nt
subdirectory, and people who know Cygwin would not expect it to, since
Cygwin is not Windows, it is a POSIX emulation environment.
etc/PROBLEMS seems more appropriate.
Woudl it be possible to use OS specific file:

etc/NOTES.Cygwin

Jari
Eli Zaretskii
2006-11-05 11:55:40 UTC
Permalink
Date: 05 Nov 2006 12:52:16 +0200
Post by Jason Rumney
etc/PROBLEMS seems more appropriate.
In the meantime, I already added to PROBLEMS an entry about Cygwin
build with GCC 3.4.4.
etc/NOTES.Cygwin
It's possible, but why would we want to do that? There are at least
several good reasons not to:

. System-specific files are a pain from the user's perspective, since
the users need to be told where to find instructions relevant for
their platform, and there's no good place to put these instructions
(obviously, those instructions cannot be in a platform-specific
files). the etc/ directory is very large, so letting users look
for the files on their own will make things hard on them

. etc/PROBLEMS has an item in the Help menu, and searching it for
"Cygwin" is trivial. Many Emacs users already know about PROBLEMS
and will look there when faced with a problem.

. Cygwin build is, for all practical purposes, a Posix build, so
users will probably assume that general Unix issues hold for it as
well, and look for instructions and other build-related material in
the general files, not in some OS-specific ones.
Eli Zaretskii
2006-10-30 21:06:04 UTC
Permalink
Date: Mon, 30 Oct 2006 14:16:28 -0500
Post by Angelo Graziosi
GCC-3.4.4-(1/2) Segment fault
GCC-4.0.3 OK
GCC-4.1.1 OK
GCC-4.2-20061024(prerelease) M-x undefined
GCC-4.3-20061022(experim.) M-x undefined
In conclusion on Cygwin only the build with GCC-4.0.3 and > 4.1.1 seem to
work fine.
Let's document that people should not use GCC 3.4 on Cygwin.
Where is the best place to document this?
I will document that in etc/PROBLEMS.
Eli Zaretskii
2006-11-04 12:12:34 UTC
Permalink
Date: Mon, 30 Oct 2006 23:06:04 +0200
Date: Mon, 30 Oct 2006 14:16:28 -0500
Post by Angelo Graziosi
GCC-3.4.4-(1/2) Segment fault
GCC-4.0.3 OK
GCC-4.1.1 OK
GCC-4.2-20061024(prerelease) M-x undefined
GCC-4.3-20061022(experim.) M-x undefined
In conclusion on Cygwin only the build with GCC-4.0.3 and > 4.1.1 seem to
work fine.
Let's document that people should not use GCC 3.4 on Cygwin.
Where is the best place to document this?
I will document that in etc/PROBLEMS.
Done.
Angelo Graziosi
2006-11-21 01:28:38 UTC
Permalink
I'm the maintainer for gnu emacs under Cygwin.
We are happy to hear that you are still the Cygwin mantainer of Emacs!

Have you recently 'frequented' the Cygwin lists ?

It is almost an year that Emacs is considered an 'orphaned' package!

(http://cygwin.com/ml/cygwin-apps/2005-10/msg00246.html,
http://sourceware.org/ml/cygwin-apps/2006-10/msg00017.html)



Cheers,

Angelo.
Angelo Graziosi
2006-11-21 01:46:24 UTC
Permalink
I'm the maintainer for gnu emacs under Cygwin.
Have you tried to build Emacs from CVS?

What about this

--------------------------------------------------------------------

....

Finding pointers to doc strings...
Finding pointers to doc strings...done
Dumping under the name emacs
Static heap usage: 10779888 of 12582912 bytes
66931 pure bytes used
mv -f emacs.exe bootstrap-emacs.exe
make[2]: Leaving directory `/tmp/emacs/.build/src'
(cd lisp; make -w bootstrap EMACS=../src/bootstrap-emacs.exe)
make[2]: Entering directory `/tmp/emacs/.build/lisp'
wd=/tmp/emacs/lisp; subdirs=`(cd $wd; find . -type d -print)`; for file in
$subdirs; do case $file in */Old | */RCS | */CVS | */CVS/* | */.* | */.*/*
| */=* ) ;; *) wins="$wins $wd/$file" ;; esac; done; \
for file in $wins; do \
/tmp/emacs/lisp/../update-subdirs $file; \
done;
wd=/tmp/emacs/lisp; subdirs=`(cd $wd; find . -type d -print)`; for file in
$subdirs; do case $file in */Old | */RCS | */CVS | */CVS/* | */.* | */.*/*
| */=* ) ;; *) wins="$wins $wd/$file" ;; esac; done; \
echo Directories: $wins; \
../src/bootstrap-emacs.exe -batch --no-site-file --multibyte -l
autoload --eval '(setq generated-autoload-file
"/tmp/emacs/lisp/loaddefs.el")' -f batch-update-autoloads $wins
Directories: /tmp/emacs/lisp/. /tmp/emacs/lisp/./calc
/tmp/emacs/lisp/./calendar /tmp/emacs/lisp/./emacs-lisp
/tmp/emacs/lisp/./emulation /tmp/emacs/lisp/./erc /tmp/emacs/lisp/./eshell
/tmp/emacs/lisp/./gnus /tmp/emacs/lisp/./international
/tmp/emacs/lisp/./language /tmp/emacs/lisp/./mail /tmp/emacs/lisp/./mh-e
/tmp/emacs/lisp/./net /tmp/emacs/lisp/./obsolete /tmp/emacs/lisp/./play
/tmp/emacs/lisp/./progmodes /tmp/emacs/lisp/./term
/tmp/emacs/lisp/./textmodes /tmp/emacs/lisp/./url
Fatal error (6)/bin/sh: line 2: 3596 Aborted (core
dumped) ../src/bootstrap-emacs.exe -batch --no-site-file --multibyte -l
autoload --eval '(setq generated-autoload-file
"/tmp/emacs/lisp/loaddefs.el")' -f batch-update-autoloads $wins
make[2]: *** [autoloads] Error 134
make[2]: Leaving directory `/tmp/emacs/.build/lisp'
make[1]: *** [bootstrap-build] Error 2
make[1]: Leaving directory `/tmp/emacs/.build'
make: *** [bootstrap] Error 2
--------------------------------------------------------------------


and similar failures that periodically come out in building under Cygwin?


Are your build 'stable' or 'segment fault's ?

The builds with gcc-4.0.3 seem very stable, those with gcc-3.4.4-1 (the
only GCC in Cygwin) seem very 'unstable'. What is your results?


Angelo.
Angelo Graziosi
2006-11-21 09:35:04 UTC
Permalink
I'm the maintainer for gnu emacs under Cygwin.
If you are the mantainer, do you know the problems that have afflicted the
Emacs-21.2-13/21.3.50-2 users in the last year?

The main problem is that after a 'rebaseall' Emacs hangs.

The workaround found was that after the rebase one should reinstall the
non rebased version of cygncurses7.dll of the libncurses7 package.

By the Cygwin mantainers it was suggested that the 'Emacs mantainer' had
to rebuild Emacs linking with the new libncurses (8), at least to verify
if this help.

In the meanwhile, why was it not released a CVS build of Emacs (at least
as exp. package, even if in Cygwin distribution there are package in
'curr' section that are taken from CVS, GDB e.g.)?


Angelo.
Angelo Graziosi
2006-11-22 14:49:08 UTC
Permalink
Iwant to flag this for the sake of completeness.


After amost a month of succeful daily build of Emacs-CVS (with GCC-4.0.3
very stable) the build fail in this way:


-------------------------------------------------------------------
....
Generating autoloads for mh-utils.el...
Generating autoloads for mh-utils.el...done
Generating autoloads for mh-xface.el...
Generating autoloads for mh-xface.el...done
Saving file
/home/Angelo/Downloads/cygwin_varie/emacs-cvs/emacs/lisp/mh-e/mh-loaddefs.el...
Wrote
/home/Angelo/Downloads/cygwin_varie/emacs-cvs/emacs/lisp/mh-e/mh-loaddefs.el
find /home/Angelo/Downloads/cygwin_varie/emacs-cvs/emacs/lisp -name
"*.elc" -print | xargs chmod +w >/dev/null 2>&1 || true; \

wd=/home/Angelo/Downloads/cygwin_varie/emacs-cvs/emacs/lisp; subdirs=`(cd
$wd; find . -type d -print)`; for file in $subdirs; do case $file in */Old
| */RCS | */CVS | */CVS/* | */.* | */.*/* | */=* ) ;; *) wins="$wins
$wd/$file" ;; esac; done; \
els=`echo $wins | tr ' \011' '\012\012' | \
sed -e 's|\(.\)$|\1/|' -e 's|^\./||' -e 's|$|*.el|'`; \
for el in
/home/Angelo/Downloads/cygwin_varie/emacs-cvs/emacs/lisp/emacs-lisp/byte-opt.el
/home/Angelo/Downloads/cygwin_varie/emacs-cvs/emacs/lisp/emacs-lisp/bytecomp.el
/home/Angelo/Downloads/cygwin_varie/emacs-cvs/emacs/lisp/subr.el
/home/Angelo/Downloads/cygwin_varie/emacs-cvs/emacs/lisp/progmodes/cc-mode.el
/home/Angelo/Downloads/cygwin_varie/emacs-cvs/emacs/lisp/progmodes/cc-vars.el
$els; do \
if test -f $el; \
then \
echo Compiling $el; \

EMACSLOADPATH=/home/Angelo/Downloads/cygwin_varie/emacs-cvs/emacs/lisp
../src/bootstrap-emacs.exe -batch --no-site-file --multibyte -f
batch-byte-compile-if-not-done $el || exit 1; \
fi \
done
Compiling
/home/Angelo/Downloads/cygwin_varie/emacs-cvs/emacs/lisp/emacs-lisp/byte-opt.el
Wrote
/home/Angelo/Downloads/cygwin_varie/emacs-cvs/emacs/lisp/emacs-lisp/byte-opt.elc
Compiling
/home/Angelo/Downloads/cygwin_varie/emacs-cvs/emacs/lisp/emacs-lisp/bytecomp.el

In end of data:
bytecomp.el:4204:1:Warning: the function `compilation-forget-errors' is
not
known to be defined.
Wrote
/home/Angelo/Downloads/cygwin_varie/emacs-cvs/emacs/lisp/emacs-lisp/bytecomp.elc
Compiling /home/Angelo/Downloads/cygwin_varie/emacs-cvs/emacs/lisp/subr.el
Fatal error (6)/bin/sh: line 4: 2196 Aborted (core
dumped) EMACSLOADPATH=/home/Angelo/Downloads/cygwin_varie/emacs-cvs/emacs/lisp
../src/bootstrap-emacs.exe -batch --no-site-file --multibyte -f
batch-byte-compile-if-not-done $el
make[2]: *** [compile] Error 1
make[2]: Leaving directory
`/home/Angelo/Downloads/cygwin_varie/emacs-cvs/emacs/.build/lisp'
make[1]: *** [bootstrap-build] Error 2
make[1]: Leaving directory
`/home/Angelo/Downloads/cygwin_varie/emacs-cvs/emacs/.build'
make: *** [bootstrap] Error 2

-------------------------------------------------------------------

This kind of error, periodically, comes out under Cygwin.



Its structure is alway the same:

Fatal error (6)/bin/sh: line <...>: <...> Aborted (core dumped)
EMACSLOADPATH=/home/Angelo/Downloads/cygwin_varie/emacs-cvs/emacs/lisp
../src/bootstrap-emacs.exe -batch --no-site-file --multibyte -f
batch-byte-compile-if-not-done $<...>.



Angelo.
Eli Zaretskii
2006-11-22 22:23:22 UTC
Permalink
Date: Wed, 22 Nov 2006 15:49:08 +0100 (MET)
Wrote /home/Angelo/Downloads/cygwin_varie/emacs-cvs/emacs/lisp/emacs-lisp/bytecomp.elc
Compiling /home/Angelo/Downloads/cygwin_varie/emacs-cvs/emacs/lisp/subr.el
Fatal error (6)/bin/sh: line 4: 2196 Aborted (core dumped) EMACSLOADPATH=/home/Angelo/Downloads/cygwin_varie/emacs-cvs/emacs/lisp
Does Cygwin GDB support core file (a.k.a. post-mortem) debugging? If
so, could you please type "gdb bootstrap-emacs.exe core" (assuming the
core file's name is `core'), and see where it crashes with the "bt"
command? Please run GDB from the src directory, to have it pick up
all the definitions in the .gdbinit file.

TIA
Angelo Graziosi
2006-11-23 00:07:40 UTC
Permalink
Post by Eli Zaretskii
Date: Wed, 22 Nov 2006 15:49:08 +0100 (MET)
Wrote /home/Angelo/Downloads/cygwin_varie/emacs-cvs/emacs/lisp/emacs-lisp/bytecomp.elc
Compiling /home/Angelo/Downloads/cygwin_varie/emacs-cvs/emacs/lisp/subr.el
Fatal error (6)/bin/sh: line 4: 2196 Aborted (core dumped) EMACSLOADPATH=/home/Angelo/Downloads/cygwin_varie/emacs-cvs/emacs/lisp
Does Cygwin GDB support core file (a.k.a. post-mortem) debugging?
I think NO: there is not a 'core' file. The failure creates a file in lisp
called 'bootstrap-emacs.exe.stackdump' which contains:

------------------------------------------------------------------
$ cat bootstrap-emacs.exe.stackdump
Stack trace:
Frame Function Args
0022A868 7C802532 (000006D0, 0000EA60, 000000A4, 0022A8B0)
0022A988 6109745C (00000000, 00000000, 00000000, 00000000)
0022AA78 61094FDB (00000000, 003B0023, 00230000, 00000000)
0022AAD8 610954BB (0022AAF0, 00000000, 00000094, 202EDC00)
0022AB98 61095672 (00000DB8, 00000006, 202DD801, 61017A53)
0022ABC8 61092AA8 (00000006, 60030000, 0022ACF8, 6109751C)
0022ACB8 61017B70 (000006D0, 0000EA60, 000000A4, 0022AD00)
0022ADD8 6109751C (00000000, 0022AED8, 20C3B800, 6101BE4E)
0022AEC8 61094FDB (00000000, 61167A20, 00000400, 61167A20)
0022AF28 610954BB (0022AF40, 00000000, 00000094, 0022AF88)
0022AFE8 61095672 (00000DB8, 00000006, 0022B018, 20151730)
0022AFF8 61092AA8 (00000000, 20CB0000, 0022B018, 20CD3000)
0022B018 20151730 (20CC0950, 211D0970, 00001AC0, 202DE004)
0022B058 201521A8 (FFFDD000, 203C0003, 0022B108, 20122139)
0022B0B8 20150951 (00004000, 202DD801, 0022B0F8, 200F28E5)
0022B0C8 200F2E3C (00004000, 203C001D, 0022D008, 0022B214)
End of stack trace (more stack frames may be present)
--------------------------------------------------------------



Trying your suggestion in any case, this is the result:

---------------------------------------------------------
$ gdb bootstrap-emacs.exe ../lisp/bootstrap-emacs.exe.stackdump
GNU gdb 6.5.50.20060706-cvs (cygwin-special)
Copyright (C) 2006 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 "i686-pc-cygwin"...
"/home/Angelo/Downloads/cygwin_varie/emacs-cvs/emacs/.build/src/../lisp/bootstrap-emacs.exe.stackdump" is
not a core dump: File format not recognized
DISPLAY = :0.0
TERM = xterm
Breakpoint 1 at 0x200a0b66: file
/home/Angelo/Downloads/cygwin_varie/emacs-cvs/emacs/src/emacs.c, line 464.
Breakpoint 2 at 0x200ba689: file
/home/Angelo/Downloads/cygwin_varie/emacs-cvs/emacs/src/sysdep.c, line
1385.
(gdb) bt
No stack.

Lisp Backtrace:
Cannot access memory at address 0x22c2f8
---------------------------------------------------------


As you can see GDB says 'bootstrap-emacs.exe.stackdump is not a core
dump'!



Angelo.
Post by Eli Zaretskii
If so, could you please type "gdb bootstrap-emacs.exe core" (assuming the
core file's name is `core'), and see where it crashes with the "bt"
command? Please run GDB from the src directory, to have it pick up
all the definitions in the .gdbinit file.
TIA
Eli Zaretskii
2006-11-23 04:15:13 UTC
Permalink
Date: Thu, 23 Nov 2006 01:07:40 +0100 (MET)
Post by Eli Zaretskii
Date: Wed, 22 Nov 2006 15:49:08 +0100 (MET)
Wrote /home/Angelo/Downloads/cygwin_varie/emacs-cvs/emacs/lisp/emacs-lisp/bytecomp.elc
Compiling /home/Angelo/Downloads/cygwin_varie/emacs-cvs/emacs/lisp/subr.el
Fatal error (6)/bin/sh: line 4: 2196 Aborted (core dumped) EMACSLOADPATH=/home/Angelo/Downloads/cygwin_varie/emacs-cvs/emacs/lisp
Does Cygwin GDB support core file (a.k.a. post-mortem) debugging?
I think NO: there is not a 'core' file. The failure creates a file in lisp
------------------------------------------------------------------
$ cat bootstrap-emacs.exe.stackdump
Frame Function Args
0022A868 7C802532 (000006D0, 0000EA60, 000000A4, 0022A8B0)
0022A988 6109745C (00000000, 00000000, 00000000, 00000000)
0022AA78 61094FDB (00000000, 003B0023, 00230000, 00000000)
0022AAD8 610954BB (0022AAF0, 00000000, 00000094, 202EDC00)
0022AB98 61095672 (00000DB8, 00000006, 202DD801, 61017A53)
0022ABC8 61092AA8 (00000006, 60030000, 0022ACF8, 6109751C)
0022ACB8 61017B70 (000006D0, 0000EA60, 000000A4, 0022AD00)
0022ADD8 6109751C (00000000, 0022AED8, 20C3B800, 6101BE4E)
0022AEC8 61094FDB (00000000, 61167A20, 00000400, 61167A20)
0022AF28 610954BB (0022AF40, 00000000, 00000094, 0022AF88)
0022AFE8 61095672 (00000DB8, 00000006, 0022B018, 20151730)
0022AFF8 61092AA8 (00000000, 20CB0000, 0022B018, 20CD3000)
0022B018 20151730 (20CC0950, 211D0970, 00001AC0, 202DE004)
0022B058 201521A8 (FFFDD000, 203C0003, 0022B108, 20122139)
0022B0B8 20150951 (00004000, 202DD801, 0022B0F8, 200F28E5)
0022B0C8 200F2E3C (00004000, 203C001D, 0022D008, 0022B214)
End of stack trace (more stack frames may be present)
--------------------------------------------------------------
Please ask Cygwin experts how to produce human-readable backtrace
information from this stackdump. There must be some utility in the
Cygwin collection to do that.

Maybe Cygwin also has a way of producing a real core file, in which
case please try using it to investigate these crashes.

TIA
Angelo Graziosi
2006-11-23 23:55:10 UTC
Permalink
Post by Eli Zaretskii
Maybe Cygwin also has a way of producing a real core file, in which
case please try using it to investigate these crashes.
Configuring the CYGWIN env. variable, when bootstrapping, it creates
lisp/bootstrap-emacs.exe.core, so I have tried the following (I am not a
very expert of GDB)

Using 'run' under GDB, it hangs and I must kill it:
---------------------------------------------------------------
$ gdb ./bootstrap-emacs.exe ../lisp/bootstrap-emacs.exe.core
GNU gdb 6.5.50.20060706-cvs (cygwin-special)
Copyright (C) 2006 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 "i686-pc-cygwin"...

warning: core file may not match specified executable file.

warning: Couldn't find general-purpose registers in core file.

warning: Couldn't find general-purpose registers in core file.
#0 0x00000000 in ?? ()
DISPLAY = :0.0
TERM = xterm
Breakpoint 1 at 0x200a0b66: file
/home/Angelo/Downloads/cygwin_varie/emacs-cvs/emacs/src/emacs.c, line 464.
Breakpoint 2 at 0x200ba689: file
/home/Angelo/Downloads/cygwin_varie/emacs-cvs/emacs/src/sysdep.c, line
1385.
(gdb) run
Starting
program: /home/Angelo/Downloads/cygwin_varie/emacs-cvs/emacs/.build/src/bootstrap-emacs.exe
-geometry 80x40+0+0
Loaded symbols for /c/WINDOWS/system32/ntdll.dll
Loaded symbols for /c/WINDOWS/system32/kernel32.dll
Loaded symbols for /usr/X11R6/bin/cygICE-6.dll
Loaded symbols for /usr/bin/cygwin1.dll
Loaded symbols for /c/WINDOWS/system32/advapi32.dll
Loaded symbols for /c/WINDOWS/system32/rpcrt4.dll
Loaded symbols for /usr/X11R6/bin/cygSM-6.dll
Loaded symbols for /usr/X11R6/bin/cygX11-6.dll
Loaded symbols for /usr/X11R6/bin/cygXaw3d-7.dll
Loaded symbols for /usr/X11R6/bin/cygXext-6.dll
Loaded symbols for /usr/X11R6/bin/cygXmu-6.dll
Loaded symbols for /usr/X11R6/bin/cygXt-6.dll
Loaded symbols for /usr/X11R6/bin/cygXpm-4.dll
Loaded symbols for /usr/bin/cygncurses-8.dll
Loaded symbols for /usr/bin/cygjpeg-62.dll
Loaded symbols for /usr/bin/cygpng12.dll
Loaded symbols for /usr/bin/cygz.dll
Loaded symbols for /usr/bin/cygtiff-5.dll
Loaded symbols for /usr/bin/cygungif-4.dll
warning: NOD32 protected [MSAFD Tcpip [TCP/IP]]
warning: NOD32 protected [MSAFD Tcpip [UDP/IP]]
warning: NOD32 protected [MSAFD Tcpip [RAW/IP]]
warning: NOD32 protected [RSVP UDP Service Provider]
warning: NOD32 protected [RSVP TCP Service Provider]


***** HERE IT HANGS ! ******


Program received signal SIGSEGV, Segmentation fault.
---Type <return> to continue, or q <return> to quit---[2]+ Killed
gdb ./bootstrap-emacs.exe ../lisp/bootstrap-emacs.exe.core
Killed
---------------------------------------------------------------



Using 'start', 'bt' and 'c' in GDB (after 'c' it hangs as above):
----------------------------------------------------------
$ gdb ./bootstrap-emacs.exe ../lisp/bootstrap-emacs.exe.core
GNU gdb 6.5.50.20060706-cvs (cygwin-special)
Copyright (C) 2006 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 "i686-pc-cygwin"...

warning: core file may not match specified executable file.

warning: Couldn't find general-purpose registers in core file.

warning: Couldn't find general-purpose registers in core file.
#0 0x00000000 in ?? ()
DISPLAY = :0.0
TERM = xterm
Breakpoint 1 at 0x200a0b66: file
/home/Angelo/Downloads/cygwin_varie/emacs-cvs/emacs/src/emacs.c, line 464.
Breakpoint 2 at 0x200ba689: file
/home/Angelo/Downloads/cygwin_varie/emacs-cvs/emacs/src/sysdep.c, line
1385.
(gdb) start
Breakpoint 3 at 0x200a1a4e: file
/home/Angelo/Downloads/cygwin_varie/emacs-cvs/emacs/src/emacs.c, line 837.
Starting
program: /home/Angelo/Downloads/cygwin_varie/emacs-cvs/emacs/.build/src/bootstrap-emacs.exe
-geometry 80x40+0+0
Loaded symbols for /c/WINDOWS/system32/ntdll.dll
Loaded symbols for /c/WINDOWS/system32/kernel32.dll
Loaded symbols for /usr/X11R6/bin/cygICE-6.dll
Loaded symbols for /usr/bin/cygwin1.dll
Loaded symbols for /c/WINDOWS/system32/advapi32.dll
Loaded symbols for /c/WINDOWS/system32/rpcrt4.dll
Loaded symbols for /usr/X11R6/bin/cygSM-6.dll
Loaded symbols for /usr/X11R6/bin/cygX11-6.dll
Loaded symbols for /usr/X11R6/bin/cygXaw3d-7.dll
Loaded symbols for /usr/X11R6/bin/cygXext-6.dll
Loaded symbols for /usr/X11R6/bin/cygXmu-6.dll
Loaded symbols for /usr/X11R6/bin/cygXt-6.dll
Loaded symbols for /usr/X11R6/bin/cygXpm-4.dll
Loaded symbols for /usr/bin/cygncurses-8.dll
Loaded symbols for /usr/bin/cygjpeg-62.dll
Loaded symbols for /usr/bin/cygpng12.dll
Loaded symbols for /usr/bin/cygz.dll
Loaded symbols for /usr/bin/cygtiff-5.dll
Loaded symbols for /usr/bin/cygungif-4.dll
main (argc=3, argv=0x202d3040)
at /home/Angelo/Downloads/cygwin_varie/emacs-cvs/emacs/src/emacs.c:837
837 {
(gdb) bt
#0 main (argc=3, argv=0x202d3040)
at /home/Angelo/Downloads/cygwin_varie/emacs-cvs/emacs/src/emacs.c:837

Lisp Backtrace:
0 (0x909090c3)
Cannot access memory at address 0x78746344
(gdb) q
The program is running. Exit anyway? (y or n) n
Not confirmed.
(gdb) c
Continuing.
warning: NOD32 protected [MSAFD Tcpip [TCP/IP]]
warning: NOD32 protected [MSAFD Tcpip [UDP/IP]]
warning: NOD32 protected [MSAFD Tcpip [RAW/IP]]
warning: NOD32 protected [RSVP UDP Service Provider]
warning: NOD32 protected [RSVP TCP Service Provider]

Program received signal SIGSEGV, Segmentation fault.
[Switching to thread 3136.0xc94]
0x00000000 in ?? ()
(gdb) Killed

----------------------------------------------------------


The results do not look very encouraging!


Angelo.
Eli Zaretskii
2006-11-24 21:17:51 UTC
Permalink
Date: Fri, 24 Nov 2006 00:55:10 +0100 (MET)
Configuring the CYGWIN env. variable, when bootstrapping, it creates
lisp/bootstrap-emacs.exe.core, so I have tried the following (I am not a
very expert of GDB)
---------------------------------------------------------------
$ gdb ./bootstrap-emacs.exe ../lisp/bootstrap-emacs.exe.core
GNU gdb 6.5.50.20060706-cvs (cygwin-special)
Copyright (C) 2006 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 "i686-pc-cygwin"...
warning: core file may not match specified executable file.
warning: Couldn't find general-purpose registers in core file.
warning: Couldn't find general-purpose registers in core file.
These 3 messages aren't a good sign.
#0 0x00000000 in ?? ()
DISPLAY = :0.0
TERM = xterm
Breakpoint 1 at 0x200a0b66: file
/home/Angelo/Downloads/cygwin_varie/emacs-cvs/emacs/src/emacs.c, line 464.
Breakpoint 2 at 0x200ba689: file
/home/Angelo/Downloads/cygwin_varie/emacs-cvs/emacs/src/sysdep.c, line
1385.
(gdb) run
No, you shouldn't run the program. You are debugging a core file,
which is an image of a dead program. Such a program cannot be run.
You can only examine the variables and memory. So the right command
is "bt".
Angelo Graziosi
2006-11-23 14:04:06 UTC
Permalink
I have asked and Cygwin suggests this:

http://cygwin.com/ml/cygwin/2006-11/msg00599.html
http://cygwin.com/ml/cygwin/2006-11/msg00600.html

I will try to understand deeply these suggestions to see how they work.

While waiting for the above answers I downloaded new CVS (which differ
very little from the previous), and now the build fails at the end of
installation, i.e. after the bootstrap!

---------------------------------------------------
...
ja-dic/CVS/Template
ja-dic/ja-dic.el
ja-dic/ja-dic.elc
unset CDPATH; \
if [ -n "/usr/bin/gzip" ]; \
then \
echo "Compressing *.el ..." ; \
(cd
/tmp/emacs/.inst/usr/local/emacs-cvs/share/emacs/22.0.91/leim; for f in
`find . -name "*.elc" -print`; do \
/usr/bin/gzip -9n `echo $f|sed 's/.elc$/.el/'` ; \
done) \
else true; fi
Compressing *.el ...
chmod -R a+r /tmp/emacs/.inst/usr/local/emacs-cvs/share/emacs/22.0.91/leim
make[1]: Leaving directory `/tmp/emacs/.build/leim'
cd lib-src; make maybe-blessmail \
MAKE='make'
archlibdir='/tmp/emacs/.inst/usr/local/emacs-cvs/libexec/emacs/22.0.91/i686-pc-cygwin'
make[1]: Entering directory `/tmp/emacs/.build/lib-src'
../src/emacs -batch -l /tmp/emacs/lib-src/../lisp/mail/blessmail.el
Fatal error (6)make[1]: *** [blessmail] Aborted (core dumped)
make[1]: Leaving directory `/tmp/emacs/.build/lib-src'
make: *** [blessmail] Error 2
---------------------------------------------------


When all works fine, the build is completed in this way
------------------------------------------------------
...
cd lib-src; make maybe-blessmail \
MAKE='make'
archlibdir='/home/Angelo/Downloads/cygwin_varie/emacs-cvs/
emacs/.inst/usr/local/emacs-cvs/libexec/emacs/22.0.90/i686-pc-cygwin'
make[1]: Entering directory
`/home/Angelo/Downloads/cygwin_varie/emacs-cvs/emacs
/.build/lib-src'
../src/emacs -batch -l
/home/Angelo/Downloads/cygwin_varie/emacs-cvs/emacs/lib-s
rc/../lisp/mail/blessmail.el
Wrote
/home/Angelo/Downloads/cygwin_varie/emacs-cvs/emacs/.build/lib-src/blessma
il
chmod +x blessmail
Assuming /usr/spool/mail is really the mail spool directory, you should
run lib-src/blessmail
/home/Angelo/Downloads/cygwin_varie/emacs-cvs/emacs/.inst/
usr/local/emacs-cvs/libexec/emacs/22.0.90/i686-pc-cygwin/movemail.exe
as root, to give movemail.exe appropriate permissions.
Do that after running make install.
make[1]: Leaving directory
`/home/Angelo/Downloads/cygwin_varie/emacs-cvs/emacs/
.build/lib-src'

Making the binary package...

===========================================
THE BUILD FINISHES AT 2006.11.18-15:12:52
===========================================
------------------------------------------------------




Cheers,

Angelo.
Post by Eli Zaretskii
Date: Thu, 23 Nov 2006 01:07:40 +0100 (MET)
Post by Eli Zaretskii
Date: Wed, 22 Nov 2006 15:49:08 +0100 (MET)
Wrote /home/Angelo/Downloads/cygwin_varie/emacs-cvs/emacs/lisp/emacs-lisp/bytecomp.elc
Compiling /home/Angelo/Downloads/cygwin_varie/emacs-cvs/emacs/lisp/subr.el
Fatal error (6)/bin/sh: line 4: 2196 Aborted (core dumped) EMACSLOADPATH=/home/Angelo/Downloads/cygwin_varie/emacs-cvs/emacs/lisp
Does Cygwin GDB support core file (a.k.a. post-mortem) debugging?
I think NO: there is not a 'core' file. The failure creates a file in lisp
------------------------------------------------------------------
$ cat bootstrap-emacs.exe.stackdump
Frame Function Args
0022A868 7C802532 (000006D0, 0000EA60, 000000A4, 0022A8B0)
0022A988 6109745C (00000000, 00000000, 00000000, 00000000)
0022AA78 61094FDB (00000000, 003B0023, 00230000, 00000000)
0022AAD8 610954BB (0022AAF0, 00000000, 00000094, 202EDC00)
0022AB98 61095672 (00000DB8, 00000006, 202DD801, 61017A53)
0022ABC8 61092AA8 (00000006, 60030000, 0022ACF8, 6109751C)
0022ACB8 61017B70 (000006D0, 0000EA60, 000000A4, 0022AD00)
0022ADD8 6109751C (00000000, 0022AED8, 20C3B800, 6101BE4E)
0022AEC8 61094FDB (00000000, 61167A20, 00000400, 61167A20)
0022AF28 610954BB (0022AF40, 00000000, 00000094, 0022AF88)
0022AFE8 61095672 (00000DB8, 00000006, 0022B018, 20151730)
0022AFF8 61092AA8 (00000000, 20CB0000, 0022B018, 20CD3000)
0022B018 20151730 (20CC0950, 211D0970, 00001AC0, 202DE004)
0022B058 201521A8 (FFFDD000, 203C0003, 0022B108, 20122139)
0022B0B8 20150951 (00004000, 202DD801, 0022B0F8, 200F28E5)
0022B0C8 200F2E3C (00004000, 203C001D, 0022D008, 0022B214)
End of stack trace (more stack frames may be present)
--------------------------------------------------------------
Please ask Cygwin experts how to produce human-readable backtrace
information from this stackdump. There must be some utility in the
Cygwin collection to do that.
Maybe Cygwin also has a way of producing a real core file, in which
case please try using it to investigate these crashes.
TIA
Angelo Graziosi
2006-11-24 23:32:42 UTC
Permalink
Post by Eli Zaretskii
Post by Angelo Graziosi
(gdb) run
No, you shouldn't run the program. You are debugging a core file,
which is an image of a dead program. Such a program cannot be run.
You can only examine the variables and memory. So the right command
is "bt".
I tried it, first, but I obtained only a "Cannot access memory at
address...", so I tried the others.

Meanwhile I have continued to build new CVS and now the build is completed
successfully!

The mystery is that also with previous CVS the problems cannot be
reproduced any more! This is what happens on Cygwin! On GNU/Linux I have
not found obstacles in build Emacs-CVS.



Thanks for your recent post on Cygwin lists.


Angelo.
Eli Zaretskii
2006-11-25 11:07:54 UTC
Permalink
Date: Sat, 25 Nov 2006 00:32:42 +0100 (MET)
Thanks for your recent post on Cygwin lists.
I just couldn't stand anymore the kind of unfriendly replies that are
evidently a norm on that list.

Angelo Graziosi
2006-11-25 09:52:42 UTC
Permalink
I post this only for the sake of completeness.


When the build fails as described
here: http://lists.gnu.org/archive/html/emacs-devel/2006-11/msg01214.html,
having activated the dumper.exe so that a core file is produced the
results are the following.

At the end of installation the build fails in this way:
-----------------------------------------------------------
...
ja-dic/CVS/Template
ja-dic/ja-dic.el
ja-dic/ja-dic.elc
unset CDPATH; \
if [ -n "/usr/bin/gzip" ]; \
then \
echo "Compressing *.el ..." ; \
(cd
/tmp/emacs/.inst/usr/local/emacs-cvs/share/emacs/22.0.91/leim; fo
r f in `find . -name "*.elc" -print`; do \
/usr/bin/gzip -9n `echo $f|sed 's/.elc$/.el/'` ; \
done) \
else true; fi
Compressing *.el ...
chmod -R a+r /tmp/emacs/.inst/usr/local/emacs-cvs/share/emacs/22.0.91/leim
make[1]: Leaving directory `/tmp/emacs/.build/leim'
cd lib-src; make maybe-blessmail \
MAKE='make'
archlibdir='/tmp/emacs/.inst/usr/local/emacs-cvs/libexec/e
macs/22.0.91/i686-pc-cygwin'
make[1]: Entering directory `/tmp/emacs/.build/lib-src'
../src/emacs -batch -l /tmp/emacs/lib-src/../lisp/mail/blessmail.el
Fatal error (6)*** starting debugger for pid 740, tid 2388
*** continuing pid 740 from debugger call (1)
make[1]: *** [blessmail] Aborted (core dumped)
make[1]: Leaving directory `/tmp/emacs/.build/lib-src'
make: *** [blessmail] Error 2
-----------------------------------------------------------

this creates a emacs.exe.core file of about 20MB.

Using GDB:
------------------------------------------------------------
/tmp/emacs/.build/src
$ gdb ./emacs.exe ../lib-src/emacs.exe.core
GNU gdb 6.5.50.20060706-cvs (cygwin-special)
Copyright (C) 2006 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 "i686-pc-cygwin"...

warning: core file may not match specified executable file.

warning: Couldn't find general-purpose registers in core file.

warning: Couldn't find general-purpose registers in core file.
#0 0x00000000 in ?? ()
Environment variable "DISPLAY" not defined.
TERM = cygwin
Breakpoint 1 at 0x200a0b66: file /tmp/emacs/src/emacs.c, line 464.
Breakpoint 2 at 0x200ba689: file /tmp/emacs/src/sysdep.c, line 1385.
(gdb) bt
#0 0x00000000 in ?? ()

Lisp Backtrace:
Cannot access memory at address 0x22c2f8
(gdb)

------------------------------------------------------------



Using the suggestion http://cygwin.com/ml/cygwin/2006-11/msg00657.html
------------------------------------------------------------------------
/tmp/emacs/.build/lib-src
$ awk '/^[0-9]/{print $2}' emacs.exe.stackdump | addr2line -f -e
../src/emacs.exe > /tmp/out

/tmp
cat out
??
??:0
??
??:0
??
??:0
??
??:0
??
??:0
??
??:0
??
??:0
??
??:0
??
??:0
??
??:0
??
??:0
??
??:0
relinquish
/tmp/emacs/src/ralloc.c:338
r_alloc_sbrk
/tmp/emacs/src/ralloc.c:934
_malloc_internal
/tmp/emacs/src/gmalloc.c:504
emacs_blocked_malloc
/tmp/emacs/src/alloc.c:1244
------------------------------------------------------------------------


Cheers,

Angelo.
Eli Zaretskii
2006-11-25 11:06:26 UTC
Permalink
Date: Sat, 25 Nov 2006 10:52:42 +0100 (MET)
relinquish
/tmp/emacs/src/ralloc.c:338
r_alloc_sbrk
/tmp/emacs/src/ralloc.c:934
_malloc_internal
/tmp/emacs/src/gmalloc.c:504
emacs_blocked_malloc
/tmp/emacs/src/alloc.c:1244
Looks like some problem with memory allocation. Several similar
crashes of the Cygwin port were reported during the last months, IIRC.
Continue reading on narkive:
Loading...