can't finish update: dpkg hangs installing xulrunner

[guy keren]

try to look back at the file, and see if this futex (0xb775e890) was
acquired earlier in the strace output, and not released. these futexes
are used to implement pthread mutexes, and if a an application attempts
to lock the same mutex twice - it will deadlock - and you'll see it
blocked on the underlying futex.

note: it's also possible that this futex call is used to implement a
different synchronization mechanism, which is persistent, and if an
application crashed while it held this lock - it could lead to a similar
deadlock.

note also that the PID of the process stuck on this futex is 10227,
while the PID of the original dpkg process is 10208 - so dpkg launched a
process which got stuck. looking back at the strace log file - you could
find what command this process executes.

--guy

On Sun, 2011-05-08 at 21:31 -0700, Michael Shiloh wrote:
> 
> On 05/08/2011 08:10 PM, guy keren wrote:
> > On Sun, 2011-05-08 at 17:04 -0700, Michael Shiloh wrote:
> >> apt-get update hangs at
> >>
> >> 	Setting up xulrunner-1.9.1
> >>
> >> I can kill this, but then I can't finish the update because it says that
> >> dpkg was interrupted. Trying to let dpkg repair with
> >>
> >> 	sudo dpkg --configure -a
> >>
> >> hangs setting up xulrunner so I'm stuck.
> >>
> >> Any ideas?
> >
> > what does strace tell you?
> >
> > i.e. run the program under 'strace -f -o /tmp/somefile.txt dpkg ...'
> >
> > and when it hangs - look in the file /tmp/somefile.txt, and see what is
> > it waiting for.
> 
> Good idea. I'm not quite sure how to understand the results. The file 
> starts with:
> 
> 10208 execve("/usr/bin/dpkg", ["dpkg", "--configure", "-a"], [/* 20 vars 
> */]) = 0
> 
> 
> and ends with:
> 
> 10227 set_robust_list(0xb775e900, 0xc)  = 0
> 10227 futex(0xbfd66510, FUTEX_WAKE_PRIVATE, 1) = 0
> 10227 futex(0xbfd66510, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 
> 1, NULL, bfd66520) = -1 EAGAIN (Resource temporarily unavailable)
> 10227 rt_sigaction(SIGRTMIN, {0x3196e0, [], SA_SIGINFO}, NULL, 8) = 0
> 10227 rt_sigaction(SIGRT_1, {0x319760, [], SA_RESTART|SA_SIGINFO}, NULL, 
> 8) = 0
> 10227 rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0
> 10227 getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, 
> rlim_max=RLIM_INFINITY}) = 0
> 10227 uname({sys="Linux", node="t60", ...}) = 0
> 10227 statfs64("/selinux", 84, {f_type="EXT2_SUPER_MAGIC", f_bsize=4096, 
> f_blocks=27662569, f_bfree=5190843, f_bavail=3785658, f_files=14057472, 
> f_ffree=13425663, f_fsid={-1774502679, 1875976236}, f_namelen=255, 
> f_frsize=4096}) = 0
> 10227 open("/proc/cpuinfo", O_RDONLY)   = 3
> 10227 read(3, "processor\t: 0\nvendor_id\t: Genuin"..., 1024) = 1024
> 10227 read(3, " no\nfpu\t\t: yes\nfpu_exception\t: y"..., 1024) = 382
> 10227 read(3, "", 1024)                 = 0
> 10227 close(3)                          = 0
> 10227 readlink("/etc/malloc.conf", 0xbfd64fab, 4096) = -1 ENOENT (No 
> such file or directory)
> 10227 mmap2(NULL, 1048576, PROT_READ|PROT_WRITE, 
> MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb765d000
> 10227 futex(0xb775e890, FUTEX_WAIT_PRIVATE, 2, NULL
> 
> 
> and that's the last line. It's been stucke there for awhile and no new 
> lines are added to the file, so it looks like that futex is what's 
> blocking. But why and what that means I don't know.
> 
> What do you think?