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 ju...@wooyd.org Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
