David, an update: it still would be good if you could obtain the info I asked for below, but it would also useful to know (in addition) if the current v4-stable does experience the problem, too. v4-stable (and most probably the version you had) has code that is different in some key sections. So a test if it fails, too, actually tells more than I initially thought.
Please also note that I have seen a potential bug inside the new sanitation code, but I think it is very, very unlikely to be causing the problem. I'll address this starting in v4-devel so a re-test of that version would also be useful once it is there. I will post when I am done with the fixing. Rainer > -----Original Message----- > From: [email protected] [mailto:rsyslog- > [email protected]] On Behalf Of Rainer Gerhards > Sent: Wednesday, August 26, 2009 11:50 AM > To: rsyslog-users > Subject: Re: [rsyslog] abort in 4.2.1 > > David, > > one more thing. If you still have the core file, could you start up gdb > again > and then do > > (gdb) thread 1 > (gdb) print sanitizeMessage::pszMsg > (gdb) print sanitizeMessage::szSanBuf > (gdb) print sanitizeMessage::pMsg > (gdb) print *sanitizeMessage::pMsg # note the asterisk! > (gdb) print sanitizeMessage::iMaxLine > (gdb) print sanitizeMessage::maxDest > > The following ones likely will yield to no result as they are usually > optimized out (moved into registers): > (gdb) print sanitizeMessage::iSrc > (gdb) print sanitizeMessage::iDst > (gdb) print sanitizeMessage::pDst > > That will tell me if the pointers are ok, and what they actually point > to. > Based on the addresses I see, I guess that the message object pointer > provided is already invalid. But it is hard to verify without the > context... > > 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
