[IRCServices] Possible bug in version 5.0.63
MiNd ErAsR
minderasr at gmail.com
Tue Jul 1 07:05:58 PDT 2008
The only added module we're using is vhost (Automatic vhosting (Hostserv)
main module. Based on code (c) Andrew Kempe (TheShadow)). All akills
appeared to be in the correct format when listed. We were able to reproduce
the crash and generate a core dump. Here is the relevant information.
1. Version: ircservices-5.0.63 services.afterx.net build #2, compiled Thu
Mar 6 15:52:12 CST 2008
2. Version: Unreal3.2.7. bellevue.tx.us.afterx.net FhinXOoZE3 [FreeBSD
7.0-RELEASE FreeBSD 7.0-RELEASE #0: Sun Feb 24 19:59:52 UTC 2008
root at logan.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386=2309]
3. Set an akill on a channel (command used was os akillchan kill +1h $0
Bots not welcome here). Note only 5 users were banned from this channel.
4. Log output:
[Jul 01 07:59:46 2008] operserv/main: tr: akillchan kill +15m #reefaholics
Bots not welcome here
[Jul 01 07:59:57 2008] operserv/main: tr: akill list
[Jul 01 08:18:06 2008] operserv/akill: BUG: (cancel_akill) Missing @ in
mask: *
[Jul 01 08:18:06 2008] operserv/akill: BUG: (cancel_akill) Missing @ in
mask: *
[Jul 01 08:18:06 2008] database/version4: del_maskdata(): invalid index 3
for type 0 at 0x283e93d8
[Jul 01 08:20:26 2008] operserv/akill: BUG: (cancel_akill) Missing @ in
mask: *
5. bt output:
#0 0x28433416 in check_expire_nick (ni=0x28386200) at
modules/nickserv/util.c:198
#1 0x281e98e8 in next_nickinfo () at modules/database/version4.c:150
#2 0x281e9924 in first_nickinfo () at modules/database/version4.c:150
#3 0x281eb16c in sync_nick_db (dbname=0x282032a0 "nick.db") at
modules/database/version4.c:620
#4 0x2842ae93 in do_save_data () at modules/nickserv/main.c:220
#5 0x0805ab20 in call_callback_5 (module=0x806c8e0, id=6, arg1=0x0,
arg2=0x0, arg3=0x0, arg4=0x0, arg5=0x0) at modules.c:705
#6 0x08056283 in do_save_data () at main.c:200
#7 0x08056465 in main (ac=1, av=0xbfbfecc8, envp=0xbfbfecd0) at main.c:251
On Tue, Jul 1, 2008 at 6:52 AM, Kieron Thwaites <ron2k.za at gmail.com> wrote:
> Hi,
>
> As Andrew said, it's possibly a third-party module.
>
> I suggest following the instructions in the FAQ that deal with generating a
> backtrace. If Services crashes again and you have a backtrace, any coder out
> there can see where in the code the crash occurred. This will even be useful
> if indeed it's a bug in a third-party module, because you can then take that
> backtrace and say to the relevant developer "your code is broken, fix it".
> :)
>
> Something else that I just thought of - when you next add akills, try
> listing them to see that they are indeed in the correct format.
>
> Cheers
>
> --K
>
> 2008/6/30 Andrew Church <achurch at achurch.org>:
>
>> >It's happened again. After operserv chankill bans expire, the problems
>> >begin. Server hosting services is running FreeBSD 7.0-RELEASE #0. Any
>> >ideas what could be causing this?
>> [...]
>> >[Jun 30 11:22:29 2008] operserv/akill: BUG: (cancel_akill) Missing @ in
>> >mask: *
>>
>> Are you perhaps using a (buggy) third-party module? The code in Services
>> itself always ensures that autokill masks have an "@" in them.
>>
>> >[Jun 30 14:41:06 2008] PANIC! signal 30, buffer = & ib 2 1214854859
>> >chatzilla <IP edit> <server name edit> 0 +wx D604FBDC.E$
>> >[Jun 30 14:41:06 2008] Out of memory!
>>
>> Again, if you're using a third-party module and that module doesn't
>> properly free the memory it uses, Services can run out of memory.
>> I'm not currently aware of any memory leaks in Services itself.
>>
>> --Andrew Church
>> achurch at achurch.org
>> http://achurch.org/
>>
>> ------------------------------------------------------------------
>> To unsubscribe or change your subscription options, visit:
>> http://lists.ircservices.za.net/mailman/listinfo/ircservices
>>
>
>
> ------------------------------------------------------------------
> To unsubscribe or change your subscription options, visit:
> http://lists.ircservices.za.net/mailman/listinfo/ircservices
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: ../attachments/20080701/3733ff97/attachment-0001.htm