[JDEV] non-unicode XML crashes jabberd

[Ralph Siemsen]

Martin Lesser wrote:

> Looks like. We disabled JUD on our productive Jabber-Server.  Should
> everyone running a productive server disable JUD?

I'm tempted to say "yes", however the actual problem has only been 
observed by a few people, so I guess it might be a bit too paranoid. 
The symptoms are pretty easy to spot: jabberd stops responding, consumes 
all the CPU, and there is a binary in the logfile where there should be 
plain text.  If someone sees these symptoms then remove the JUD.

>>The other observation about this problem is that shortly before the
>>server spirals into its endless loop, the log file shows that it tried
>>to access the global.xdb file (where JUD entries get stored); however
>>the first 8 bytes of the filename have been overwritten.
> 
> ... with a pointer (you said that on 09/09)

Hmm, right, i did say that.  But pointers on intel are 4 bytes (I deal 
with too many machine types...).  There are clearly 8 bytes being 
overwritten in the filename... I won't make any claim as to what those 
bytes are, except to say they are _not_ the filename.

Eg. It should read "/var/spool/jaber/jud/global.xdb" however instead I 
see in my log file: "decaching 0.$...*.ol/jabber/jud/global.xdb" where 
"." represents nonprinting characters.  Those 8 bytes in hex have the 
values: 30 1C 24 09 98 B6 2A 08.

If they were pointers that would be 0x09241c30 and 0x082ab698 
repectively.  Neither of those are valid addresses in any of my jabberd 
processes, so I suspect they are not pointers... sorry for the earlier 
claim as being such.
> We made another observation: After jabberd and jud crashed global.xdb
> was rewritten totally: All entries except the one of the user who
> crashed it did not exist any longer :-(

Wow, that is a departure from mine... our xdb file remained intact, at 
least, I didn't _notice_ that anything was lost from it.  This would 
imply to me that there might be race condition between multiple threads 
trying to write to the data file.  Something I hadn't really considered 
until now.

> Until now I only can say that the main trigger for this was a
> misconfigured client which had no appropriate locales so it sent
> xml-garbage.

Hmm, then we should be able to spot the garbled XML being transmitted 
with a packet sniffer.  I regularly run tcpdump and log _everything_, 
and I don't remember seeing anything that I'd consider invalid in the 
packets leading up to the crash.  Would like to be proven wrong though.

> The question also is whether it is not a waste of time to locate the
> problems or if it would be better to write a new (perhaps SQL-based)
> JUD as temas suggested?

Yep, maybe.  Not sure I'd go the SQL route, unless dealing with a really 
large (distributed) jabber server farm.  For single host systems, I 
think it would be easier to just keep everything in RAM, writing to disk 
only when there are changes made.  It would only take a few megabytes to 
  hold even a moderately sized user directory.  That should be pretty 
easy to implement as well.