Re: Compiling ext2fs.static with pthreads

[Richard Braun]

On Tue, May 08, 2012 at 07:16:09PM -0700, Thomas Thomas wrote:
> So, it runs as a translator. Spews out some unexpected debugging info that 
> Barry
> added, but I can add files, delete files, list directories, etc. I haven't 
> tested it under
> load, however. Thank you for the link on debugging translators. I tried to 
> start a
> sub-hurd using it, but for some reason it gets to somewhere in libc while 
> trying to
> create its first thread and derefs a null pointer. I don't have complete 
> debugging info
> for where it falls apart. Here's the backtrace:

I have also reached this state with the branch we're working on. With
the fixed pthread_hurd_cond_wait_np, and the hack to reduce stack sizes,
I could also test the ext2fs server under load, without any particular
issue.

> #0 0x080d0366 in _hurd_sigstate_lock ()
> #1 0x0805a570 in __pthread_sigstate ()
> #2 0x080598d8 in __pthread_create_internal ()
> #3 0x08059b67 in pthread_create ()
> #4 0x0805b522 in diskfs_start_disk_pager (upi=0x81e0d48,
>     pager_bucket=0x81e0d58, may_cache=1, notify_on_evict=1, size=268435456,
>     image=0x81c1ec4) at disk-pager.c:60
> #5 0x08054036 in create_disk_pager () at pager.c:1203
> #6 0x0804826b in main (argc=7, argv=0x3ffe78) at ext2fs.c:186
> 
> and the offending instruction is (x/i $pc)
> 
> => 0x80d0366 <_hurd_sigstate_lock+70>: xchg %eax,0x4(%edx)

I'm also currently working on solving this.

> So, with (x/i $pc-8), I find
> 0x80d035e <_hurd_sigstate_lock+62>: mov $0x1,%eax
> This looks to me to be the mutex lock code, though I am not good at x86 
> assembly,
> and don't know where the previous instruction could be (but then again, no 
> one can).
> I want to blame cthreads dependencies in libc, because that is the easy 
> solution.

It's a spin lock actually. Here is _hurd_sigstate_lock :

void
_hurd_sigstate_lock (struct hurd_sigstate *ss)
{
  if (sigstate_is_global_rcv (ss))
    __spin_lock (&_hurd_global_sigstate->lock);
  __spin_lock (&ss->lock);
}

The problem is that _hurd_global_sigstate is NULL at this moment. It's
part of the global signal dispositions patch, and migrating Hurd servers
to pthreads means they now have to behave more POSIXely. The global
signal state is normally created by _hurdsig_init, but only if the proc
server exists (see hurd/hurdinit.c). Obviously, when used as a root file
system, this isn't the case.

What prevents _hurdsig_init from being called unconditionally and
earlier ?

-- 
Richard Braun