[JDEV] non-unicode XML crashes jabberd
Ralph Siemsen
ralphs at blueairnetworks.com
Tue Sep 17 08:02:20 CDT 2002
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.
More information about the JDev
mailing list