|
From: Jack U. <jd...@gm...> - 2006-12-23 23:55:20
|
I'm experiencing what appears to be stack corruption during a MinGW
build. This is with CVS latest as of today. My environment is:
WinXP SP2 / gcc 3.4.5 (mingw special) / libsigsegv 2.4
My configure command-line is:
CFLAGS="-g" ./configure --with-mingw --build build
--with-libsigsegv-prefix=/usr/local --with-module=bindings/win32
--with-module=gdi --with-module=dirkey --with-module=rawsock
--with-module=wildcard
This is the point during the build in which the crash happens:
[...snip preceding output...]
rm -f deprecated.lisp
ln -s ../src/deprecated.lisp deprecated.lisp
cp -p ../src/cfgwin32.lisp config.lisp
rm -f interpreted.mem
lisp.exe -B . -N locale -E 1:1 -Efile UTF-8 -Eterminal UTF-8 -norc -m 1800KW -x
"(and (load \"init.lisp\") (sys::%saveinitmem) (ext::exit)) (ext::exit t)"
i
i i i i I i i i i ooooo o ooooooo ooooo ooooo
I I I I I I I I I 8 8 8 8 8 o 8 8
I I \ `+' / I I 8 8 8 8 8 8
I \ `-+-' / I 8 8 8 ooooo 8oooo
\ `-__|__-' / 8 8 8 8 8
`--___|___--' 8 o 8 8 o 8 8
| ooooo 8oooooo ooo8ooo ooooo 8
--------+--------
*** - handle_fault error2 ! address = 0xce37cc88 not in [0x5ad70000,0x5ad70000)
!
SIGSEGV cannot be cured. Fault address = 0xce37cc88.
Permanently allocated: 88544 bytes.
Currently in use: 202300 bytes.
Free space: 321988 bytes.
make: *** [interpreted.mem] Error 5
When I run this stage under gdb, I get a stack trace that indicates
stack corruption with numerous stack frames showing addresses
0x00000000 and 0xffffffff and then this message from gdb:
Previous frame inner to this frame (corrupt stack?)
During compilation, I see the following warning issues for various files,
perhaps it's related?
lispbibl.d:9115: warning: register used for two global register variables
--
Jack Unrue
|
|
From: Sam S. <sd...@gn...> - 2006-12-26 03:02:00
|
> * Jack Unrue <wq...@tz...> [2006-12-23 16:55:18 -0700]: > > I'm experiencing what appears to be stack corruption during a MinGW > build. This is with CVS latest as of today. My environment is: > > WinXP SP2 / gcc 3.4.5 (mingw special) / libsigsegv 2.4 > > My configure command-line is: > > CFLAGS="-g" ./configure --with-mingw --build build > --with-libsigsegv-prefix=/usr/local --with-module=bindings/win32 > --with-module=gdi --with-module=dirkey --with-module=rawsock > --with-module=wildcard > > This is the point during the build in which the crash happens: > > [...snip preceding output...] > rm -f deprecated.lisp > ln -s ../src/deprecated.lisp deprecated.lisp > cp -p ../src/cfgwin32.lisp config.lisp > rm -f interpreted.mem > lisp.exe -B . -N locale -E 1:1 -Efile UTF-8 -Eterminal UTF-8 -norc -m 1800KW -x > "(and (load \"init.lisp\") (sys::%saveinitmem) (ext::exit)) (ext::exit t)" > i > i i i i I i i i i ooooo o ooooooo ooooo ooooo > I I I I I I I I I 8 8 8 8 8 o 8 8 > I I \ `+' / I I 8 8 8 8 8 8 > I \ `-+-' / I 8 8 8 ooooo 8oooo > \ `-__|__-' / 8 8 8 8 8 > `--___|___--' 8 o 8 8 o 8 8 > | ooooo 8oooooo ooo8ooo ooooo 8 > --------+-------- > > > *** - handle_fault error2 ! address = 0xce37cc88 not in [0x5ad70000,0x5ad70000) > ! > SIGSEGV cannot be cured. Fault address = 0xce37cc88. > Permanently allocated: 88544 bytes. > Currently in use: 202300 bytes. > Free space: 321988 bytes. > make: *** [interpreted.mem] Error 5 this i disturbing. could you please find out (by a binary search) which patch broke your build? you did build 2.41, right? > During compilation, I see the following warning issues for various files, > perhaps it's related? > > lispbibl.d:9115: warning: register used for two global register variables this is normal. -- Sam Steingold (http://sds.podval.org/) on Fedora Core release 6 (Zod) http://camera.org http://truepeace.org http://jihadwatch.org http://dhimmi.com http://ffii.org http://memri.org I just forgot my whole philosophy of life!!! |
|
From: Jack U. <jd...@gm...> - 2006-12-27 03:51:14
|
On 12/25/06, Sam Steingold <sd...@gn...> wrote: > > * Jack Unrue <wq...@tz...> [2006-12-23 16:55:18 -0700]: > > > > *** - handle_fault error2 ! address = 0xce37cc88 not in [0x5ad70000,0x5ad70000) > > ! > > SIGSEGV cannot be cured. Fault address = 0xce37cc88. > > Permanently allocated: 88544 bytes. > > Currently in use: 202300 bytes. > > Free space: 321988 bytes. > > make: *** [interpreted.mem] Error 5 > > this i disturbing. > could you please find out (by a binary search) which patch broke your > build? In progress... > you did build 2.41, right? Yes, and I have been regularly using the same MinGW build that I uploaded. -- Jack Unrue |
|
From: Jack U. <jd...@gm...> - 2006-12-27 05:24:24
|
I wrote: > On 12/25/06, Sam Steingold <sd...@gn...> wrote: > > > > this i disturbing. > > could you please find out (by a binary search) which patch broke your > > build? > > In progress... I went as far back as a CVS checkout from Aug. 1st and still see the build crash. I looked at src/ChangeLog to verify that I hadn't made a mistake in my checkout command-line. I'm reasonably sure that I have done a build from CVS at least once in the past few months since Aug. 1st. I downloaded the 2.41 tarball again, re-applied the patch that you (Sam) provided <http://article.gmane.org/gmane.lisp.clisp.general/11548/> and that build succeeds. At this point, I'm inclined to think this is an issue on my end, but I don't yet know what it could be. -- Jack Unrue |
|
From: Jack U. <jd...@gm...> - 2006-12-31 02:36:03
|
I wrote:
> On 12/25/06, Sam Steingold <sd...@gn...> wrote:
> >
> > this i disturbing.
> > could you please find out (by a binary search) which patch broke your
> > build?
>
> In progress...
After further investigation, I got a better stack trace (see the end
of this email) indicating a problem loading build/locale/en/LC_MESSAGES/clisp.mo
which is a symbolic link back to src/po/en.gmo
When I compare en.gmo from the official 2.41 release tarball with what
I'm getting from CVS (revision 1.20 is the latest and was tagged for the
release), the file sizes are different and a hexdump diff shows
what looks like end-of-line translation occurring at various file offsets.
The first 0x0a byte value in the version of en.gmo included in the
release tarfile is here:
0000220 941d 0000 000a 0000 9425 0000 0031 0000
compared to what I get from my CVS checkout:
0000220 941d 0000 0a0d 0000 2500 0094 3100 0000
The next 0x0a byte value occurs at
0003000 b484 0000 000a 0000 b4ef 0000 000c 0000
vs what I get from CVS:
0003000 0000 b484 0000 0a0d 0000 ef00 00b4 0c00
etc. etc.
Using 'cvs status' I see that the -kb sticky option is not
set on any of the *.gmo files in src/po
Here's a more informative stack trace for the crash that I originally
reported:
(gdb) run -B . -N locale -E 1:1 -Efile UTF-8 -Eterminal UTF-8 -norc -m 1800KW -x
"(and (load \"init.lisp\") (sys::%saveinitmem) (ext::exit)) (ext::exit t)"
Starting program: c:\projects\third_party\working-dirs\clisp\build/lisp.exe -B .
-N locale -E 1:1 -Efile UTF-8 -Eterminal UTF-8 -norc -m 1800KW -x "(and (load \
"init.lisp\") (sys::%saveinitmem) (ext::exit)) (ext::exit t)"
i i i i i i i ooooo o ooooooo ooooo ooooo
I I I I I I I 8 8 8 8 8 o 8 8
I \ `+' / I 8 8 8 8 8 8
\ `-+-' / 8 8 8 ooooo 8oooo
`-__|__-' 8 8 8 8 8
| 8 o 8 8 o 8 8
------+------ ooooo 8oooooo ooo8ooo ooooo 8
Program received signal SIGSEGV, Segmentation fault.
0x004c6a50 in _nl_find_msg (domain_file=0x3d7b48, domainbinding=0x3d50e8,
msgid=0x5804f0 "", convert=0, lengthp=0x22b9f4)
at ../../gettext-runtime/intl/gettextP.h:111
111 {
(gdb) backtrace
#0 0x004c6a50 in _nl_find_msg (domain_file=0x3d7b48, domainbinding=0x3d50e8,
msgid=0x5804f0 "", convert=0, lengthp=0x22b9f4)
at ../../gettext-runtime/intl/gettextP.h:111
#1 0x004c7aec in _nl_load_domain (domain_file=0x3d7b48,
domainbinding=0x3d50e8) at ../../gettext-runtime/intl/loadmsgcat.c:1283
#2 0x004c9eff in _nl_find_domain (
dirname=0x22bb20 "c:\\projects\\third_party\\working-dirs\\clisp\\build/loca
le", locale=0x22bad0 "en", domainname=0x22baf0 "LC_MESSAGES/clisp.mo",
domainbinding=0x3d50e8) at ../../gettext-runtime/intl/finddomain.c:172
#3 0x004c720b in libintl_dcigettext (domainname=0x4e596f "clisp",
msgid1=0x4f19c8 "Welcome to", msgid2=0x0, plural=0, n=0, category=1729)
at ../../gettext-runtime/intl/dcigettext.c:733
#4 0x004c6631 in libintl_dcgettext (domainname=0x4e596f "clisp",
msgid=0x4f19c8 "Welcome to", category=1729)
at ../../gettext-runtime/intl/dcgettext.c:49
#5 0x004c60e1 in libintl_dgettext (domainname=0x4e596f "clisp",
msgid=0x4f19c8 "Welcome to") at ../../gettext-runtime/intl/dgettext.c:52
#6 0x00407356 in clgettext ()
#7 0x0040cb8f in main_actions ()
#8 0x004110c0 in main ()
(gdb)
--
Jack Unrue
|
|
From: Sam S. <sd...@gn...> - 2006-12-31 15:58:52
|
> * Jack Unrue <wq...@tz...> [2006-12-30 19:36:02 -0700]: > > After further investigation, I got a better stack trace (see the end > of this email) indicating a problem loading build/locale/en/LC_MESSAGES/clisp.mo > which is a symbolic link back to src/po/en.gmo > > When I compare en.gmo from the official 2.41 release tarball with what > I'm getting from CVS (revision 1.20 is the latest and was tagged for > the release), the file sizes are different and a hexdump diff shows > what looks like end-of-line translation occurring at various file > offsets. Thanks Jack, I now did $ cvs admin -kb *.gmo could you please try again? Thanks! -- Sam Steingold (http://sds.podval.org/) on Fedora Core release 6 (Zod) http://palestinefacts.org http://thereligionofpeace.com http://ffii.org http://iris.org.il http://mideasttruth.com http://memri.org If your VCR is still blinking 12:00, you don't want Linux. |
|
From: Jack U. <jd...@gm...> - 2006-12-31 17:49:11
|
On 12/31/06, Sam Steingold <sd...@gn...> wrote: > > Thanks Jack, I now did > $ cvs admin -kb *.gmo > could you please try again? > Thanks! The crash is fixed :-) The streams test is failing. I'll backtrack and see which patch started causing this. DRIVEN% cat build/tests/*.erg Form: (LET ((IF "tmp-input=file") (OF "tmp-output=file")) (OPEN IF :DIRECTION :PROBE :IF-DOES-NOT-EXIST :CREATE) (UNWIND-PROTECT (WITH-OPEN-FILE (O OF :DIRECTION :OUTPUT) (WITH-OPEN-FILE (I IF :DIRECTION :INPUT) (WITH-OPEN-STREAM (2WAY (MAKE-TWO-WAY-STREAM I O)) (LIST (EQ (STREAM-EXTERNAL-FORMAT I) (STREAM-EXTERNAL-FORMAT O)) (EQ (STREAM-EXTERNAL-FORMAT I) (STREAM-EXTERNAL-FORMAT 2WAY)) (PROGN (SETF (STREAM-EXTERNAL-FORMAT I) :DOS (STREAM-EXTERNAL-FORMAT I) :MAC) (CONS (EQ (STREAM-EXTERNAL-FORMAT I) (STREAM-EXTERNAL-FORMAT O)) (STREAM-EXTERNAL-FORMAT 2WAY))) (PROGN (SETF (STREAM-EXTERNAL-FORMAT 2WAY :INPUT) :UNIX (STREAM-EXTERNAL-FORMAT 2WAY :OUTPUT) :UNIX) (ENCODING-LINE-TERMINATOR (STREAM-EXTERNAL-FORMAT 2WAY))) (EQ (STREAM-EXTERNAL-FORMAT I) (STREAM-EXTERNAL-FORMAT O)))))) (DELETE-FILE IF) (DELETE-FILE OF))) CORRECT: (T T (NIL . :DEFAULT) :UNIX T) CLISP : (T T (NIL . :DEFAULT) :DOS NIL) Differ at position 3: :UNIX vs :DOS CORRECT: (:UNIX T) CLISP : (:DOS NIL) -- Jack Unrue |
|
From: Sam S. <sd...@gn...> - 2006-12-31 18:28:03
|
> * Jack Unrue <wq...@tz...> [2006-12-31 10:49:10 -0700]: > > On 12/31/06, Sam Steingold <sd...@gn...> wrote: >> >> Thanks Jack, I now did >> $ cvs admin -kb *.gmo >> could you please try again? >> Thanks! > > The crash is fixed :-) thanks! > The streams test is failing. I'll backtrack and see which patch > started causing this. > > DRIVEN% cat build/tests/*.erg > Form: (LET ((IF "tmp-input=file") (OF "tmp-output=file")) (OPEN IF > :DIRECTION :PROBE :IF-DOES-NOT-EXIST :CREATE) (UNWIND-PROTECT > (WITH-OPEN-FILE (O OF :DIRECTION :OUTPUT) (WITH-OPEN-FILE (I IF > :DIRECTION :INPUT) (WITH-OPEN-STREAM (2WAY (MAKE-TWO-WAY-STREAM I O)) > (LIST (EQ (STREAM-EXTERNAL-FORMAT I) (STREAM-EXTERNAL-FORMAT O)) (EQ > (STREAM-EXTERNAL-FORMAT I) (STREAM-EXTERNAL-FORMAT 2WAY)) (PROGN (SETF > (STREAM-EXTERNAL-FORMAT I) :DOS (STREAM-EXTERNAL-FORMAT I) :MAC) (CONS > (EQ (STREAM-EXTERNAL-FORMAT I) (STREAM-EXTERNAL-FORMAT O)) > (STREAM-EXTERNAL-FORMAT 2WAY))) (PROGN (SETF (STREAM-EXTERNAL-FORMAT > 2WAY :INPUT) :UNIX (STREAM-EXTERNAL-FORMAT 2WAY :OUTPUT) :UNIX) > (ENCODING-LINE-TERMINATOR (STREAM-EXTERNAL-FORMAT 2WAY))) (EQ > (STREAM-EXTERNAL-FORMAT I) (STREAM-EXTERNAL-FORMAT O)))))) > (DELETE-FILE IF) (DELETE-FILE OF))) > CORRECT: (T T (NIL . :DEFAULT) :UNIX T) > CLISP : (T T (NIL . :DEFAULT) :DOS NIL) > Differ at position 3: :UNIX vs :DOS > CORRECT: (:UNIX T) > CLISP : (:DOS NIL) this is a new test, added on 2006-12-27. -- Sam Steingold (http://sds.podval.org/) on Fedora Core release 6 (Zod) http://palestinefacts.org http://truepeace.org http://camera.org http://iris.org.il http://thereligionofpeace.com http://memri.org Money does not "play a role", it writes the scenario. |