#590 server_event.lua: bad argument #4 to 'addevent'
Reporter
Roi
Owner
Zash
Created
Updated
Stars
★ (1)
Tags
Status-Fixed
Type-Defect
Priority-Medium
Milestone-0.9
Roi
on
prosody-0.9 1nightly255-1~sid running on Debian amd64
Jan 14 14:05:26 general error Top-level error, please report:
/usr/lib/prosody/net/server_event.lua:293: bad argument #4 to 'addevent' (function expected, got nil)
Jan 14 14:05:26 general error
stack traceback:
/usr/bin/prosody:8389122: in function 'loop'
/usr/lib/prosody/net/server_event.lua:793: in function </usr/lib/prosody/net/server_event.lua:792>
[C]: in function 'xpcall'
/usr/bin/prosody:376: in function 'loop'
/usr/bin/prosody:407: in main chunk
[C]: ?
Zash
on
Changes
tagStatus-Accepted
tagMilestone-0.9
Zash
on
Do you have mod_limits enabled?
Roi
on
Yes it is enabled, here's the config:
limits = {
c2s = {
rate = "3kb/s";
burst = "2s";
};
s2sin = {
rate = "100kb/s";
burst = "5s";
};
}
Maybe these settings are a little bit outdated? If yes, let me know. I set this up because of transport spammers, MattJ suggested these settings.
Zash
on
Ge0rG reported the same trackeback in the chatroom, along with logs suggesting it was mod_limits and mod_smacks triggering an issue in server_event.
So do you also have mod_smacks? (The traceback mentions server_event, so 2/3)
Roi
on
Yes, mod_smacks is also active.
Zash
on
Changes
owner Zash
tags Status-Started
Zash
on
Eh, where did the patch I included go? Bug in bug tracker?
This should fix the traceback but mod_smacks and/or mod_limits will probably need some change to not interfere with each other.
diff -r 0386ccf20ac7 net/server_event.lua
--- a/net/server_event.lua Sun Jan 10 23:25:00 2016 +0100
+++ b/net/server_event.lua Mon Jan 18 16:39:59 2016 +0100
@@ -289,7 +289,7 @@ do
function interface_mt:resume()
self:_lock(self.nointerface, false, self.nowriting);
- if not self.eventread then
+ if self.readcallback and not self.eventread then
self.eventread = addevent( base, self.conn, EV_READ, self.readcallback, cfg.READ_TIMEOUT ); -- register callback
end
end
Zash
on
So my understanding of what happens is:
1. a session is disconnected while being throttled by mod_limits
2. mod_smacks prevents the session from being destroyed, it will keep the connection object attached
3. mod_limits resumes the connection after a bit
4. the read callback was removed when the connection was closed and :resume() needs this
5. boom, traceback
prosody-0.9 1nightly255-1~sid running on Debian amd64 Jan 14 14:05:26 general error Top-level error, please report: /usr/lib/prosody/net/server_event.lua:293: bad argument #4 to 'addevent' (function expected, got nil) Jan 14 14:05:26 general error stack traceback: /usr/bin/prosody:8389122: in function 'loop' /usr/lib/prosody/net/server_event.lua:793: in function </usr/lib/prosody/net/server_event.lua:792> [C]: in function 'xpcall' /usr/bin/prosody:376: in function 'loop' /usr/bin/prosody:407: in main chunk [C]: ?
Do you have mod_limits enabled?
Yes it is enabled, here's the config: limits = { c2s = { rate = "3kb/s"; burst = "2s"; }; s2sin = { rate = "100kb/s"; burst = "5s"; }; } Maybe these settings are a little bit outdated? If yes, let me know. I set this up because of transport spammers, MattJ suggested these settings.
Ge0rG reported the same trackeback in the chatroom, along with logs suggesting it was mod_limits and mod_smacks triggering an issue in server_event. So do you also have mod_smacks? (The traceback mentions server_event, so 2/3)
Yes, mod_smacks is also active.
Eh, where did the patch I included go? Bug in bug tracker? This should fix the traceback but mod_smacks and/or mod_limits will probably need some change to not interfere with each other. diff -r 0386ccf20ac7 net/server_event.lua --- a/net/server_event.lua Sun Jan 10 23:25:00 2016 +0100 +++ b/net/server_event.lua Mon Jan 18 16:39:59 2016 +0100 @@ -289,7 +289,7 @@ do function interface_mt:resume() self:_lock(self.nointerface, false, self.nowriting); - if not self.eventread then + if self.readcallback and not self.eventread then self.eventread = addevent( base, self.conn, EV_READ, self.readcallback, cfg.READ_TIMEOUT ); -- register callback end end
So my understanding of what happens is: 1. a session is disconnected while being throttled by mod_limits 2. mod_smacks prevents the session from being destroyed, it will keep the connection object attached 3. mod_limits resumes the connection after a bit 4. the read callback was removed when the connection was closed and :resume() needs this 5. boom, traceback
Fixed in http://hg.prosody.im/0.9/rev/56e65b1e54e8 and http://hg.prosody.im/0.9/rev/168d03dd09c7
Changes