Bug 35743 - SyslogAppender throws a NullPointerException upon misconfiguration
Summary: SyslogAppender throws a NullPointerException upon misconfiguration
Alias: None
Product: Log4j - Now in Jira
Classification: Unclassified
Component: Appender (show other bugs)
Version: 1.2
Hardware: All All
: P2 normal
Target Milestone: ---
Assignee: log4j-dev
Depends on:
Reported: 2005-07-14 18:15 UTC by Mary Thornton
Modified: 2014-02-17 13:58 UTC (History)
1 user (show)


Note You need to log in before you can comment on or make changes to this bug.
Description Mary Thornton 2005-07-14 18:16:16 UTC
If the syslogappender is configured with a nonexistent syslog host, it will 
throw a nullpointerexception from the java.net.DatagramSocket.send() method 
through the SyslogWriter.write method.  This exception is thrown up through 
the application making the log call, which is not an appropriate outcome.
Comment 1 Yoav Shapira 2005-07-30 22:56:33 UTC
What do you suggest?  Checking to ensure the SysLog Host specified does exist,
and if not throwing an error at configuration time?  Just curious...
Comment 2 Mary Thornton 2005-08-05 01:05:46 UTC
I just thought logging a warning at configuration time as when there are no 
appenders found would be appropriate.  Your average log4j user, given a 
warning that the syslog host did not exist or something to that effect, could 
then track down the problem, and the application wouldn't explode because the 
logging was misconfigured.

I'm pretty sure that a logging tool should never throw errors back to an 
application.  Logging is almost never mission-critical.  I suppose someone 
could debate the point, but I think most people would agree.
Comment 3 John Morrissey 2005-10-28 02:51:08 UTC
I noticed the same thing recently. Specifying an unresolvable syslog server
results in a null InetAddress (SyslogWriter.address). SyslogWriter.flush() does
not check that ds.address is not null, so DatagramSocket.send() throws a

Sample exception output:

log4j:ERROR Could not find foo. All logging will FAIL.
java.net.UnknownHostException: foo: foo
        at java.net.InetAddress.getAllByName0(InetAddress.java:1011)
        at java.net.InetAddress.getAllByName0(InetAddress.java:981)
        at java.net.InetAddress.getAllByName(InetAddress.java:975) 
        at java.net.InetAddress.getByName(InetAddress.java:889)
        at org.apache.log4j.helpers.SyslogWriter.<init>(SyslogWriter.java:47)
        at net.horde.pv.PV.main(PV.java:87)

Exception in thread "main" java.lang.NullPointerException: null buffer || null
        at java.net.PlainDatagramSocketImpl.send(Native Method)
        at java.net.DatagramSocket.send(DatagramSocket.java:611)
        at org.apache.log4j.helpers.SyslogWriter.write(SyslogWriter.java:77)
        at org.apache.log4j.helpers.QuietWriter.write(QuietWriter.java:47)
        at org.apache.log4j.net.SyslogAppender.append(SyslogAppender.java:254)
        at org.apache.log4j.AppenderSkeleton.doAppend(AppenderSkeleton.java:230)
        at org.apache.log4j.Category.callAppenders(Category.java:203)
        at org.apache.log4j.Category.forcedLog(Category.java:388)
        at org.apache.log4j.Category.debug(Category.java:257)
        at net.horde.pv.PV.main(PV.java:114)

The following patch should prevent the exception:

Index: SyslogWriter.java
--- SyslogWriter.java   (revision 321351)
+++ SyslogWriter.java   (working copy)
@@ -79,7 +79,7 @@
     DatagramPacket packet =
       new DatagramPacket(bytes, bytes.length, address, SYSLOG_PORT);
-    if (this.ds != null) {
+    if (this.ds != null && this.address != null) {
     // clean up for next time
Comment 4 John Morrissey 2006-05-05 19:06:06 UTC
According to the latest revision at:


this problem still exists. This is marked NEEDINFO; is there any additional
information I can provide? Thanks!
Comment 5 Gregg Fowler 2006-07-24 13:42:14 UTC
Is any additional info needed?  I believe the patch he provided is correct. As
it stands, if the log host cannot be resolved, exceptions are thrown upon every
call to a log statement.
Comment 6 Curt Arnold 2006-08-01 19:37:24 UTC
Suggested remedy applied to log4j 1.2 branch in rev 427691 and trunk in rev 427690.