Re: bind fails with sig11 on start / pthread failure on ARM?

Bernd Walter wrote:
> On Fri, Feb 19, 2010 at 01:29:03PM +0100, Grzegorz Bernacki wrote:
>> Bernd Walter wrote:
>>> On Fri, Feb 19, 2010 at 05:12:06AM +0100, Bernd Walter wrote:
>>>> On Thu, Feb 18, 2010 at 08:47:39PM -0700, M. Warner Losh wrote:
>>>>> In message: <20100219033000.GZ43625_at_cicely7.cicely.de>
>>>>>            Bernd Walter <ticso_at_cicely7.cicely.de> writes:
>>>>> : Warner - it names you in the copyright, so very likely you know this 
>>>>> code.
>>>>> : I will build a debug version of bind, but as usual it will take some
>>>>> : time...
>>>>>
>>>>> Make sure that the code matches our current atomics code...
>>>> There are just 3 functions.
>>>> isc_atomic_xadd and isc_atomic_store just wrap to atomic_fetchadd_int and
>>>> atomic_store_rel_int
>>>> isc_atomic_cmpxchg is inline assembly, but I don't think we have such a
>>>> function in our ARM atomic.h - at least I can't find it.
>>> #0  0x0015521c in isc_atomic_cmpxchg (p=0x155214, cmpval=0, val=1) at 
>>> atomic.h:75
>>> 75      }
>>> [New Thread 20804500 (LWP 100100)]
>>> [New Thread 208043c0 (LWP 100099)]
>>> [New Thread 20804280 (LWP 100098)]
>>> [New Thread 20804140 (LWP 100043)]
>>> (gdb) bt
>>> #0  0x0015521c in isc_atomic_cmpxchg (p=0x155214, cmpval=0, val=1) at 
>>> atomic.h:75
>>> #1  0x00155a20 in isc_rwlock_lock (rwl=0x1c0fd4, type=isc_rwlocktype_write)
>>>    at 
>>>    /data/builder/arm-current/head/lib/bind/isc/../../../contrib/bind9/lib/isc/rwlock.c:325
>>> #2  0x000f8144 in dns_db_register (name=0x173fe8 "_builtin", 
>>> create=0x4d46c <dns_sdb_create>, driverarg=0x2092b078, 
>>>    mctx=0x2080e0c0, dbimp=0x2092b08c) at 
>>>    /data/builder/arm-current/head/lib/bind/dns/../../../contrib/bind9/lib/dns/db.c:821
>>> #3  0x0004d0b4 in dns_sdb_register (drivername=0x173fe8 "_builtin", 
>>> methods=Variable "methods" is not available.
>>> )
>>>    at 
>>>    /data/builder/arm-current/head/lib/bind/dns/../../../contrib/bind9/lib/dns/sdb.c:239
>>> #4  0x0000c96c in ns_builtin_init () at 
>>> /data/builder/arm-current/head/usr.sbin/named/../../contrib/bind9/bin/named/builtin.c:296
>>> #5  0x0001a97c in $a () at 
>>> /data/builder/arm-current/head/usr.sbin/named/../../contrib/bind9/bin/named/main.c:741
>>> #6  0x0001a97c in $a () at 
>>> /data/builder/arm-current/head/usr.sbin/named/../../contrib/bind9/bin/named/main.c:741
>>> (gdb) print p
>>> $1 = (isc_int32_t *) 0x155214
>>> (gdb) print *p
>>> $2 = -498139128
>>> (gdb) 
>>>
>>> Initially it looks like a valid pointer.
>>> But it also looks like a pointer in codespace, which of course would be
>>> non-writeable and can't be updated.
>>>
>> Hi,
>>
>> Some time ago we changed an address of RAS. Probably that's the problem. 
>> Please try
>> with patch below.
> 
> I will try, but if p really points to codespace it should be a problem
> in a any of the calling functions.
> 

I think that gdb is lying. Function isc_rwlock_lock() calls isc_atomic_cmpxchg() like that:
isc_atomic_cmpxchg(&rwl->cnt_and_flag, 0, WRITER_ACTIVE);
rwl=0x1c0fd4 as you can see in backtrace above and cnt_and_flag is at offset 0x10 in rwl,
so address of rwl->cnt_and_flag should be 0x1c0fd4+0x10 not 0x155214. Address of rwl 
should be in .bss section and 0x1c0fd4 looks good for me, so in this case a believe that 
gdb says true.

At the begining of isc_atomic_cmpxchg() there is some like this:
<isc_atomic_cmpxchg+4>:      sub     r0, pc, #8      ; 0x8
it changes contents of r0 (which contained value of first parameter) to address of code, 
maybe gdb takes value of r0 and think that it contains value of first parameter.

grzesiek