strange segfault

[sKy]

I got access to a box of a friend and he gave me a ssh2 account. Downloading, unpacking and compiling eggdrop worked well without errors. But after I wanted to start it there was a segfault, so I started with -n to see more debug messages.

30688@pa64:~/eggdrop$ ./eggdrop -m -n eggdrop.conf

Eggdrop v1.6.18 (C) 1997 Robey Pointer (C) 2006 Eggheads
[10:50] Allocated bind table unld (flags 1)
[10:50] Allocated bind table time (flags 1)
[10:50] Allocated bind table note (flags 0)
[10:50] Allocated bind table nkch (flags 1)
[10:50] Allocated bind table load (flags 1)
[10:50] Allocated bind table link (flags 1)
[10:50] Allocated bind table filt (flags 1)
[10:50] Allocated bind table disc (flags 1)
[10:50] Allocated bind table dcc (flags 0)
[10:50] Allocated bind table chpt (flags 1)
[10:50] Allocated bind table chon (flags 1)
[10:50] Allocated bind table chof (flags 1)
[10:50] Allocated bind table chjn (flags 1)
[10:50] Allocated bind table chat (flags 1)
[10:50] Allocated bind table bot (flags 0)
[10:50] Allocated bind table bcst (flags 1)
[10:50] Allocated bind table away (flags 1)
[10:50] Allocated bind table act (flags 1)
[10:50] Allocated bind table evnt (flags 1)
[10:50] --- Loading eggdrop v1.6.18 (Sun Oct 21 2007)
[10:50] all.tcl 1
[10:50] Logfile suffix changed. Closing all open logs.
[10:50] Module loaded: channels
[10:50] Allocated bind table wall (flags 1)
[10:50] Allocated bind table raw (flags 1)
[10:50] Allocated bind table notc (flags 1)
[10:50] Allocated bind table msgm (flags 1)
[10:50] Allocated bind table msg (flags 0)
[10:50] Allocated bind table flud (flags 1)
[10:50] Allocated bind table ctcr (flags 1)
[10:50] Allocated bind table ctcp (flags 1)
[10:50] Module loaded: server
[10:50] Module loaded: ctcp
[10:50] Allocated bind table topc (flags 1)
[10:50] Allocated bind table splt (flags 1)
[10:50] Allocated bind table sign (flags 1)
[10:50] Allocated bind table rejn (flags 1)
[10:50] Allocated bind table part (flags 1)
[10:50] Allocated bind table nick (flags 1)
[10:50] Allocated bind table mode (flags 1)
[10:50] Allocated bind table kick (flags 1)
[10:50] Allocated bind table join (flags 1)
[10:50] Allocated bind table pubm (flags 1)
[10:50] Allocated bind table pub (flags 0)
[10:50] Allocated bind table need (flags 1)
[10:50] Module loaded: irc
[10:50] Allocated bind table rcvd (flags 1)
[10:50] Allocated bind table sent (flags 1)
[10:50] Allocated bind table lost (flags 1)
[10:50] Allocated bind table tout (flags 1)
[10:50] LANG: Section loaded: transfer
[10:50] LANG: 59 messages of 65 lines loaded from ./language/transfer.english.lang
[10:50] LANG: 59 adds, 0 updates to message table
[10:50] Module loaded: transfer (with lang support)
[10:50] Module loaded: share
[10:50] Module loaded: compress
[10:50] Allocated bind table fil (flags 0)
[10:50] LANG: Section loaded: filesys
[10:50] LANG: 53 messages of 58 lines loaded from ./language/filesys.english.lang
[10:50] LANG: 53 adds, 0 updates to message table
[10:50] Module loaded: filesys (with lang support)
[10:50] * Last context: tclhash.c/238 []
[10:50] * Please REPORT this BUG!
[10:50] * Check doc/BUG-REPORT on how to do so.
[10:50] * Wrote DEBUG
[10:50] * SEGMENT VIOLATION -- CRASHING!
Segmentation fault (core dumped)

Btw, the configuration worked already on other box. Dunno what here is the problem. Any hints?

[nml375]

Read the file BUG-REPORT that comes with the source.

To gather any useful information on what actually caused the segmentation fault, a core dump with backtrace would be needed.

[sKy]

There is some file core.anumber. I did download it to my comp and looked int o it with an editor mostly it`s a lot weird chars.

How to read this log?

[nml375]

Did you read BUG-REPORT?
If not, I'm quoting the relevant part from it:

Code: Select all

4.8) If the bot dumped a 'core' file when it crashed, it would be *very*
     useful if you could paste gdb's output during the following steps:
     First call gdb
         $ gdb eggdrop -c core
     and then enter 'bt' on gdb's command line:
         (gdb) bt
     Keep your core file for at least one week, so that the dev team
     can ask for further information if needed. However, don't send
     us the core file unless we ask for it.

     NOTE: If this is a bug you can reproduce, please compile with
           make debug and follow the above step. It can greatly help
           find and fix the bug.

[sKy]

Amazing on how fast you are here an try to help.

Well, I`ve reported a less strange a bug (which could be easy reproduced) on that way several years ago. So far no one from their development team did care about.

See the archive some years ago, there someone did care about and answered on the list.
http://eggheads.org/pipermail/bugs/2002 ... hread.html

But now I would say it`s unmaintained.
http://eggheads.org/pipermail/bugs/2007 ... hread.html

[nml375]

One of the big issues with most reports shown in those archives is the lack of backtraces on coredumps... Without that, tracking down bugs is quite similar like searching for a needle in a haystack while being blindfolded.

The 1.6 tree, I guess, is'nt being much developed these days for numerous reasons. One I've been told is the lack of developers with time/interrest in enhancing the 1.6 tree, aswell as fixing bugs within it. There is a memleak in the notes-module that I've reported long time ago, that I belive is still unadressed (albeit a possible solution has been provided).

Nevertheless... post the result of the backtrace here aswell, and we'll see what comes up..