What steps will reproduce the problem?
1. Start a WvDBusServer application (e.g. dbus/tests/wvdbusd)
2. Make 2^32 connections to it - this takes just over 1.3 years at 100
connections/second, or 49.7 days at 1000 connections/second. Note: some
funny stuff might also happen halfway through, when it rolls from positive
to negative.
As a gauge, I managed to write a brutally stupid DBus connection spammer
that achieved over 600 TCP connections/second on my fairly pokey local
machine; I'm sure Unix domain sockets would be a fair bit faster (though
WvDBusServer doesn't support them just now), and there was a lot of WvLog
junk I didn't disable either, so this is a not-totally-infeasible scenario
if WvDBusServer were ever used in production.
What is the expected output? What do you see instead?
Expected: The unique name assigned to a connection by the bus remains
unique, as required by the DBus spec.
Actual: The counter used by the name generator in wvdbusconn.cc is just a
(signed) int. The real DBus server uses two unsigned 32-bit counters, and
creates names like ":1.2", where the first number increments when the
second one rolls over.
Please use labels and text to provide additional information.
Attached is my connection spammer; to build it, put it in dbus/tests and
run "make dbus/tests". It connects to localhost:5555.
Original issue reported on code.google.com by peter.mc...@gmail.com on 10 Jan 2008 at 12:36
Original issue reported on code.google.com by
peter.mc...@gmail.comon 10 Jan 2008 at 12:36Attachments: