gdb-6.6-39.fc8 has been pushed to the Fedora 8 stable repository.  If problems still persist, please make note of it in this bug report.

I think #426615 should have been closed, not this.

(In reply to comment #2)
> I think #426615 should have been closed, not this.

Definitely. Would it be possible to upload core file somewhere? Also please tell
me if named consumes much CPU and memory when stops responding. Log messages and
named.conf will be also useful.

Thanks

I don't have a core file -- it was still running. Now that I have a working GDB
installed, how about I just let you poke at it directly? If you mail me a ssh
public key, I'll set you up with an account on the machine.

Same thing happened to me. ppc64 build gives a better info, as shown on
http://marc.info/?l=bind-users&m=120217756009100&w=2
Temporary workaround : rebuilt with --disable-atomic, and start named with -n 2
Server works fine after that.

Hm, this might be problem in ISC's implementation of atomic "exchange and add"
on PPC. Would it be possible test
http://people.redhat.com/atkac/test_srpms/bind-9.5.0-24.1.b1.fc8.src.rpm (source
rpm). Address of ppc F8 koji build will be added soon. Please tell me if you
still have problems.

http://koji.fedoraproject.org/koji/taskinfo?taskID=396508 - build for F8. Please
test ppc package, not ppc64. If you need specific build against some other OS
(different fedora etc) tell me it.

Testing it right now on a not-so-busy server. I've rebuild the SRPM for RHEL
5.1. Please provide RHEL5-build for further fixes :)
Why the ppc package, and not ppc64? We'd like to use ppc64 binary as it (should)
be able to use more memory for cache.

If you really need such much memory ppc64 binary makes sence for you. But ppc64
binaries are significantly slower than ppc32 binaries. Also I'm not sure if
patch for this issue will works on ppc64 because it's ppc assembler :) I need
know if problem is really in bind's atomic operations and if yes I will discuss
proper fix in upstream

Why do you say that ppc64 binaries are "significantly slower" than ppc32
binaries? That shouldn't be the case in general -- if it is, please file a bug
so that we can investigate. They're _slightly_ slower, because of the use of
function descriptors and the 'bloat' of 64-bit pointers and 'long' types. But
for the case where a single userspace process actually _wants_ more than 4GiB of
memory, that isn't entirely bloat. 

The same atomic functions should work for 32-bit and 64-bit code as long as they
get built in, although obviously they operate on 32-bit 'atomic' type only.
Since the function prototype indicates that the type is 'isc_int32_t', that
seems OK.

It looks like the original version of xadd can be given input values in r6, and
it will scribble on them before using them. The new version imported from glibc
won't do that -- but don't you also have to fix isc_atomic_cmpxhg() too, which
has the same problem?

(In reply to comment #10)
> It looks like the original version of xadd can be given input values in r6, and
> it will scribble on them before using them. The new version imported from glibc
> won't do that -- but don't you also have to fix isc_atomic_cmpxhg() too, which
> has the same problem?

I lie. GCC documentation promises that the clobbered register won't be used as
an input. So I don't see any problems with the existing routines.

The patch doesn't work as intended though. Named, ppc binary, simply stop
responding. On the other hand, the binary compiled with --disabled atomic is
still running correctly, so I believe the problem IS because of the atomic
operation.

(In reply to comment #12)
> The patch doesn't work as intended though. Named, ppc binary, simply stop
> responding. On the other hand, the binary compiled with --disabled atomic is
> still running correctly, so I believe the problem IS because of the atomic
> operation.

We checked disasembled code with David Woodhouse and it looks problem is not
directly in atomic operations. That's weird because this problem hits only ppc.
Please report if binary without atomic operation starts have same problems. I'm
going to discuss this with ISC.

Actually, we DO have a problem. We have two servers running bind 9.5.0b1, ppc,
without atomic. 

On one server, it dies, and on /var/log/messages I get this log :

Feb 13 04:01:15 <hostname here> out of memory [13668]

which SHOULD be normal, because max memory for 32bit userspace app is limited
(what is the limit BTW? 2G? 4G?). What makes it abnormal is that :
- named was consuming over 2G of memory (RES from htop)
- max-cache-size was set to 1G
- max-acache-size was set to 256M

It MIGHT be related to http://marc.info/?l=bind-users&m=119715064818829&w=2 , so
not really a ppc-specific problem

On the other server, hovewer, named simply dies (after about one week), no
message about memory error on /var/log/messages. How can I set named to log why
it dies, or to leave core dump if it crashed?

On a side note, these two cases are actually better than the one with atomic,
because in his case I can simply use some kind of supervised system to (re)start
named when it crashed.

(In reply to comment #14)
> which SHOULD be normal, because max memory for 32bit userspace app is limited
> (what is the limit BTW? 2G? 4G?). What makes it abnormal is that :
> - named was consuming over 2G of memory (RES from htop)
> - max-cache-size was set to 1G
> - max-acache-size was set to 256M

Pointers are 32bit so limit should be 4G. Btw as David Woodhouse wrote above you
will use ppc64 binary because atomic operations are same on both ppc and ppc64.
(Or if you disabled atomics there's also no problem with ppc64 binary)

> 
> It MIGHT be related to http://marc.info/?l=bind-users&m=119715064818829&w=2 , so
> not really a ppc-specific problem
> 
> On the other server, hovewer, named simply dies (after about one week), no
> message about memory error on /var/log/messages. How can I set named to log why
> it dies, or to leave core dump if it crashed?

This is quite problematic. BIND's working directory has to be writable. The best
way is set named working directory to /var/named/data (directory option in
options statement in named.conf) and modify all zone paths (add '../' to start
of each zone). If you have many zones you will simply 'chmod 775 /var/named' and
set SELinux policy appropriately. After segfault you will find corefile in
named's working directory.

Could someone verify this is still reproducable with latest BIND packages, please?

This message is a reminder that Fedora 8 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 8.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '8'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 8's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 8 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Fedora 8 changed to end-of-life (EOL) status on 2009-01-07. Fedora 8 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.