View Issue Details

IDProjectCategoryView StatusLast Update
0000811unrealircdpublic2003-12-29 20:21
Reporteromega Assigned Toluke  
PrioritynormalSeveritycrashReproducibilityhave not tried
Status closedResolutionopen 
Summary0000811: ReLink crash
DescriptionI got delinked from the hub due to Missing H:Line when i linked NeoStats-2.5.0 to my server witch is also a hub. My server didn't had an H:Line on the main server.
I relinked my server to the main hub without NeoStats linked and the hub seg faulted: « global from light.*: AIEEE!!! Server Terminating: Segmention fault (buf: ~ !{SthZ #jukebox +ntr :@*omega )
Steps To Reproduce1) Two hubs second hub without an H:Line on the main hub
2) Link NeoStats-2.5.0 to second hub. Got delinked to Missing H:Line
3) Kill NeoStats before reconnect to main hub
4) Reconnect to main hub
3rd party modules

Activities

omega

2003-04-15 16:15

reporter   ~0002342

#0 ircvsprintf (
    str=0x8120020 "NOTICE ALL :SEGFAULT! I'm Meeeeellllting, what a world!\r\n", format=0xbfffd49d "@%s) MODE %s %s %s", vl=0xbfffd874) at ircsprintf.c:289
289 if ((*str = *p1))
(gdb)

syzop

2003-04-15 17:56

administrator   ~0002343

just for the record, a similar bug (0000732) is present in 3.2.* as well.

omega

2003-04-16 13:52

reporter   ~0002353

We don't have a server which is compiled as debug and i managed to reproduce to bug again but i didn't try to reproduce it. It just came again.

syzop

2003-04-16 14:10

administrator   ~0002354

Yeah no need to, it's easy to reproduce.

omega

2003-04-16 14:33

reporter   ~0002355

About when will this bug be fixed? Because my network core dumps alot due to this bug. (This is what the owner told me)

syzop

2003-04-16 15:37

administrator   ~0002356

Last edited: 2003-04-16 15:39

Hmm, the simple workaround is using a good config (that is: so it never delinks because a leaf is acting like a hub). [in other words: add the H: lines]

edited on: 04-16-03 15:39

syzop

2003-04-16 18:06

administrator   ~0002359

0000732 now fixed _IN DEVEL (3.2 cvs)_. Luke: I'm unsure if it's exactly the same bug, anyway, in 3.2 there's was:
m_server -> m_server_remote -> exit_client
however in m_server there was just a simple:
m_server_remote(cptr, ... etc);
return 0;
so FLUSH_BUFFER (=client doesnt exist anymore) was not returned causing.. blahhh..

but it doesn't seem to be the case @ 3.1.5.1 (very quick look, 1m).

Issue History

Date Modified Username Field Change
2003-04-15 16:15 omega Note Added: 0002342
2003-04-15 17:56 syzop Note Added: 0002343
2003-04-16 13:52 omega Note Added: 0002353
2003-04-16 14:10 syzop Note Added: 0002354
2003-04-16 14:33 omega Note Added: 0002355
2003-04-16 15:37 syzop Note Added: 0002356
2003-04-16 15:39 syzop Note Edited: 0002356
2003-04-16 18:06 syzop Note Added: 0002359
2003-04-16 18:33 syzop Assigned To => luke
2003-04-16 18:33 syzop Status new => assigned
2003-12-29 20:21 syzop Status assigned => closed