glibc issues

int80 · 02-17-2008, 10:59 AM

It all started when I wrote a program using malloc, everything was ok until I executed it, then it said "glibc detected free() XX". I googled it, and didn't find much, other than someone saying to upgrade to the latest glibc version and coreutils, which I did.

Quote:

I would download the latest glibc package
(download not upgrade with swaret, just download)

Then I'd do a telinit 1 as root and upgradepkg glibc-xxx.tgz
After that, telinit 3 and upgrade coreutils package if newer
version is available

Although, when I typed "telinit 1" as told to, it just crashed my box, so I did it without doing it...

Now when I try and compile a program I get this:

Code:

bt programming # gcc sounds.c -o sounds
/usr/lib/gcc/i486-slackware-linux/3.4.6/../../../../i486-slackware-linux/bin/ld:/usr/lib/gcc/i486-slackware-linux/3.4.6/                                             ../../../libc.so: file format not recognized; treating as linker script
/usr/lib/gcc/i486-slackware-linux/3.4.6/../../../../i486-slackware-linux/bin/ld:/usr/lib/gcc/i486-slackware-linux/3.4.6/                                             ../../../libc.so:5: parse error
collect2: ld returned 1 exit status

Code:

bt ~ $ /lib/libc.so.6
GNU C Library stable release version 2.7, by Roland McGrath et al.
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 4.1.2.
Compiled on a Linux >>2.6.23.15-smp<< system on 2008-02-09.
Available extensions:
        crypt add-on version 2.1 by Michael Glad and others
        GNU Libidn by Simon Josefsson
        Native POSIX Threads Library by Ulrich Drepper et al
        BIND-8.2.3-T5B
For bug reporting instructions, please see:
<http://www.gnu.org/software/libc/bugs.html>.
bt ~ $ uname -a
Linux bt 2.6.20-NOSMP #3 Sat Feb 24 15:52:59 GMT 2007 i686 Intel(R) Pentium(R) M processor 1.80GHz GenuineIntel GNU/Linux

All I want to do is compile and run something, but it seems like a complete headache.

Any ideas what to do?

mrrangerman · 02-17-2008, 11:33 AM

Looks to me like you have it backwards

Code:

gcc sounds.c -o sounds

Change to gcc -o sounds sounds.c

Make sure you are in the directory the sourse file is, or give the path.

int80 · 02-17-2008, 03:23 PM

Quote:

Originally Posted by mrrangerman

Looks to me like you have it backwards

Code:

gcc sounds.c -o sounds

Change to gcc -o sounds sounds.c

Make sure you are in the directory the sourse file is, or give the path.

That's not the issue, I can compile it now, as I reinstalled the older version of glibc. It's just now, after I malloc'd some memory, when I try to free() it, it doesn't like it - just like before.

Code:

        if((mem_ptr2 = malloc(sizeof(char)*lsize2)) == NULL) {
                puts("Error assigning memory\n");
                exit(0);
        }

        for(y = 0; y != lsize ; y++) {
                g = fgetc(fptr2);
                mem_ptr2[y] = g;
        }

        for(x=0; x != lsize; x++) {
                if(mem_ptr[x] != mem_ptr2[x]) {
                        k = (mem_ptr[x] ^ mem_ptr[++x]);
                        --x;
                        printf("%c\n", k);
                }
        }

        free(mem_ptr); <<<<<<<< Doesn't like these
        free(mem_ptr2);
        fclose(fptr);
        fclose(fptr2);

        exit(0);
}

Code:

*** glibc detected *** stego-challenge2: free(): invalid next size (fast): 0x08055450 ***
======= Backtrace: =========
/lib/libc.so.6[0xb7ed4bcd]
/lib/libc.so.6(cfree+0x90)[0xb7ed8350]
stega-challenge2[0x80488af]
/lib/libc.so.6(__libc_start_main+0xdc)[0xb7e7f36c]
stega-challenge2[0x8048581]
======= Memory map: ========
08048000-08049000 r-xp 00000000 03:01 5527103    /home/int_80/programming/puzzle/stega-challenge2
08049000-0804a000 rw-p 00000000 03:01 5527103    /home/int_80/programming/puzzle/stega-challenge2
0804a000-0806b000 rw-p 0804a000 00:00 0          [heap]
b7d00000-b7d21000 rw-p b7d00000 00:00 0
b7d21000-b7e00000 ---p b7d21000 00:00 0
b7e68000-b7e69000 rw-p b7e68000 00:00 0
b7e69000-b7fb1000 r-xp 00000000 03:01 6852955    /lib/libc-2.7.so
b7fb1000-b7fb2000 r--p 00148000 03:01 6852955    /lib/libc-2.7.so
b7fb2000-b7fb4000 rw-p 00149000 03:01 6852955    /lib/libc-2.7.so
b7fb4000-b7fb7000 rw-p b7fb4000 00:00 0
b7fc2000-b7fca000 r-xp 00000000 03:01 4500332    /usr/lib/libgcc_s.so.1
b7fca000-b7fcb000 rw-p 00007000 03:01 4500332    /usr/lib/libgcc_s.so.1
b7fcb000-b7fcf000 rw-p b7fcb000 00:00 0
b7fcf000-b7fd0000 r-xp b7fcf000 00:00 0          [vdso]
b7fd0000-b7fec000 r-xp 00000000 03:01 6852979    /lib/ld-2.7.so
b7fec000-b7fee000 rw-p 0001b000 03:01 6852979    /lib/ld-2.7.so
bf917000-bf92c000 rw-p bf917000 00:00 0          [stack]
Aborted

I really haven't got a clue what's going on atall. It's doing my head in though, as I can't use malloc.

btmiller · 02-17-2008, 04:15 PM

I've gotten that error before. It generally means you have a bug in your code that has messed up the pointer so it's pointing to memory you did not malloc. This calls free to get confused as it can't find the bookkeeping information it stored when it malloc'ed the chunk. You can use a memory debugger like Valgrind to help you find the error, or simply examine your code. I didn't find anything too suspicious in the sample you posted, so it may occur somewhere else (like where you malloc mem_ptr). In no case should you attempt to upgrade glibc because of something like this -- you're fortunate you didn't destroy your system (I've done this with bad glibc updates before)!

int80 · 02-19-2008, 03:24 PM

Quote:

Originally Posted by btmiller

I've gotten that error before. It generally means you have a bug in your code that has messed up the pointer so it's pointing to memory you did not malloc. This calls free to get confused as it can't find the bookkeeping information it stored when it malloc'ed the chunk. You can use a memory debugger like Valgrind to help you find the error, or simply examine your code. I didn't find anything too suspicious in the sample you posted, so it may occur somewhere else (like where you malloc mem_ptr). In no case should you attempt to upgrade glibc because of something like this -- you're fortunate you didn't destroy your system (I've done this with bad glibc updates before)!

Yeah, you're right dude. I'm so arrogant about my coding "Oh it couldn't be my code", I practically took my OS apart trying to fix it without taking other possibilities into account. I did something stupid earlier on in the code.