[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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 
Starting program: /home/jurij/seed/seed-3.2.0/src/.libs/lt-seed 
[Thread debugging using libthread_db enabled]
Using host libthread_db library 
[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

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: