On Thu, Feb 23, 2012 at 10:30:45AM +, peter green wrote:
seed currently FTBFS on sparc with a bus error.
I've reproduced this on a sparc box that Tom Theisen made available
(thanks tom) but i'm kinda stuck on how to debug it.
Any ideas on how to debug this? Normally i'd start by turning down
the optimisation but this package doesn't seem to be using any in
the first place. I tried to use gdb but ran into issues with the
libtool wrapper scripts.
To find out which binary actually gets invoked by the wrapper script
you can change the first line of the script to
#! /bin/bash -x
The '-x' option will cause every command executed to be printed out.
After you run the crashing command you'll see this:
jurij@debian:~/seed/seed-3.2.0/doc/modules/readline$ ../../../src/seed
../../../doc/modules/make-functions.js ../../../doc/modules/readline/readline.js
[...]
+ func_exec_program_core ../../../doc/modules/make-functions.js
../../../doc/modules/readline/readline.js
+ test -n ''
+ exec /home/jurij/seed/seed-3.2.0/src/.libs/lt-seed
../../../doc/modules/make-functions.js ../../../doc/modules/readline/readline.js
Bus error
This is the binary:
jurij@debian:~/seed/seed-3.2.0/doc/modules/readline$ file
/home/jurij/seed/seed-3.2.0/src/.libs/lt-seed
/home/jurij/seed/seed-3.2.0/src/.libs/lt-seed: ELF 32-bit MSB executable,
SPARC32PLUS, V8+ Required, version 1 (SYSV), dynamically linked (uses shared
libs), for GNU/Linux 2.6.26,
BuildID[sha1]=0x06c16562047979adb84cd930e74723b3935b2cc8, not stripped
And the crash is still reproducible if it's run by hand:
jurij@debian:~/seed/seed-3.2.0/doc/modules/readline$
/home/jurij/seed/seed-3.2.0/src/.libs/lt-seed
../../../doc/modules/make-functions.js ../../../doc/modules/readline/readline.js
Bus error
Now gdb will give you a backtrace:
jurij@debian:~/seed/seed-3.2.0/doc/modules/readline$ gdb
/home/jurij/seed/seed-3.2.0/src/.libs/lt-seed
[...]
(gdb) run ../../../doc/modules/make-functions.js
../../../doc/modules/readline/readline.js
Starting program: /home/jurij/seed/seed-3.2.0/src/.libs/lt-seed
../../../doc/modules/make-functions.js
../../../doc/modules/readline/readline.js
[Thread debugging using libthread_db enabled]
Using host libthread_db library
/lib/sparc-linux-gnu/libthread_db.so.1.
[New Thread 0xf60e7b70 (LWP 10943)]
[New Thread 0xf57c3b70 (LWP 10944)]
Program received signal SIGBUS, Bus error.
0xf7a6a400 in JSC::Lexer::lex(JSC::JSTokenData*, JSC::JSTokenInfo*, unsigned
int, bool) () from /usr/lib/libjavascriptcoregtk-3.0.so.0
(gdb) bt
#0 0xf7a6a400 in JSC::Lexer::lex(JSC::JSTokenData*, JSC::JSTokenInfo*,
unsigned int, bool) () from /usr/lib/libjavascriptcoregtk-3.0.so.0
#1 0xf7a58ef4 in JSC::ASTBuilder::Expression
JSC::JSParser::parseMemberExpressionJSC::ASTBuilder(JSC::ASTBuilder) () from
/usr/lib/libjavascriptcoregtk-3.0.so.0
#2 0xf7a3deac in ?? () from /usr/lib/libjavascriptcoregtk-3.0.so.0
#3 0xf7a3deac in ?? () from /usr/lib/libjavascriptcoregtk-3.0.so.0
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
It's not a very useful one, but it points to
libjavascriptcoregtk-3.0.so.0 as the culprit and there is a
corresponding debug symbol package (libjavascriptcoregtk-3.0-0-dbg).
Installing it and running the binary under gdb again produces a much
more informative stack trace:
Program received signal SIGBUS, Bus error.
parseKeywordtrue (data=0xceb0, this=0xf57faba0) at
./Source/JavaScriptCore/KeywordLookup.h:201
201 ./Source/JavaScriptCore/KeywordLookup.h: No such file or directory.
(gdb) bt
#0 parseKeywordtrue (data=0xceb0, this=0xf57faba0) at
./Source/JavaScriptCore/KeywordLookup.h:201
#1 parseIdentifiertrue (strictMode=false, lexType=0, tokenData=0xceb0,
this=0xf57faba0) at ../Source/JavaScriptCore/parser/Lexer.cpp:435
#2 JSC::Lexer::lex (this=0xf57faba0, tokenData=0xceb0,
tokenInfo=0xceb8, lexType=0, strictMode=false) at
../Source/JavaScriptCore/parser/Lexer.cpp:1133
#3 0xf7a58ef4 in next (lexType=0, this=0xce60) at
../Source/JavaScriptCore/parser/JSParser.cpp:118
#4 consume (flags=0, expected=JSC::OPENPAREN, this=0xce60) at
../Source/JavaScriptCore/parser/JSParser.cpp:138
#5 parseArgumentsJSC::ASTBuilder (context=..., this=0xce60) at
../Source/JavaScriptCore/parser/JSParser.cpp:2250
[...]
'disassemble' command may be used to look up the assembler code around
the instruction which caused the crash:
0xf7a6a3f8 +5368: be,pn %icc, 0xf7a6c3f4
JSC::Lexer::lex(JSC::JSTokenData*, JSC::JSTokenInfo*, unsigned int,
bool)+13556
0xf7a6a3fc +5372: sethi %hi(0x72), %g3
= 0xf7a6a400 +5376: ld [ %l0 ], %g1
0xf7a6a404 +5380: or %g3, 0x65, %g4
0xf7a6a408 +5384: cmp %g1, %g4
The offending instruction tries to load a 4-byte word located at
address %l0 into %g1 register, so it's expected to be aligned on a
4-byte boundary, however it is obviously not:
(gdb) info reg l0
l0 0xf581f42e -176032722
(gdb)
Figuring out why
