View Issue Details

IDProjectCategoryView StatusLast Update
0002115unrealircdpublic2004-10-08 21:59
ReporterMagicalTux Assigned To 
PrioritynormalSeveritycrashReproducibilityhave not tried
Status closedResolutionopen 
Product Version3.2.1 
Summary0002115: Crash on bad link blocks
DescriptionI had a bad link { } block which was for services (host *, port *, etc...) and I didn't notice that the option "autoconnect" was set.
Once I logged in as ircop I was flooded by notices :
[21:35:43] -Beta-IRC.FF.st- Bad hostname returned from 127.0.0.1 for 127.0.0.1
[21:35:43] -Beta-IRC.FF.st- *** Notice -- Hostname * is unknown for server MatrIRX.Beta-IRC.FF.st.
[21:35:43] -Beta-IRC.FF.st- *** Notice -- Host * unknown
[21:35:44] -Beta-IRC.FF.st- *** Notice -- Hostname * is unknown for server MatrIRX.Beta-IRC.FF.st.
[21:35:44] -Beta-IRC.FF.st- Bad hostname returned from 127.0.0.1 for 127.0.0.1
[21:35:44] -Beta-IRC.FF.st- Bad hostname returned from 127.0.0.1 for 127.0.0.1
[21:35:44] -Beta-IRC.FF.st- *** Notice -- Hostname * is unknown for server MatrIRX.Beta-IRC.FF.st.

So I immediatly fixed that in the config, and then issued a /rehash in the IRC window.

Here's the crash :
289 if ((*str = *p1))
(gdb) bt
#0 ircvsprintf (str=0x81dd277 "tion loaded without any problems ..\r\n", format=0xbfffe579 " is unknown for server %s.", vl=0xbfffe968 "-IRC\001") at ircsprintf.c:289
#1 0x080a69de in vsendto_one (to=0x828a8b8, pattern=0xbfffe540 ":Beta-IRC.FF.st NOTICE MT`AwAy :*** Notice -- Hostname %s is unknown for server %s.", vl=0xbfffe964 "st")
    at send.c:243
#2 0x080a8911 in sendto_realops (pattern=0x8131260 "Hostname %s is unknown for server %s.") at send.c:1760
#3 0x0808a882 in do_dns_async () at s_bsd.c:2635
#4 0x0808a0da in read_message (delay=0, listp=0x82081e0) at s_bsd.c:1757
#5 0x0807fe5d in main (argc=1, argv=0x0) at ircd.c:1528
#6 0x400c2dc6 in __libc_start_main () from /lib/libc.so.6
(gdb) print str
$1 = 0x81dd277 "tion loaded without any problems ..\r\n"
(gdb) print p1
$2 = 0x7473 <Address 0x7473 out of bounds>
Steps To ReproduceRead above
3rd party modulesNone

Activities

syzop

2004-10-08 21:56

administrator   ~0007925

This was probably fixed in CVS:
- Fixed possible crash if /rehash'ing and a servername was just resolving (due to
  /connect or autoconnect) and was not present in the cache. Reported and traced by sh0
  (0001976).

in short: a bad case of coincidence ;)

Issue History

Date Modified Username Field Change
2004-10-08 21:40 MagicalTux New Issue
2004-10-08 21:40 MagicalTux 3rd party modules => None
2004-10-08 21:56 syzop Note Added: 0007925
2004-10-08 21:59 syzop Status new => closed