Irssi core bugs

Notice: Undefined index: tasklist_type in /var/www/ : eval()'d code on line 85 Notice: Undefined index: tasklist_type in /var/www/ : eval()'d code on line 90
  • Status Unconfirmed
  • Percent Complete
  • Task Type Bug Report
  • Category core
  • Assigned To No-one
  • Operating System Linux
  • Severity Medium
  • Priority Normal
  • Reported Version irssi 0.8.13
  • Due in Version Undecided
  • Due Date Undecided
  • Votes 0
  • Private No
Attached to Project: Irssi core bugs
Opened by ferret (ferret) - 2009-09-02

FS#701 - 'print text' signal has null pointer in arguments, causes segfault

Here's a fairly minimal script snippet that segfaults irssi-0.8.14

Irssi::signal_add 'print text' => sub {
my $foo = $_[0]->{server}{tag}; # crashes whole client

Comparing, assigning from, or doing anything with $_[0]->{server}{tag} causes a crash.

The following code does NOT crash:

Irssi::signal_add 'print text' => sub {
my $foo = $_[0]->{server};
my $bar = $foo->{tag};

This leads me to suspect that something in the C bit will try to dereference textdestrec->server to get to textdestrec->server->tag without checking if textdestrec->server is NULL. The fix is probably very simple, but I'm not familiar with how libperl stuff works.

This task does not depend on any other tasks.

Wouter Coekaerts (coekie)
Saturday, 05 September 2009, 08:05 GMT
This has nothing to do with C code trying to dereference NULL. It is the script that is 'trying' to crash, but the line being printed for the perl error recursively causes 'print text' handler, which then crashes again.
This crashes for the same reason as Irssi::signal_add 'print text' => sub {die 'foo'} or Irssi::signal_add 'print text' => sub {print 'foo'}.
In your case, the error it is trying to print is: Modification of non-creatable hash value attempted, subscript "server"

The scripting interface is not "safe": Irssi does not try to prevent scripts from doing bad things that cause crashes. Recursively causing signals like here is one of those bad things.
Wouter Coekaerts (coekie)
Saturday, 05 September 2009, 08:10 GMT
This is really a typical problem for the 'print text' signal. I've had to prevent this in several scripts of mine too, with something like this:
my $handling = 0;
Irssi::signal_add 'print text' => sub {
if (!$handling) {
$handling = 1;
... all of your handling here ...
$handling = 0;
Wouter Coekaerts (coekie)
Saturday, 05 September 2009, 08:12 GMT
I remember seeing a patch that removes signal handlers for a script that is crashing earlier. That should prevent a script from "crashing recursively" like that. But I can't find it right now.