Eggdrop 1.6.20 glibc 2.11.1 *** glibc detected *** ./eggdrop

[LimeyTX]

I have just built a brand new eggdrop on a VPS running Ubuntu. As soon as I do ./eggdrop I get immediately the following error.

*** glibc detected *** ./eggdrop: free(): invalid next size (fast): 0x08794250 * **
======= Backtrace: =========
/lib/libc.so.6(+0x6c12a)[0x45d12a]
/lib/libc.so.6(+0x6d988)[0x45e988]
/lib/libc.so.6(cfree+0x6d)[0x461afd]
./eggdrop[0x80827fa]
./eggdrop[0x8082b32]
./eggdrop[0x807c937]
./eggdrop[0x80726d5]
/lib/libc.so.6(__libc_start_main+0xe6)[0x407bc6]
./eggdrop[0x804aa01]
======= Memory map: ========
00153000-00167000 r-xp 00000000 fd:00 5280853 /lib/libpthread-2.11.1.so
00167000-00168000 r-xp 00014000 fd:00 5280853 /lib/libpthread-2.11.1.so
00168000-00169000 rwxp 00015000 fd:00 5280853 /lib/libpthread-2.11.1.so
00169000-0016b000 rwxp 00169000 00:00 0
0024d000-0034c000 r-xp 00000000 fd:00 7471170 /usr/local/lib/libtcl8.5.so
0034c000-0034e000 r-xp 000ff000 fd:00 7471170 /usr/local/lib/libtcl8.5.so
0034e000-00352000 rwxp 00101000 fd:00 7471170 /usr/local/lib/libtcl8.5.so
00352000-00353000 rwxp 00352000 00:00 0
0039f000-003a0000 r-xp 0039f000 00:00 0 [vdso]
003ed000-003ef000 r-xp 00000000 fd:00 5280842 /lib/libdl-2.11.1.so
003ef000-003f0000 r-xp 00001000 fd:00 5280842 /lib/libdl-2.11.1.so
003f0000-003f1000 rwxp 00002000 fd:00 5280842 /lib/libdl-2.11.1.so
003f1000-00533000 r-xp 00000000 fd:00 5280839 /lib/libc-2.11.1.so
00533000-00534000 --xp 00142000 fd:00 5280839 /lib/libc-2.11.1.so
00534000-00536000 r-xp 00142000 fd:00 5280839 /lib/libc-2.11.1.so
00536000-00537000 rwxp 00144000 fd:00 5280839 /lib/libc-2.11.1.so
00537000-0053a000 rwxp 00537000 00:00 0
005db000-005ee000 r-xp 00000000 fd:00 5280845 /lib/libnsl-2.11.1.so
005ee000-005ef000 r-xp 00012000 fd:00 5280845 /lib/libnsl-2.11.1.so
005ef000-005f0000 rwxp 00013000 fd:00 5280845 /lib/libnsl-2.11.1.so
005f0000-005f2000 rwxp 005f0000 00:00 0
00677000-00692000 r-xp 00000000 fd:00 5280836 /lib/ld-2.11.1.so
00692000-00693000 r-xp 0001a000 fd:00 5280836 /lib/ld-2.11.1.so
00693000-00694000 rwxp 0001b000 fd:00 5280836 /lib/ld-2.11.1.so
00761000-00785000 r-xp 00000000 fd:00 5280843 /lib/libm-2.11.1.so
00785000-00786000 r-xp 00023000 fd:00 5280843 /lib/libm-2.11.1.so
00786000-00787000 rwxp 00024000 fd:00 5280843 /lib/libm-2.11.1.so
00cad000-00cb3000 r-xp 00000000 fd:00 5280846 /lib/libnss_compat-2.11.1.so
00cb3000-00cb4000 r-xp 00006000 fd:00 5280846 /lib/libnss_compat-2.11.1.so
00cb4000-00cb5000 rwxp 00007000 fd:00 5280846 /lib/libnss_compat-2.11.1.so
00d25000-00d2d000 r-xp 00000000 fd:00 5280850 /lib/libnss_nis-2.11.1.so
00d2d000-00d2e000 r-xp 00007000 fd:00 5280850 /lib/libnss_nis-2.11.1.so
00d2e000-00d2f000 rwxp 00008000 fd:00 5280850 /lib/libnss_nis-2.11.1.so
00d9d000-00da7000 r-xp 00000000 fd:00 5280848 /lib/libnss_files-2.11.1.so
00da7000-00da8000 r-xp 00009000 fd:00 5280848 /lib/libnss_files-2.11.1.so
00da8000-00da9000 rwxp 0000a000 fd:00 5280848 /lib/libnss_files-2.11.1.so
00ed8000-00ef5000 r-xp 00000000 fd:00 5280705 /lib/libgcc_s.so.1
00ef5000-00ef6000 r-xp 0001c000 fd:00 5280705 /lib/libgcc_s.so.1
00ef6000-00ef7000 rwxp 0001d000 fd:00 5280705 /lib/libgcc_s.so.1
08048000-0809a000 r-xp 00000000 fd:00 11273019 /home/cobo/eggdrop/eggdrop-1.6. 20
0809a000-0809b000 r--p 00051000 fd:00 11273019 /home/cobo/eggdrop/eggdrop-1.6. 20
0809b000-0809f000 rw-p 00052000 fd:00 11273019 /home/cobo/eggdrop/eggdrop-1.6. 20
0809f000-080a3000 rw-p 0809f000 00:00 0
08778000-087bb000 rw-p 08778000 00:00 0
b7e00000-b7e21000 rw-p b7e00000 00:00 0
b7e21000-b7f00000 ---p b7e21000 00:00 0
b7f23000-b7f26000 rw-p b7f23000 00:00 0
b7f29000-b7f2c000 rw-p b7f29000 00:00 0
bfa2e000-bfa43000 rw-p bfa2e000 00:00 0 [stack]
Aborted

I have seen some references about a new glibc causing problems but I haven't seen a solution anywhere.

Can anyone help?

[nml375]

Since you can reproduce this, it would be very helpful if you could do a debug build (make debug), and allow it to do a coredump upon crashing (ulimit -c 10240). Finally, follow the instructions in the doc/BUG-REPORT document that comes with the source.

[LimeyTX]

I did as you requested. Below is the output from the gdb bt

(gdb) bt
#0 0x00e04607 in raise () from /lib/libc.so.6
#1 0x00e07ab2 in abort () from /lib/libc.so.6
#2 0x00e3bf0d in ?? () from /lib/libc.so.6
#3 0x00e4612a in ?? () from /lib/libc.so.6
#4 0x00e47988 in ?? () from /lib/libc.so.6
#5 0x00e4aafd in free () from /lib/libc.so.6
#6 0x0808282a in add_builtins (tl=0x9c30688, cc=0xbfc4d000) at tclhash.c:1272
#7 0x08082b62 in init_bind () at tclhash.c:241
#8 0x0807c957 in init_tcl (argc=1, argv=0xbfc4e334) at tcl.c:819
#9 0x080726f5 in main (arg_c=1, arg_v=0xbfc4e334) at ./main.c:1035

[nml375]

Thank you,
At a first glance, it would seem we've got a buffer overrun bug in add_builtins (thrashing the malloc heap space.
Unfortunately, I'm having a hard time pinning down the issue:
Tcl_ScanElement() and Tcl_ConvertElement are designed to operate closely together, and the size provided by Tcl_ScanElement() should be more than sufficient to hold the data from Tcl_ConvertElement().

The piece of code in question:

Code: Select all

void add_builtins(tcl_bind_list_t *tl, cmd_t *cc)
{
  int k, i;
  char p[1024], *l;
  cd_tcl_cmd table[2];

  table[0].name = p;
  table[0].callback = tl->func;
  table[1].name = NULL;
  for (i = 0; cc[i].name; i++) {
    egg_snprintf(p, sizeof p, "*%s:%s", tl->name,
                 cc[i].funcname ? cc[i].funcname : cc[i].name);
    l = nmalloc(Tcl_ScanElement(p, &k));
    Tcl_ConvertElement(p, l, k | TCL_DONT_USE_BRACES);
    table[0].cdata = (void *) cc[i].func;
    add_cd_tcl_cmds(table);
    bind_bind_entry(tl, cc[i].flags, cc[i].name, l);
    nfree(l);
  }
}

A nasty workaround would be to simply tell glibc to don't bother checking for these issues; it won't fix the issue at hand, just sweep it under the rug... You've been warned

Code: Select all

./eggdrop eggdrop.conf MALLOC_CHECK_=1

[LimeyTX]

I tried that. The result was to crash on the malloc() at tclhash.c line 395.
I guess ignoring the heap corruption just manifests itself differently.

I recall reading that glibc has been modified so that the block returned by malloc is larger then requested so that glibc can store information in the portion before the returned pointer. I assume this area is checked by the free to ensure the storage freed is valid. My c skills are pretty rusty so I am not much help.

These runs were completed with the UNMODIFIED eggdrop.conf file. My guess is you could reproduce this by using glibc 2.11.1

If you need any further information, please let me know.

[LimeyTX]

Some further thoughts. I could be totally off base here but with my almost zero knowledge of eggdrop and TCL I did get to thinking.

Since the malloc/free are in the same for loop,any error in Tcl_ConvertElement os Tcl_ScanElement would most likely cause corruption past the area obtained by the malloc.

Therefore, it occurred to me the most likely cause is overrun of the area on the heap BEFORE the malloc for the Tcl_ScanElement. I have no clue what that is, but it would mean that add_builtins() was the victim rather than the culprit. Just a thought, feel free to completely ignore me if I am not making sense!

[nml375]

I suspected something like that might happen. Thanks for confirming though..
And yes, glibc does allocate a header in front of the returned pointer, for maintaining information amongst other, the size of the allocated area.

I've successfully built and run 1.6.20 on several different Ubuntu dists, and not been able to reproduce this yet. Could you tell if your VPS is running Ubuntu 10.10 (Maverick), and whether your system is a 32 or 64bit install?

[LimeyTX]

It is Maverick and it's 32 bit

[nml375]

Update: Just tried a VM with Ubuntu 10.10 Server and glibc 2.11.1 (64bit system), and everything worked smoothly.

Regarding the Before/After thoughts; before the call to malloc, the memory-area of the header is not allocated - and thus not initialized. Upon calling malloc(), once the memory area is allocated, the header is written on top of any previous data. Also, should the previous header be damaged, the malloc() call would crash, rather than the free() call.

[LimeyTX]

My VPS provider has just restaged my VPS and guess what, now it works. I'm guessing something was screwed up on the base system.

Anyway, I appreciate your help and apologize for wasting your time,but it wasn't my fault

[saldawod]

The same problem with me..

[Vladislav]

The same problem with me TCL8.5.10. 8.5.9 - good.

[LimeyTX]

As I stated earlier, my provider restaged my VPS host and that solved the problem. But something I read the other day, I forget where, mentioned doing an apt-get on tcl8.5-dev and it occurred to me later that maybe the problem was that the tcl.h being used was incompatible with the tcllib.so and that could have been causing the problem. Maybe someone who knows a lot more about it than me can comment on the proper way to install TCL on Ubuntu systems for use with eggdrop.

[thommey]

The patch at http://forum.egghelp.org/viewtopic.php?p=97173#97173 should fix it.