[llvm-testresults] Alpha nightly test

[Nicholas Riley]

On Fri, Apr 14, 2006 at 11:46:22AM -0500, Chris Lattner wrote:
> The ACM Alpha tester has been failing to build for quite some time.  Can 
> someone look into the problem or disable it please?
 
tblgen is segfaulting in Action's static constructor when compiled for
the release build (works fine in debug build).

It gets here, at least:

(gdb) bt
#0  0x0000020000037950 in __pthread_alt_unlock (lock=0x20000498b80)
    at pt-machine.h:104
#1  0x0000020000033ce0 in *__GI___pthread_mutex_unlock (mutex=0x20000498b68)
    at mutex.c:196
#2  0x0000020000399b64 in __libc_malloc (bytes=4064) at malloc.c:3319
#3  0x000002000020337c in operator new (sz=4064)
    at ../../../../src/libstdc++-v3/libsupc++/new_op.cc:48
#4  0x0000000120116368 in __gnu_cxx::__mt_alloc<std::pair<char const*, std::pair<ActionType, char const*> > >::allocate ()
#5  0x0000000120116688 in std::vector<std::pair<char const*, std::pair<ActionType, char const*> >, std::allocator<std::pair<char const*, std::pair<ActionType, char const*> > > >::_M_insert_aux ()
#6  0x000000012011691c in llvm::cl::apply<llvm::cl::ValuesClass<int>, llvm::cl::opt<ActionType, false, llvm::cl::parser<ActionType> > > ()
#7  0x0000000120112d30 in global constructors keyed to _ZN41_GLOBAL__N_TableGen.cpp_AAEE1AA9_8C14AE666ActionE ()
#8  0x0000000120137888 in __do_global_ctors_aux ()
#9  0x000000012003e428 in _init ()
#10 0x0000000120137734 in __libc_csu_init ()
#11 0x0000000120137734 in __libc_csu_init ()
#12 0x000000011ffffc08 in ?? ()
warning: Hit beginning of text section without finding
warning: enclosing function for address 0x11ffffc08
#13 0x0000000120137734 in __libc_csu_init ()
#14 0x000000011ffffc48 in ?? ()
warning: Hit beginning of text section without finding
warning: enclosing function for address 0x11ffffc48
#15 0x0000000120137734 in __libc_csu_init ()
#16 0x00000001200bc340 in PatternCodeEmitter::EmitResultCode ()
#17 0x0000000000000001 in ?? ()
Cannot access memory at address 0xfffffffffffffffd
(gdb) b mutex.c:197
Note: breakpoint 5 also set at pc 0x20000033cf4.
Breakpoint 6 at 0x20000033cf4: file mutex.c, line 197.
(gdb) c
Continuing.

Program received signal SIGSEGV, Segmentation fault.
Cannot access memory at address 0x200a11a000000000

(gdb) info break
Num Type           Disp Enb Address            What
1   breakpoint     keep y   0x000000012011900c <llvm::cl::generic_parser_base::findOption(char const*)+348>
        breakpoint already hit 1 time
4   breakpoint     keep y   0x0000020000033a00 in *__GI___pthread_mutex_lock
                                               at mutex.c:124
        breakpoint already hit 5 times
5   breakpoint     keep y   0x0000020000033cf4 in *__GI___pthread_mutex_unlock
                                               at mutex.c:199
        breakpoint already hit 2 times

I got the above by hitting breakpoint 1, then enabling breakpoint 4,
hitting it 5 times, then enabling breakpoint 5, hitting it twice, then
doing some noodling.  At this point I don't have any more time to
spend on this - it's very painful to do because you can't step through
the pthread locks (they're time-based, so they will hang forever).

It seems like it might be some bug in the thread-safe malloc or
linuxthreads.  We're upgrading wunderdog's kernel to 2.6.x in the near
future (after OpenAFS 1.4.1 is released), so it can use NPTL, at which
point the problem might disappear.

Andrew - fenris has a 2.6.x kernel on it right?  Does this problem
occur when compiling the release build?

Thanks.

-- 
Nicholas Riley <njriley at uiuc.edu> | <http://www.uiuc.edu/ph/www/njriley>