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.

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?

• tags Status-NeedInfo

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.

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

• tags Status-Started Milestone-0.11
• owner Zash

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

• tags Status-Fixed