[OpenAFS-devel] Re: afsd-fuse segfaults

[Troy Benjegerdes]

damned heisenbugs. 

I added -ggdb to src/libuafs/Makefile, and it went away.
At least we fixed some makefile bugs.

My conclusion is the bug is some hidden dependency or the size of a
structure changed, and some file never got rebuilt to reflect it, or
something with adding roken, and now all the evidence of what actually
happened is gone.

If we are not going to enable 'make check' on the buildbots, then
is there any documentation on how I can set up my own buildbots that
do run make check?

Right now my 'script' for testing involves typing the following into
a terminal:

git pull 
./regen -q
./configure
make -j4
make check

or some variation thereof. 

I'd like to be building nightly, out of an AFS volume so I have a 
backup volume to refer to if something like this happens again.

On Tue, Sep 18, 2012 at 10:45:11AM -0400, Derrick Brashear wrote:
> > [New Thread 0x7ffff54d3700 (LWP 21044)]
> >
> > Program received signal SIGSEGV, Segmentation fault.
> > [Switching to Thread 0x7ffff697a700 (LWP 21033)]
> 
> I assume that's the pthread scheduler thread and the library support
> built on the system does not
> include symbols for it. More interestingly I assume 21044 is the
> interesting thread, because it was
> running memcpy when we crashed. So...
> 
> > 0x0000000000000000 in ?? ()
> > (gdb) bt
> > #0  0x0000000000000000 in ?? ()
> > #1  0x0000000000000000 in ?? ()
> > (gdb) thread
> > [Current thread is 2 (Thread 0x7ffff697a700 (LWP 21033))]
> > (gdb) help thread
> > Use this command to switch between threads.
> > The new thread ID must be currently known.
> >
> > List of thread subcommands:
> >
> > thread apply -- Apply a command to a list of threads
> > thread find -- Find threads that match a regular expression
> > thread name -- Set the current thread's name
> >
> > Type "help thread" followed by thread subcommand name for full documentation.
> > Type "apropos word" to search for commands related to "word".
> > Command name abbreviations are allowed if unambiguous.
> > (gdb) thread apply gdb
> > (gdb) thread apply bt
> > (gdb) thread apply bt all
> > (gdb) help thread apply
> > Apply a command to a list of threads.
> >
> > List of thread apply subcommands:
> >
> > thread apply all -- Apply a command to all threads
> >
> > Type "help thread apply" followed by thread apply subcommand name for full documentation.
> > Type "apropos word" to search for commands related to "word".
> > Command name abbreviations are allowed if unambiguous.
> > (gdb) thread apply all bt
> >
> > Thread 13 (Thread 0x7ffff54d3700 (LWP 21044)):
> > #0  __memcpy_ssse3 () at ../sysdeps/x86_64/multiarch/memcpy-ssse3.S:385
> > #1  0x000000000040402f in uafs_InitThread ()
> > #2  0x0000000000404075 in get_user_struct ()
> > #3  0x0000000000405c4d in call_syscall ()
> > #4  0x000000000040e79d in afsd_call_syscall ()
> > #5  0x000000000040ba6c in call_syscall_thread ()
> > #6  0x00007ffff7797b50 in start_thread (arg=<optimized out>) at pthread_create.c:304
> > #7  0x00007ffff6a5390d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
> > #8  0x0000000000000000 in ?? ()
> 
> Get a real line number for uafs_InitThread (you probably need to fix
> OPTF=-O2 in src/libuafs/Makefile or Makefile.common and remake
> libuafs;
> This is a bug I noticed last night and haven't fixed, namely, that
> --enable-debug doesn't override this.)
> 
> My offhand guess would be an alignment issue.
> 
> -- 
> Derrick
> _______________________________________________
> OpenAFS-devel mailing list
> OpenAFS-devel@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-devel