#1313 mod_c2s error: attempt to call a field 'data' (a nil value)

Reporter Jagannathan Tiruvallur Eachambadi
Owner Zash
Created
Updated
Stars ★ (1)
Tags
  • Milestone-0.11
  • Status-Fixed
  • Priority-Medium
  • Type-Defect
  1. Jagannathan Tiruvallur Eachambadi on

    What steps will reproduce the problem? 1. Prosody crashes with this after a day of running but not sure what is triggering this. What do you see instead? Feb 04 05:49:22 general error Top-level error, please report: /usr/lib/prosody/modules/mod_c2s.lua:308: attempt to call field 'data' (a nil value) Feb 04 05:49:22 general error stack traceback: /usr/lib/prosody/modules/mod_c2s.lua:308: in function </usr/lib/prosody/modules/mod_c2s.lua:305> (...tail calls...) /usr/lib/prosody/net/server_select.lua:915: in function </usr/lib/prosody/net/server_select.lua:899> [C]: in function 'xpcall' /usr/bin/prosody:80: in function 'loop' /usr/bin/prosody:90: in main chunk [C]: in ? Feb 04 05:49:37 c2s4d1290 info Client disconnected: closed Feb 04 05:50:22 c2s70c4b0 info Client connected Feb 04 05:50:22 general error Top-level error, please report: /usr/lib/prosody/util/id.lua:16: bad argument #1 to 'base64_encode' (string expected, got nil) Feb 04 05:50:22 general error stack traceback: [C]: in function 'base64_encode' /usr/lib/prosody/util/id.lua:16: in function </usr/lib/prosody/util/id.lua:15> (...tail calls...) /usr/lib/prosody/util/async.lua:141: in function 'runner' /usr/lib/prosody/modules/mod_c2s.lua:275: in function </usr/lib/prosody/modules/mod_c2s.lua:240> (...tail calls...) /usr/lib/prosody/net/server_select.lua:915: in function </usr/lib/prosody/net/server_select.lua:899> [C]: in function 'xpcall' /usr/bin/prosody:80: in function 'loop' /usr/bin/prosody:90: in main chunk [C]: in ? What version of the product are you using? On what operating system? 0.11.2-1~stretch1 (debian 9) Please provide any additional information below. I enabled mod_smacks and mod_http_upload from community modules.

  2. Zash on

    Thanks for the report! This appears to be a failed read from /dev/urandom, where Prosody gets random bytes from. This should be impossible, /dev/urandom should by definition never block and always return data. Is Prosody running in some kind of constrained environment?

    Changes
    • tags Status-NeedInfo
  3. Jagannathan Tiruvallur Eachambadi on

    Yes it is running in a Illumos zone on Joyent. Not sure if it that should affect /dev/urandom. OT: I never seem to have got an email for this although I subscribed, going to try again.

  4. Zash on

    So what I believe happens here is that util.async fails to generate an identifier for the thread and produces the second traceback. This failure prevents creation of the sessions '.data()' method. Incoming data to this broken session later triggers the first traceback. I think we can affort a few sanity checks and tweaks to lower the impact of this. But there are limits to how much you can do if the platform doesn't keep to the promise of "/dev/urandom never blocks".

    Changes
    • owner Zash
    • tags Status-Started Milestone-0.11
  5. Zash on

    The "attempt to call field 'data'" traceback should be fixed by https://hg.prosody.im/trunk/rev/62d8689beafb Any error should prevent the now broken session from being associated with the connection, which should then eventually time out due to inactivity. The following commits https://hg.prosody.im/trunk/rev/5d2f7144fa12 ... https://hg.prosody.im/trunk/rev/af8c514e5cf7 should make the urandom read error more obvious. I'm not sure what else we can do about the underlying platform not behaving as specified. As mentioned in the chatroom, there is the (experimental) possibility of using a different randomness source, either the Linux getrandom(), the *BSD arc4random() or OpenSSL. `./configure --help` and look for `--with-random`.

    Changes
    • tags Status-Fixed

New comment

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