Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Master]

Okay...this is weird. All of a sudden, Anope decides to crash with memos too. I saw this under feature requests, but this...meh.

Basically, a user gets a memo from another user. It's dated way back in 1969 or something, labeled memo 0, and has some odd ASCII before it. If a user tries to read or delete the memo, Anope panics and closes. The only way to "see" the memo is an /memoserv list command. I don't know what's up...we don't have any extra modules installed for Anope, either, and it just began happening for no apparent reason...

[Charles Kingsley]

Output of /os modlist please.

Additionally can you provide a back trace. (Instructions - http://anope.info/wiki/Other:GDB)

[Master]

The primary admin didn't enable the core dump...so I guess I'll get that when I can.

Output of /os modlist ...

(09:24:16am) **OperServ** Current Module list:
(09:24:17am) **OperServ** Module: cs_appendtopic [$Id: cs_appendtopic.c 1332 2008-01-04 10:43:21Z geniusdex $] [Supported]
(09:24:17am) **OperServ** Module: cs_enforce [$Id: cs_enforce.c 1335 2008-01-06 13:38:15Z geniusdex $] [Supported]
(09:24:17am) **OperServ** Module: enc_none [$Id$] [Encryption]
(09:24:17am) **OperServ** Module: hs_request [$Id$] [Supported]
(09:24:17am) **OperServ** Module: ns_maxemail [$Id: ns_maxemail.c 1332 2008-01-04 10:43:21Z geniusdex $] [Supported]
(09:24:17am) **OperServ** Module: os_info [$Id: os_info.c 1332 2008-01-04 10:43:21Z geniusdex $] [Supported]
(09:24:17am) **OperServ** Module: unreal32 [$Id: unreal32.c 1291 2007-08-30 20:59:14Z drstein $] [Protocol]
(09:24:17am) **OperServ** 7 Modules loaded.

[Jan Milants]

I recommend using gdb instead of the coredump.. the coredump doesn't always work.. depends on your system.
and we really need a backtrace with debug log to make any sense out of this one..

[katsklaw]

A real quick gdb tutorial for running Anope in gdb.

cd ~/services (this assumes you installed normally with /home/user/services/)
gdb services
run -debug -nofork (this will run the same as ./services -debug -nofork)

When services crashs:

bt full (copy and paste this output in reply to this thread.)

[Master]

Okay, I'll ask the admin about doing that...but it won't be easy forcing a crash on a production network

I'll set up a time to do it, as it shouldn't take very long to crash it (one command?!?). Currently we disabled all of MemoServ's commands, so we'd have to restart it anyway.

[katsklaw]

copy the db's to a testnet and run it there.

Don't have Linux at home? No prob... VMWare Server is free http://www.vmware.com

[Master]

Curious...the "corrupted" memos disappeared and MemoServ is behaving again. Very odd...I'll post again if it happens again, since services is configured now to dump the core file on crash.

Edit: Jynxed myself. It happened again...while not in debug mode. We'll run it in debug mode and see what happens.

[Master]

Okay, got some information:

http://pastebin.ca/1202005

[Master]

Bump and triple post...I feel like I'm talking to myself 

I don't know if this is fixed in 1.7.22 either because the changelog referenced 0 changes to memoserv...

[katsklaw]

Bump and triple post...I feel like I'm talking to myself 

I don't know if this is fixed in 1.7.22 either because the changelog referenced 0 changes to memoserv...

Re, talking to yourself: We have day jobs and lives. Unless you'd like to pay our salaries, you'll have to be satisfied with us answering when we can, not when you want.

RE, 1.7.22. Only confirmed bugs were included in 1.7.22, this issue can't even be viewed as a bug at this stage. Database corruption can not be prevented, nor are the classified as bugs in the application it's self since the application is only 1 of countless reasons data gets corrupted. It's something that IT people just have to deal with and prevent by creating backups and closely monitoring.

[master2004134]

So, do you know a possible way to resolve this without dumping the databases? I think we have backups...but I have no idea how old they are considering I don't manage the services myself...but in case not, any other solutions?

[katsklaw]

If it's db corruption, there likely isn't much that can be done. You can try to restore from backups, but Anope only stores 7 days worth by default.

If you know what nick has the "corrupted" memo then you could try to drop their nick, which should also delete their memos. I'd suggest playing with this on a TestNet and not on your production net.

You can email your db's to katsklaw@ircmojo.net and I'll load them up and see what I can do.

[Master]

Ok...I'll see if the admin agrees...if not, to a TestNet it goes!


(FYI, apparently I had two accounts and didn't even know it o_O)

[katsklaw]

You should try the TestNet first. Nothing like the feeling of solving your own problems

Email to me if you fail to figure it out, not mail to me first ..

[Master]

I think the issue lies within the memo deletion code, which by design expects the memo to have text associated with it:

Code: [Select]

int delmemo(MemoInfo * mi, int num)
{
    int i;

    for (i = 0; i < mi->memocount; i++) {
        if (mi->memos[i].number == num)
            break;
    }
    if (i < mi->memocount) {
        moduleCleanStruct(&mi->memos[i].moduleData);
        free(mi->memos[i].text);        /* Deallocate memo text memory */
        mi->memocount--;        /* One less memo now */
        if (i < mi->memocount)  /* Move remaining memos down a slot */
            memmove(mi->memos + i, mi->memos + i + 1,
                    sizeof(Memo) * (mi->memocount - i));
        if (mi->memocount == 0) {       /* If no more memos, free array */
            free(mi->memos);
            mi->memos = NULL;
        }
        return 1;
    } else {
        return 0;
 ..........

I think there's a simple fix for this...but I don't know if I can get any help with this as this is part of Anope's core...

Edit: If there's in fact no fix, is there a way to code a module which will delete all memos from every user? It seems a lot of users have a corrupted memo, which makes it unfeasible to drop the nicks...I think it's better to lose all memos then your nick group

[someone]

i requested a "feature" to split nick.db and memo.db like 1 year ago.

all i got was something like: maybe later
so deleting all nicks and disabling memoserv is the only solution i guess.

[Jan Milants]

i requested a "feature" to split nick.db and memo.db like 1 year ago.

all i got was something like: maybe later
so deleting all nicks and disabling memoserv is the only solution i guess.

No significant DB changes will be made to the 1.7 branch and splitting up databases is something I d call significant..

[Andrey]

i get same problem today  :'(

[15:10:00] -MemoServ- 1 Paulinho 17 Set 15:46:53 2008 BST
[15:10:00] -MemoServ- 0 -ÓHxHuGo 01 Jan 01:00:00 1970 BST
[15:10:00] -MemoServ- 0  01 Jan 01:00:03 1970 BST
[15:10:00] -MemoServ- 153900544  01 Jan 01:00:00 1970 BST
[15:10:00] -MemoServ- 805511230 01 Jan 01:00:00 1970 BST
[15:10:00] -MemoServ- 857749507 17 Nov 06:11:04 1974 GMT
[15:10:00] -MemoServ- *2901240 ÀV,    01 Jan 01:05:28 1970 BST
[15:10:00] -MemoServ- 1852403562 øD, 01 Jan 01:01:21 1970 BST

[Oct 02 18:50:08 2008] PANIC! buffer = :tucupi PRIVMSG MemoServ :READ 2

[Jan Milants]

that is clearly a corrupted database..

[15:10:00] -MemoServ- *2901240 ÀV,    01 Jan 01:05:28 1970 BST
[15:10:00] -MemoServ- 1852403562 øD, 01 Jan 01:01:21 1970 BST

completely messed up.. even if anope would add a sanity check before deleting, something really fucked up your database.. try restoring from a backup and removing all your modules.

[Andrey]

i think its any machine config/os/lib/caracter code..., because i change for other machine with same *.dbs and work fine. i'm confused, i'm making many test for found this.

[katsklaw]

i think its any machine config/os/lib/caracter code..., because i change for other machine with same *.dbs and work fine. i'm confused, i'm making many test for found this.

If it works fine on a second machine as you just admitted, then it is NOT any machine/os/lib/character code. I'd also go as far as saying it's not the db either but an environment variable outside the control of Anope since it's not possible for the exact same data in the exact same environment but on different machines to work on one and not another.

What are the specs of both machines, please indicate which one works and which one doesn't.

[Andrey]

2 years... and same problem.

I change machine and copy all *.db, i tried many backups and all get same error.

[07:12:49] -MemoServ- 1 RaphaeL 31 Mar 19:46:47 2010 MSD
[07:12:49] -MemoServ- 0 8·ºKBricio 01 Jan 03:00:00 1970 MSK
[07:12:49] -MemoServ- 0 01 Jan 03:00:03 1970 MSK
[07:12:49] -MemoServ- 149120120  01 Jan 03:00:00 1970 MSK
[07:12:49] -MemoServ- 1801677166 01 Jan 03:00:00 1970 MSK
[07:12:49] -MemoServ- *1920102246 23 Set 01:18:16 1974 MSK
[07:12:49] -MemoServ- *204879 hfã 30 Abr 09:06:16 1970 MSK
[07:12:49] -MemoServ- 10303576 X8 01 Jan 03:01:21 1970 MSK
[07:12:49] -MemoServ- 50470821 #Brèfã 02 Mar 19:10:43 1971

[07:13:11] <Global> PANIC! buffer = :tucupi PRIVMSG MemoServ :del all
[07:13:12] <Global> Backtrace: Segmentation fault detected
[07:13:12] <Global> Backtrace: report the following lines
[07:13:12] <Global> Backtrace: Anope version 1.8.5 (3037) build #1, compiled Oct 14 2010 15:09:14 QM
[07:13:12] <Global> Backtrace(0): ./services(do_backtrace+0x64) [0x807aad4]
[07:13:12] <Global> Backtrace(1): ./services(sighandler+0x16f) [0x807b9cf]
[07:13:12] <Global> Backtrace(2): /lib/libc.so.6 [0xb7c135f8]
[07:13:12] <Global> Backtrace(3): /home/redenort/services/modules/runtime/ms_del.so.6cfMo8(do_del+0x408) [0xb7abf0a8]
[07:13:12] <Global> Backtrace(4): ./services(do_run_cmd+0xa3) [0x806d363]
[07:13:12] <Global> Backtrace(5): ./services(mod_run_cmd+0x43) [0x806d513]
[07:13:12] <Global> Backtrace(6): ./services(memoserv+0x8b) [0x807ce3b]
[07:13:12] <Global> Backtrace(7): ./services(m_privmsg+0x4ff) [0x807df6f]
[07:13:14] <Global> Backtrace(: /home/redenort/services/modules/runtime/inspircd11.so.FQ7Ssb(anope_event_privmsg+0x3b) [0xb7b5c57b]
[07:13:14] <Global> Backtrace(9): ./services(process+0x1d0) [0x808fe70]
[07:13:14] <Global> Backtrace: complete
[07:13:14] <Global> Shutdown: Services Shutting Down
[07:13:14] <Global> Services terminating: Segmentation fault

 

[Charles Kingsley]

What's the difference in the machines.

[Andrey]

i dont know last machine, i think its same os.

i check in nick.db and its normal, only in services get this problem.