After reconnecting to ZNC it will hang sometimes and not complete connection (from either client or server). Connecting to the process via strace reveals:
funny, 0x1edf is 7903
which is the return value of write from the success of the first queued attempt
Either something in ZNC is not handling return values correctly, or something in OpenSSL isn't. I'm not quite sure where to look, though, and I'm not very familiar with C++ to make it through all the layers of indirection.
Additional notes from the log @Ttech just added:
```
funny, 0x1edf is 7903
which is the return value of write from the success of the first queued attempt
```
Either something in ZNC is not handling return values correctly, or something in OpenSSL isn't. I'm not quite sure where to look, though, and I'm not very familiar with C++ to make it through all the layers of indirection.
<!-- github-comment-id:72959305 -->
I use konversation, on a Debian testing.
Seems happen when connection hang (real) server side.
In my case when Freenode close one of it node, leading the socket to timeout when connecting.
I use konversation, on a Debian testing.
Seems happen when connection hang (real) server side.
In my case when Freenode close one of it node, leading the socket to timeout when connecting.
<!-- github-comment-id:74379449 -->
Also do you have zncstrap (which breaks at least network adding in 1.6.0) or any other custom patches?
I am not developer and I have no idea if this even goes anywhere, but I think list of modules might be a good idea in case there is something that people who are experiencing this have in common.
As this issue isn't happening to everyone, could you paste list of your loaded modules `/msg *status listmods`? (See https://help.github.com/articles/github-flavored-markdown/#fenced-code-blocks for making the output easier to read on this issue tracker).
Also do you have zncstrap (which breaks at least network adding in 1.6.0) or any other custom patches?
---
_I am not developer and I have no idea if this even goes anywhere, but I think list of modules might be a good idea in case there is something that people who are experiencing this have in common._
<!-- github-comment-id:75393764 -->
I don't have this issue, but I could probably still paste my modules for comparsion. With quick glance you seem to have awaystore and bouncedcc that I don't have.
Also experiencing this on Arch 1.6.0 - the module responsible is definitely bouncedcc - after disabling it on a user who had it enabled and restarting znc the issue has not come up again.
Also experiencing this on Arch 1.6.0 - the module responsible is definitely bouncedcc - after disabling it on a user who had it enabled and restarting znc the issue has not come up again.
<!-- github-comment-id:84333544 -->
Thanks @alexwh. That fixed it! I forgot to reply and close this issue, but I appreciate you posting the solution you found.
Thanks @alexwh. That fixed it! I forgot to reply and close this issue, but I appreciate you posting the solution you found.
<!-- github-comment-id:109339054 -->
Start gdb, enter attach 1234 (where 1234 is znc's PID), type bt and/or bt full, then detach and quit. For extra "fun", you could also repeat this a couple of times (something like attach, then get a backtrace, then cont to let znc continue, then ctrl+c to interrupt it again and bt to get another backtrace).
Since Csocket normally does not use recvfrom(), I wonder if that might have been a DNS thread? Could someone check if this is really the main thread that causes this? I don't have any good suggestions, but in gdb thread apply all bt gives a backtrace for all threads instead of just the current one.
The only "special" think that bouncedcc does might be throttling: If one ends sends data faster than the other end receives, it pauses reading from that "spammy end". Perhaps this code is involved and causes problems?
Could someone also try gdb instead of strace?
Start `gdb`, enter `attach 1234` (where 1234 is znc's PID), type `bt` and/or `bt full`, then `detach` and `quit`. For extra "fun", you could also repeat this a couple of times (something like attach, then get a backtrace, then `cont` to let znc continue, then ctrl+c to interrupt it again and `bt` to get another backtrace).
Since Csocket normally does not use `recvfrom()`, I wonder if that might have been a DNS thread? Could someone check if this is really the main thread that causes this? I don't have any good suggestions, but in gdb `thread apply all bt` gives a backtrace for all threads instead of just the current one.
The only "special" think that bouncedcc does might be throttling: If one ends sends data faster than the other end receives, it pauses reading from that "spammy end". Perhaps this code is involved and causes problems?
<!-- github-comment-id:111557374 -->
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
After reconnecting to ZNC it will hang sometimes and not complete connection (from either client or server). Connecting to the process via strace reveals:
so bit more info:
(snippet from logs)
This primarily happens when connecting to freenode, other networks are not affected as much.
--- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/8286849-znc-using-100-cpu-when-using-bouncedcc?utm_campaign=plugin&utm_content=tracker%2F1759&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F1759&utm_medium=issues&utm_source=github).ZNC version and OS?
Ah right, sorry about that.
ZNC 1.4 - IPv6: yes, SSL: yes, DNS: threads
Running on a ArchLinux box.
Additional notes from the log @Ttech just added:
Either something in ZNC is not handling return values correctly, or something in OpenSSL isn't. I'm not quite sure where to look, though, and I'm not very familiar with C++ to make it through all the layers of indirection.
Same problem here, for freenode too
ZNC 1.4-2, Debian testing, IPv6: yes, SSL: yes, DNS: threads
strace on the ZNC process leads to huuuuuuuuuuge spam like this and nothing else
@aeris what irc client do you use? is it on os x?
Seems to primarily happen only when connect via SSL.
I use konversation, on a Debian testing.
Seems happen when connection hang (real) server side.
In my case when Freenode close one of it node, leading the socket to timeout when connecting.
Can confirm this is still happening on ArchLinux -
OpenSSL 1.0.2 22 Jan 2015
ZNC - 1.6.0 - http://znc.in
As this issue isn't happening to everyone, could you paste list of your loaded modules
/msg *status listmods? (See https://help.github.com/articles/github-flavored-markdown/#fenced-code-blocks for making the output easier to read on this issue tracker).Also do you have zncstrap (which breaks at least network adding in 1.6.0) or any other custom patches?
I am not developer and I have no idea if this even goes anywhere, but I think list of modules might be a good idea in case there is something that people who are experiencing this have in common.
Here's the list of mods
I don't have this issue, but I could probably still paste my modules for comparsion. With quick glance you seem to have awaystore and bouncedcc that I don't have.
Also experiencing this on Arch 1.6.0 - the module responsible is definitely bouncedcc - after disabling it on a user who had it enabled and restarting znc the issue has not come up again.
Thanks @alexwh. That fixed it! I forgot to reply and close this issue, but I appreciate you posting the solution you found.
If the issue is bouncedcc, I don't think this issue should be closed until it's fixed as it comes with ZNC.
Could someone also try gdb instead of strace?
Start
gdb, enterattach 1234(where 1234 is znc's PID), typebtand/orbt full, thendetachandquit. For extra "fun", you could also repeat this a couple of times (something like attach, then get a backtrace, thencontto let znc continue, then ctrl+c to interrupt it again andbtto get another backtrace).Since Csocket normally does not use
recvfrom(), I wonder if that might have been a DNS thread? Could someone check if this is really the main thread that causes this? I don't have any good suggestions, but in gdbthread apply all btgives a backtrace for all threads instead of just the current one.The only "special" think that bouncedcc does might be throttling: If one ends sends data faster than the other end receives, it pauses reading from that "spammy end". Perhaps this code is involved and causes problems?