uhlin / swirc Goto Github PK

Swirc Version: 3.3.1
OS: Windows 10 Home, Version 21H1, Build 19043.1237

Resizing the window leads to a fatal error and crashes the program:
term_resize_panel: newwin(1, 120, 0, 0): unable to create new window

A lot of rendering artifacts occur during the resizing, and the window always reverts itself back to the default size. Is this intended behavior?

See also video: https://streamable.com/avlnbi

Protocol fuzzing found the following reproducible crash:

(start netcat server with attached fuzzing data.)

nc -l 6667 <fuzz.log&

(start swirc)

gdb swirc
(gdb) run -c localhost -n x -u x -r x
Starting program: swirc -c brrpi02 -n x -u x -r x
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".
FATAL: In events/names.c: Can't find a window with label pp NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN

(crash backtrace)

Thread 3 "swirc" received signal SIGABRT, Aborted.
[Switching to Thread 0x752ff440 (LWP 12067)]
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
51 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#1 0x76925824 in __GI_abort () at abort.c:89
#2 0x00021d7c in hInstall (ctx=0x752fec14) at src/events/names.c:221
#3 0x00021e1c in event_names_htbl_insert (nick=0x74900f09 "c", channel=0x74901610 "pp ", 'N' <repeats 99 times>) at src/events/names.c:242
#4 0x0001c2cc in event_join (compo=0x74900c88) at src/events/channel.cpp:129
#5 0x0002f1a4 in irc_search_and_route_event (compo=0x74900c88) at src/irc.c:499
#6 0x0002f4e8 in ProcessProtoMsg (token=0x74900948 ":c JOIN pp ", 'N' <repeats 99 times>) at src/irc.c:552
#7 0x0002f7ec in irc_handle_interpret_events (recvbuffer=0x74900470 ":127.0.0.1 001 joseph :a", message_concat=0x752fedb8, state=0x752fedbc) at src/irc.c:646
#8 0x0003403c in net_irc_listen (connection_lost=0x752fee3b) at src/network.cpp:382
#9 0x00032230 in listenThread_fn (arg=0x0) at src/net-unix.c:150
#10 0x76c92fc4 in start_thread (arg=0x752ff440) at pthread_create.c:458
#11 0x769ca038 in ?? () at ../sysdeps/unix/sysv/linux/arm/clone.S:76 from /lib/arm-linux-gnueabihf/libc.so.6
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Are there any plans for Unicode support?

I do heave the headers installed, and compiled my ncurses with wchar support. merging the LINUX #if with OSX and BSD fixes the problem.

After updating I cannot run it anymore, getting Renamed executable dialog window.

Windows 10 x64 1803

Hi,

Looks like a promising project but it seems to lack some kind of window feature irssi or am I missing something?

Best regards,
Daniel

When a channel key is set, /cycle fails to use to key when rejoining, resulting in a failure to rejoin.

IRC protocol colon escaping seems to be done haphazardly. For example:

When a channel key containing a ":" is set, the ":" is erroneously stripped from display.

Server sending a "MODE #test +kl a:b :99" parses as: "mode/[#test] [+kl ab 99] by user". The ':' should not be stripped as part of a channel key, but it it is.

(Servers may allow a colon in the key as long as the colon is not the first character).

However, it is displayed on the status bar as [#test(+klnt a:b :99)]" which is also incorrect, as the ':' before 99 (last argument) should have been stripped here but is not.

When colon escaping is used in non-traditional places it seems to not always be escaped - for example, on inspircd (testnet.inspircd.org) channel modes are often misparsed, for example: "[#test(:+nt)]".

The practice of colon-escaping all final arguments, including those without spaces, is unusual but not in violation of the IRC RFC.

Hi,

ive found a bug in swirc, that i would prefer to report via e-mail instead of public github.

An email to bredband.net bounced back.

How can i proceed?

Kind regards,
Michael