[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Compiling ext2fs.static with pthreads

From: Thomas DiModica
Subject: Re: Compiling ext2fs.static with pthreads
Date: Wed, 15 Aug 2012 13:12:12 -0700 (PDT)

----- Original Message -----
From: Richard Braun <rbraun@sceen.net>
To: Thomas Thomas <ricinwich@yahoo.com>
Cc: bug-hurd@gnu.org
Sent: Wednesday, August 15, 2012 3:24 AM
Subject: Re: Compiling ext2fs.static with pthreads

>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

>> #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.

How I got around this was to apply Thomas Schwinge's fix_have_kernel_resources
branch to libpthread. Basically, the first thread structure allocated is not 
zeroed out,
so have_kernel_resources is some random non-zero number, and thus the thread
neither gets a wakeup port, nor does the kernel_thread member get initialized.
There may be other issues to work on.

Thomas D

reply via email to

[Prev in Thread] Current Thread [Next in Thread]