Mailing List Archive

rsyslog core dump in getutent - possible race condition?
Hi,

The stack looks like

rsyslogd:core> ::stack 0
libc.so.1`fread+0x10()
libc.so.1`getutxent_frec+0x170()
libc.so.1`getutxent+0x18()
libc.so.1`getutent+0x64()
wallmsg+0x30()
actionCallDoAction+0x118()
processMsgMain+0x304()
doSubmitToActionQ+0x20c()
scriptExec+0x134()
scriptExec+0x4e0()
processBatch+0xbc()
msgConsumer+0x1b4()
ConsumerReg+0xac()
wtiWorker+0xb8()
wtpWorker+0xe4()
libc.so.1`_lwp_start()

The process core dumped because the fread did use NULL pointer as a file
descriptor. The utmpx_fd is -1. Normally getutent_frec would re-open the
utmpx_fd, but this seems that this did not happen.

The utmpx_fd address was found on stack of second thread

formatTimestamp3339+0x10()
getTimeReported+0x408()
strgen+8()
tplToString+0x24()
processMsgMain+0x2dc()
doSubmitToActionQ+0x20c()
scriptExec+0x134()
scriptExec+0x4e0()
processBatch+0xbc()
msgConsumer+0x1b4()
ConsumerReg+0xac()
wtiWorker+0xb8()
wtpWorker+0xe4()
libc.so.1`_lwp_start()

I do not see any other direct call to getutent. It might be a red
herring, but is there any chance that getutent / wallmsg could be called
in parallel in multiple threads?


Thank you
--
Vlad
_______________________________________________
rsyslog mailing list
https://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
What's up with rsyslog? Follow https://twitter.com/rgerhards
NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT.