#590 server_event.lua: bad argument #4 to 'addevent'

Reporter Roi
Owner Zash
Created
Updated
Stars ★ (1)
Tags
  • Priority-Medium
  • Milestone-0.9
  • Type-Defect
  • Status-Fixed
  1. 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]: ?

  2. Zash on

    Changes
    • tag Status-Accepted
    • tag Milestone-0.9
  3. Zash on

    Do you have mod_limits enabled?

  4. 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.

  5. 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)

  6. Roi on

    Yes, mod_smacks is also active.

  7. Zash on

    Changes
    • owner Zash
    • tags Status-Started
  8. 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

  9. 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

  10. Zash on

    Fixed in http://hg.prosody.im/0.9/rev/56e65b1e54e8 and http://hg.prosody.im/0.9/rev/168d03dd09c7

    Changes
    • tags Status-Fixed

New comment

Not published. Used for spam prevention and optional update notifications.