Hey,
I'm experiencing a crash with zinc since updating to the latest version today. Before, everything worked nicely.
Here's the debug log. The only external module I had been running was playback, although it wasn't even loaded on bitlbee (which somehow always was the one right before the crash).
Any ideas? I have no idea what to make of that message.
So... bitlbee sends a mode change with +Ct. According to CIRCSock::GetModeType, mode C has type ListArg, i.e. has an argument. However, no argument was sent. The STL debug features catch this attempt to go over the end of the argument list and aborts.
So, apparently ZNC is confused about the CHANMODES values of the server. No idea how this can happen, since I expect bitlbee to always send the same value (and ZNC treats unknown modes as NoArg). And a reconnect should end up with a new CIRCSock instance, so that also does not explain how things ended up in this situation.
@manavortex Are you always running ZNC under gdb or is this bug just easily reproducable for you? Could you perhaps provide some more information about how you are triggering this? Can you figure out what values bitlbee sends in its 005 numeric when znc connects to it?
(Also: The actual bug here (invalid mode change that has too few parameters for ZNC's taste) should definitely be fixed as well, I just do not understand how you hit this problem.)
```
[2019-09-25 11:16:59.490291] (manavortex/bitlbee) IRC -> ZNC [:ubuntu 324 manavortex &bitlbee +Ct]
[...]
#4 0x000000000071990e in CChan::ModeChange (this=0xb9c630, sModes=..., vsModes=std::__debug::vector of length 0, capacity 0, pOpNick=0x0) at src/Chan.cpp:392
[..]
cMode = @0x7fffffffc811: 67 'C'
```
So... bitlbee sends a mode change with `+Ct`. According to `CIRCSock::GetModeType`, mode `C` has type `ListArg`, i.e. has an argument. However, no argument was sent. The STL debug features catch this attempt to go over the end of the argument list and aborts.
https://github.com/znc/znc/blob/7b6a5641690a56ca3f5aea00160cfa8837fa50fa/src/Chan.cpp#L389-L393
A quick look at bitlbee's source code finds the following `CHANMODES` value:
https://github.com/bitlbee/bitlbee/blob/0b1448f070917daf4966097a06b47fc4b2ce0c92/irc_send.c#L47
According to this, bitlbee says that all modes are a setting and never have a parameter.
Also relevant: CMODES is `ntC`: https://github.com/bitlbee/bitlbee/blob/0b1448f070917daf4966097a06b47fc4b2ce0c92/irc.h#L41
So, apparently ZNC is confused about the `CHANMODES` values of the server. No idea how this can happen, since I expect bitlbee to always send the same value (and ZNC treats unknown modes as `NoArg`). And a reconnect should end up with a new `CIRCSock` instance, so that also does not explain how things ended up in this situation.
@manavortex Are you always running ZNC under gdb or is this bug just easily reproducable for you? Could you perhaps provide some more information about how you are triggering this? Can you figure out what values bitlbee sends in its 005 numeric when znc connects to it?
(Also: The actual bug here (invalid mode change that has too few parameters for ZNC's taste) should definitely be fixed as well, I just do not understand how you hit this problem.)
<!-- github-comment-id:535076761 -->
Hey,
I've started regularly been running znc forked to the background, but since it started crashing earlier today it's now running in a screen under gdb. So far it's alive, but I also disconnected the bitlbee server network.
As in how to reproduce: I updated znc and started it with my usual config. I'm running both it and bitlbee on my own virtual box, both are up-to-date. Since my facebook plugin broke, bitlbee is just connecting to steam and discord.
Both are built from source from a checkout of the corresponding repository's master.
Tell me how to provide information, and I'll do it - the debugging info on the wiki was just about the right level of dumb for me :D
Hey,
I've started regularly been running znc forked to the background, but since it started crashing earlier today it's now running in a screen under gdb. So far it's alive, but I also disconnected the bitlbee server network.
As in how to reproduce: I updated znc and started it with my usual config. I'm running both it and bitlbee on my own virtual box, both are up-to-date. Since my facebook plugin broke, bitlbee is just connecting to steam and discord.
Both are built from source from a checkout of the corresponding repository's master.
Tell me how to provide information, and I'll do it - the debugging info on the wiki was just about the right level of dumb for me :D
<!-- github-comment-id:535110093 -->
znc is on commit 7b6a564169, merge branch 1.7.x, of master.
bitlbee is on commit fe122f3fa913c5bbb64f8d815b4687df44c5d422, debian/copyright: some more copyright attribution fixups
Both are built from source and up-to-date on the corresponding repo's master.
znc is on commit 7b6a5641690a56ca3f5aea00160cfa8837fa50fa, merge branch 1.7.x, of master.
bitlbee is on commit fe122f3fa913c5bbb64f8d815b4687df44c5d422, debian/copyright: some more copyright attribution fixups
Both are built from source and up-to-date on the corresponding repo's master.
<!-- github-comment-id:535127521 -->
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.
Hey,
I'm experiencing a crash with zinc since updating to the latest version today. Before, everything worked nicely.
Here's the debug log. The only external module I had been running was playback, although it wasn't even loaded on bitlbee (which somehow always was the one right before the crash).
Any ideas? I have no idea what to make of that message.
So... bitlbee sends a mode change with
+Ct. According toCIRCSock::GetModeType, modeChas typeListArg, i.e. has an argument. However, no argument was sent. The STL debug features catch this attempt to go over the end of the argument list and aborts.https://github.com/znc/znc/blob/7b6a5641690a56ca3f5aea00160cfa8837fa50fa/src/Chan.cpp#L389-L393
A quick look at bitlbee's source code finds the following
CHANMODESvalue:https://github.com/bitlbee/bitlbee/blob/0b1448f070917daf4966097a06b47fc4b2ce0c92/irc_send.c#L47
According to this, bitlbee says that all modes are a setting and never have a parameter.
Also relevant: CMODES is
ntC: https://github.com/bitlbee/bitlbee/blob/0b1448f070917daf4966097a06b47fc4b2ce0c92/irc.h#L41So, apparently ZNC is confused about the
CHANMODESvalues of the server. No idea how this can happen, since I expect bitlbee to always send the same value (and ZNC treats unknown modes asNoArg). And a reconnect should end up with a newCIRCSockinstance, so that also does not explain how things ended up in this situation.@manavortex Are you always running ZNC under gdb or is this bug just easily reproducable for you? Could you perhaps provide some more information about how you are triggering this? Can you figure out what values bitlbee sends in its 005 numeric when znc connects to it?
(Also: The actual bug here (invalid mode change that has too few parameters for ZNC's taste) should definitely be fixed as well, I just do not understand how you hit this problem.)
Hey,
I've started regularly been running znc forked to the background, but since it started crashing earlier today it's now running in a screen under gdb. So far it's alive, but I also disconnected the bitlbee server network.
As in how to reproduce: I updated znc and started it with my usual config. I'm running both it and bitlbee on my own virtual box, both are up-to-date. Since my facebook plugin broke, bitlbee is just connecting to steam and discord.
Both are built from source from a checkout of the corresponding repository's master.
Tell me how to provide information, and I'll do it - the debugging info on the wiki was just about the right level of dumb for me :D
Please clarify which exact version do you mean as "latest".
znc is on commit
7b6a564169, merge branch 1.7.x, of master.bitlbee is on commit fe122f3fa913c5bbb64f8d815b4687df44c5d422, debian/copyright: some more copyright attribution fixups
Both are built from source and up-to-date on the corresponding repo's master.
This looks related to #1661
@linuxdaemon
Thank you :)