Re: How to debug seed FTBFS on sparc?
On Thu, Feb 23, 2012 at 10:30:45AM +0000, 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::parseMemberExpression<JSC::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.
parseKeyword<true> (data=0xffffceb0, this=0xf57faba0) at ./Source/JavaScriptCore/KeywordLookup.h:201
201 ./Source/JavaScriptCore/KeywordLookup.h: No such file or directory.
(gdb) bt
#0 parseKeyword<true> (data=0xffffceb0, this=0xf57faba0) at ./Source/JavaScriptCore/KeywordLookup.h:201
#1 parseIdentifier<true> (strictMode=false, lexType=0, tokenData=0xffffceb0, this=0xf57faba0) at ../Source/JavaScriptCore/parser/Lexer.cpp:435
#2 JSC::Lexer::lex (this=0xf57faba0, tokenData=0xffffceb0, tokenInfo=0xffffceb8, lexType=0, strictMode=false) at ../Source/JavaScriptCore/parser/Lexer.cpp:1133
#3 0xf7a58ef4 in next (lexType=0, this=0xffffce60) at ../Source/JavaScriptCore/parser/JSParser.cpp:118
#4 consume (flags=0, expected=JSC::OPENPAREN, this=0xffffce60) at ../Source/JavaScriptCore/parser/JSParser.cpp:138
#5 parseArguments<JSC::ASTBuilder> (context=..., this=0xffffce60) 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(0x720000), %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 this happens is the tricky part :-).
Best regards,
--
Jurij Smakov jurij@wooyd.org
Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC
Reply to: