After some days of debbuging, I guess I've found the condition triggering
the problem.
1. A jabber client connects to the server and sends an in-band register
request
2. c2s sends the "create" message to sm
3. The jabber client then disconnect from server and another one makes a
new conection (using the same file descriptor as the previous one)
4. sm "created" answer arrives at c2s
5. The session found in the hash table is not what c2s expects,
sess->result is NULL, and this causes the assertion failure
Adding an extra verification will prevent this from happening. IMO, we
could change this in c2s.c:
-if(action >= 0 && NAD_AVAL_L(nad, action) == 7 && strncmp("created",
NAD_AVAL(nad, action), 7) == 0) {
+if(action >= 0 && NAD_AVAL_L(nad, action) == 7 && strncmp("created",
NAD_AVAL(nad, action), 7) == 0 && sess->result) {
What do you guys think about this ?
Best regards
2012/7/6 Clint Eastwood <[email protected]>
> Hi,
>
> I've been doing some tests on jabberd2 server under high load using
> Tsung<http://tsung.erlang-projects.org/>and I'm experiencing a behaviour that
> could be a bug.
> Under a 5 register requests per second scenario the c2s process is
> closing, creating the following backtrace:
>
> #0 0xb77c3424 in __kernel_vsyscall ()
> #1 0xb73d5c8f in raise () from /lib/i386-linux-gnu/libc.so.6
> #2 0xb73d92b5 in abort () from /lib/i386-linux-gnu/libc.so.6
> #3 0xb73ce826 in __assert_fail () from /lib/i386-linux-gnu/libc.so.6
> #4 0x08058516 in sx_nad_write_elem (s=0x92a21d0, nad=0x0, elem=0) at
> io.c:422
> #5 0x08054481 in c2s_router_sx_callback (s=0x927b0d8, e=event_PACKET,
> data=0x92a26c8, arg=0x9255028) at c2s.c:1037
> #6 0x0805b11c in __sx_event (file=0x806fdc4 "io.c", line=156,
> s=0x927b0d8, e=event_PACKET, data=0x92a26c8) at sx.c:340
> #7 0x08058a1a in _sx_process_read (s=0x927b0d8, buf=0x92a2970) at io.c:156
> #8 0x08059086 in sx_can_read (s=0x927b0d8) at io.c:243
> #9 0x080556e5 in c2s_router_mio_callback (m=0x927ab70, a=action_READ,
> fd=0x927ada8, data=0x0, arg=0x9255028) at c2s.c:1370
> #10 0x08062c11 in _mio_run (m=0x927ab70, timeout=5) at mio_impl.h:268
> #11 0x0804e831 in main (argc=4, argv=0xbfa78954) at main.c:788
>
> The version used for the tests is 2.2.16, which I downloaded and compiled
> by myself, on a Ubuntu 11.10 computer.
> It seems to me, that the issue is related to timing/synchronisation,
> because the time to trigger the problem is not always the same. Also, when
> I add a delay between the connection establishment and the register request
> the crash doesn't happen!
>
> The Tsung's XML file used on the test is attached.
>
> Regards
