Running with assert switched on and debugging at level 9, -O2 and not
under valgrind gives the usual crash, this time after 3 hours 14 minutes.
It is the usual crash in m_away.c:88
Here is the tail of the output:
ENGINE: send queued for [vangogh.ath.cx]
Parsing [EMAIL PROTECTED]: :!4000 u
I compiled with -O0 in preparation for valgrind. That alone appears to
have fixed the issue, in that for the first time, the daemon has stayed
up for 15 hours. And with no valgrind-reported errors.
I'm now running standalone just to see if it is really fixed. So let me
get back to you in a
Rather an interesting one.
What strikes me is that AWAY verifies sptr-user is non-NULL before
it does anything. However just because sptr-user is non-NULL does
not mean it's valid memory space. Methinks a heap corruption.
What are you doing on the server prior to this occurring?
How long
Alasdair McWilliam wrote:
Rather an interesting one.
What strikes me is that AWAY verifies sptr-user is non-NULL before
it does anything. However just because sptr-user is non-NULL does
not mean it's valid memory space. Methinks a heap corruption.
What are you doing on the server prior
On Tue, Oct 04, 2005 at 10:46:21AM +0100, Philip Craig wrote:
What is different between my two setups (I run both servers under
rageircd) is that the good one is a single CPU AMD64, and the crashing
one is a dual Intel PIII.
Do you have the opportunity to retry on a known good machine, or at
Do you have the opportunity to retry on a known good machine, or at
least with the crashing one in single CPU mode?
I have booted the machine into single CPU mode, same kernel version. The
behaviour is exactly the same. One time it again broke at m_away.c line
88. Another time it broke at
On Tue, Oct 04, 2005 at 05:03:22PM +0100, Philip Craig wrote:
Do you have the opportunity to retry on a known good machine, or at
least with the crashing one in single CPU mode?
I have booted the machine into single CPU mode, same kernel version. The
behaviour is exactly the same.
That
Marc Haber wrote:
One time it again broke at m_away.c line
88. Another time it broke at m_away.c line 68
That, however, looks like that we have either _two_ bugs, or you have
a hardware issue. A single bug would most probnably show at the same
point .
Reading the code, it looked like it
PS. I can never actually re-create the issue; it happens at random.
I've found that if I wait for it to happen, it doesn't!!
On 4 Oct 2005, at 17:37, Philip Craig wrote:
Marc Haber wrote:
One time it again broke at m_away.c line 88. Another time it
broke at m_away.c line 68
That,
Phil,
I believe your observations are correct. That is, two manifestations
of the same bug.
I've had this problem for a number of months, as I said, on a FreeBSD
server. However we have an almost identical server (also running
FreeBSD) and the ircd has an uptime of almost six months.
Package: rageircd
Version: 2.0.1-1
Followup-For: Bug #331089
After a few hours, a debug version of the current release ended up here:
(gdb) run -t -V -c /etc/rageircd/rageircd.conf
Starting program: /usr/bin/rageircd -t -V -c /etc/rageircd/rageircd.conf
Attempting to open config file
11 matches
Mail list logo
