On Thu, 29 Jan 2009, Rainer Gerhards wrote: > Hi all, > > I had another interesting discussion with Lorenzo today. Those of you > interested in details my find the chatlog interesting: > > http://blog.gerhards.net/2009/01/some-more-on-rsyslog-data-race.html
so, distilling this down I think I am reading the following. 1. mixing mutex and atomic operations is a problem, one or the other is safe 2. reliable duplication of the problem requires fast machine multiple cores _not_ sharing L1 cache (early Intel 4-core machines or multi-socket machines) a complex rsyslog config that uses multiple thread heavily high traffic log volume to heavily load rsyslog high system load external to rsyslog increases the chancesof the race question, have you tried enabling/disabling preemption in the kernel on these systems to see if that affects the probability of having a problem? I'm eagerly waiting for the fixes to appear in the 4.1 branch to test them out. David Lang > Rainer > >> -----Original Message----- >> From: [email protected] [mailto:rsyslog- >> [email protected]] On Behalf Of Rainer Gerhards >> Sent: Wednesday, January 28, 2009 6:32 PM >> To: rsyslog-users >> Subject: Re: [rsyslog] rsyslog still crashes >> >> Hi all, >> >> thanks to Lorenzo's help, we made good progress. It is too much to > post >> inside a mail, please have a look at my analysis of the bug: >> >> http://blog.gerhards.net/2009/01/rsyslog-data-race-analysis.html >> >> The short story is that we have at least improved the situation very >> much and I hope to have fixes for all branches within the next couple >> of >> days. >> >> Rainer >> >>> -----Original Message----- >>> From: [email protected] [mailto:rsyslog- >>> [email protected]] On Behalf Of Rainer Gerhards >>> Sent: Friday, January 16, 2009 3:22 PM >>> To: rsyslog-users >>> Subject: Re: [rsyslog] rsyslog still crashes >>> >>> Lorenzo, >>> >>> I have created a new branch "raceDebug" and done a first commit to >> it. >>> The change is very lightweight. Please pull, compile as usual and >> give >>> it a try. It spits out some info to stdout from time to time >>> (hopefully). I am not sure if it aborts, depending on the output it >> may >>> or may not. Even if we get messages, they are probably not enough to >>> pinpoint the bug, but I wanted to do something very light to see if >> the >>> bug stays. >>> >>> Feedback appreciated. >>> >>> Rainer >> _______________________________________________ >> rsyslog mailing list >> http://lists.adiscon.net/mailman/listinfo/rsyslog >> http://www.rsyslog.com > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com
