channel modes +Q make kill the ircd proccess

[WildClaudio]

+Q Strip QUIT/PART messages */ <-- when i set this channel mode on a channel and i part the channel with a message the ircd proccess is killed SIG_SERV error !!!
"CHMODE_Q" = "TRUE"; <-- ircd.conf line !!!

problem solved !!!

Program received signal SIGSEGV, Segmentation fault.
HasColor (text=0x0) at ircd_string.c:756
756 for (tmp = text; (*tmp); tmp++) {
#0 HasColor (text=0x0) at ircd_string.c:756

fixed by adding

if (text != NULL) { }
the code looks like this:

int HasColor(const char* text)
{
const char _tmp;
if (text != NULL) {
for (tmp = text; (_tmp); tmp++) {
if (_tmp & 224) continue;
switch (_tmp) {
case COLOR_BOLD:
case COLOR_REVERSE:
case COLOR_UNDERLINE:
case COLOR_ITALIC:
case COLOR_NORMAL:
case COLOR_COLOR:
return 1;
default:;
}
}
}
return 0;
}

[jobe1986]

Strictly speaking, if the QUIT/PART message is empty (NULL) then HasColor() should never be called to begin with. So the solution would be to prevent HasColor() being called.

Seeing as the current code currently does not allow a NULL pointer (0x0) to be passed to HasColor() from m_part.c and m_quit.c (the only places channel mode +Q affects the use of HasColor()) I am going to have to ask you for the FULL back trace for the crash please. And can you also tell me what exact revision of Nefarious 2 you are using please?

For example in m_part.c HasColor() is used as such (note the addtion of parts.jb_comment on its own to verify that it is a non-zero value and thus would not allow the back trace info you already provided to fit):
/* Strip PART message if color blocked and has color */
if ((chptr->mode.exmode & EXMODE_NOCOLOR) && parts.jb_comment && HasColor(parts.jb_comment))
parts.jb_comment = 0;

And in m_quit.c HasColor() is used (where one of the checks BadPrt() does is to ensure parv[parc - 1] is non-zero):
if (parc > 1 && !BadPtr(parv[parc - 1]) && !stripquit)
if (blockcolor && HasColor(parv[parc - 1]))
return exit_client(cptr, sptr, sptr, "Quit");

[WildClaudio]

i am using nefarious2 not the "-master" revision_with few changes/m_topic.c was haveing the same problem with colors but i saw in "-master" that you already fixed_ .... well the problem there that the quit/part "text" in hascolor ircd_string.c the other channel modes /notice/color/ctcp/ works fine..
for example when a user quits there will be always a mesage no ? Quit (Ping timeout) / Quit (Quit) this is not a quit/part message is a server message so was killing the proccess ...
here is the full debug
so i added additional check to do it if text is not null
(gdb) continue
Continuing.
Program received signal SIGSEGV, Segmentation fault.
HasColor (text=0x0) at ircd_string.c:756
756 for (tmp = text; (_tmp); tmp++) {
(gdb) bt
#0 HasColor (text=0x0) at ircd_string.c:756
#1 0x08086dda in m_part (cptr=0x223092b8, sptr=0x223092b8, parc=3, parv=0x81bbd80) at m_part.c:155
#2 0x0809dc43 in parse_client (cptr=0x223092b8, buffer=0x2230e13b "part", bufend=0x2230e14e "") at parse.c:1179
#3 0x0809d134 in client_dopacket (cptr=0x223092b8, length=19) at packet.c:180
#4 0x080a3913 in read_packet (cptr=0x223092b8, socket_ready=) at s_bsd.c:763
#5 0x080a4087 in client_sock_callback (ev=0x2235be58) at s_bsd.c:1061
#6 0x08062fa5 in event_execute (type=ET_READ, arg=0x2230e33c, data=0) at ircd_events.c:162
#7 event_generate (type=ET_READ, arg=0x2230e33c, data=0) at ircd_events.c:414
#8 0x080c2b68 in engine_loop (gen=0x81b6740) at engine_epoll.c:333
#9 0x08062c8f in event_loop () at ircd_events.c:378
#10 0x08060334 in main (argc=1, argv=0xbfb13284) at ircd.c:777
(gdb) frame 0
#0 HasColor (text=0x0) at ircd_string.c:756
756 for (tmp = text; (_tmp); tmp++) {
: (gdb) print tmp
$1 =
(gdb) print text
$2 = 0x0
(gdb) quit

[WildClaudio]

ohh and another one :) /mode channel +o nickname after the user gets @/op and i repeat the command , will always showing that i give @/op to that user even if the user is already opped.
[22:12:33] *** nickname sets mode: +o nickname2
[22:12:43] *** nickname sets mode: +o nickname2
[22:12:44] *** nickname sets mode: +o nickname2

[frootv]

ALLOW_OPLEVEL_CHANGE = FALSE and you will be fine ;)

[jobe1986]

Closing as I am unable to replicate.or even work out how the explanation even lead to the crash in question.