Thread: glibc detected: what can I do?

  1. #1
    Registered User
    Join Date
    May 2010
    Posts
    50

    glibc detected: what can I do?

    Hi guys...another "bad new"...I was compiling some code and checking it within C and everithing was ok...but when I compile the code in order to use it inside R there something wrong.
    This is what I type on the terminal in order to compile
    gcc -std=gnu99 -I/usr/share/R/include -fpic -g -O2 -c codeRGLM.c -o codeRGLM.o
    gcc -std=gnu99 -shared -o codeRGLM.so codeRGLM.o dgesv.o dgetrf.o dlaswp.o dgetf2.o ilaenv.o ieeeck.o dgetrs.o dpofa.o dpodi.o eigen.o svd.o -L/usr/lib/R/lib -lR

    And running it inside R I got this...I have tried to do not include usr/share/R/include, but I need the headers inside in order to run the code inside R.

    *** glibc detected *** /usr/lib/R/bin/exec/R: free(): invalid pointer: 0xb712d180 ***
    ======= Backtrace: =========
    /lib/tls/i686/cmov/libc.so.6[0xb7c9b454]
    /lib/tls/i686/cmov/libc.so.6(cfree+0x96)[0xb7c9d4b6]
    /home/.../Lavoro_PHD/revenge_C/matrix/Statistical_header/codeRGLM.so(Simpson_Simpson_Adaptive+0x1ed)[0xb7119e0d]
    /home/...Lavoro_PHD/revenge_C/matrix/Statistical_header/codeRGLM.so(bstr_Q_m1+0x74)[0xb7119eb4]
    /usr/lib/R/lib/libR.so[0xb7e39c39]
    /usr/lib/R/lib/libR.so(Rf_eval+0x73a)[0xb7e663ea]
    /usr/lib/R/lib/libR.so[0xb7e688a7]
    /usr/lib/R/lib/libR.so(Rf_eval+0x465)[0xb7e66115]
    /usr/lib/R/lib/libR.so(Rf_applyClosure+0x2e7)[0xb7e69e07]
    /usr/lib/R/lib/libR.so(Rf_eval+0x38b)[0xb7e6603b]
    /usr/lib/R/lib/libR.so(Rf_ReplIteration+0x24d)[0xb7e8d11d]
    /usr/lib/R/lib/libR.so[0xb7e8d3d3]
    /usr/lib/R/lib/libR.so(run_Rmainloop+0x65)[0xb7e8d475]
    /usr/lib/R/lib/libR.so(Rf_mainloop+0x1c)[0xb7e8d49c]
    /usr/lib/R/bin/exec/R(main+0x46)[0x80487c6]
    /lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe5)[0xb7c42685]
    /usr/lib/R/bin/exec/R[0x80486b1]


    What can I do without changing the source code of the function that causes this? (it is an integration routine and I have not written it :-( )
    Last edited by violatro; 06-10-2010 at 08:21 AM.
    ai confini della conoscenza

  2. #2
    Registered User
    Join Date
    Oct 2008
    Location
    TX
    Posts
    2,059
    First of all compile with the debugging switch "-g", so gdb can be more helpful.
    Looks like free() is getting a pointer that's different from what malloc() returned.

  3. #3
    spurious conceit MK27's Avatar
    Join Date
    Jul 2008
    Location
    segmentation fault
    Posts
    8,300
    "glibc detected" is better than the reverse. If it ever says "glibc not detected" immediately hit the off button.

    That's not gdb output, that's the kernel (I believe) but if you do run it in gdb you should be able to find the culprit.
    C programming resources:
    GNU C Function and Macro Index -- glibc reference manual
    The C Book -- nice online learner guide
    Current ISO draft standard
    CCAN -- new CPAN like open source library repository
    3 (different) GNU debugger tutorials: #1 -- #2 -- #3
    cpwiki -- our wiki on sourceforge

  4. #4
    and the hat of int overfl Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    39,660
    > What can I do without changing the source code of the function that causes this?
    Have you ruled out that it might be your code that is causing the problem?

    For example, this looks like you trashed memory, and one easy way to do that is to allocate less than you thought.

    Crashes like this only show the symptom, not the cause.
    The root cause might be you didn't allocate enough space (say for example forgetting to scale the number of elements by the size of each one).
    Eg.
    double *p = malloc( howMany ); // oops, forgot * sizeof(*p)
    Nothing apparently wrong in your code, but the user of that blows up.
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.

  5. #5
    Registered User
    Join Date
    May 2010
    Posts
    50
    Thank you guys...This is a new "topic" for me because, up to now, I took care about my segmentation faults..
    I compile with this string in order to create an executable to run in gdb: gcc -I/usr/share/R/include codeRGLM.c (including R headers). But in this situation I am not getting seg. fault (only inside R).
    As far as I know the trouble is in free(pinterval) that was initialized in this way (I put also the structure...)
    Code:
    struct Subinterval { 
       double upper_limit;
       double lower_limit;
       double function[5];
       struct Subinterval *interval;
    };
    
    static struct Subinterval interval;
    static struct Subinterval *pinterval;
    
    double Simpson_Adaptive()
     {
               pinterval = &interval;
    ....
               free(pinterval);
    .....
    }
    so I think that maybe the problem is not "it did not allocate enough space".
    ai confini della conoscenza

  6. #6
    and the hat of int overfl Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    39,660
    The problem is, you're trying to free something which you didn't get from malloc.
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.

  7. #7
    Registered User
    Join Date
    May 2010
    Posts
    50
    Quote Originally Posted by Salem View Post
    The problem is, you're trying to free something which you didn't get from malloc.
    ok, that was my guess...but it works in C. Calling the shared library in R causes this. Ok, for the moment forget about this...
    The point is that I can't allocate in this way
    Code:
    static struct Subinterval *pinterval=malloc( sizeof(struct Subinterval*) );
    because the compiler says " error: initializer element is not constant".. Do you have a suggestion?
    Last edited by violatro; 06-10-2010 at 11:18 AM.
    ai confini della conoscenza

  8. #8
    and the hat of int overfl Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    39,660
    > ok, that was my guess...but it works in C
    You're confusing "skill" with "luck"

    Rest assured, it is quite broken. The fact that it doesn't blow up the first time you try it merely makes you lucky, not good.

    Sooner or later (well now in fact), it will bite you.
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.

  9. #9
    spurious conceit MK27's Avatar
    Join Date
    Jul 2008
    Location
    segmentation fault
    Posts
    8,300
    Quote Originally Posted by violatro View Post
    ok, that was my guess...but it works in C.
    No. It does not. It should crap out on you (altho the fact that it may not for some reason does not mean "it works").

    You do not have to malloc it if you don't want to. In that case DON'T free it, because you don't have to do that either.

    If you do want to malloc it, you'll need to do it within some function (such as main):

    Code:
    static struct Subinterval *pinterval;  // global pointer
    int main() {
         pinterval=malloc( sizeof(struct Subinterval*) )
    However, you don't have to do that at all if you are just assigning an address to a pointer, eg:
    Code:
    char string[]="hello world";
    char *ptr = &string[6];
    ptr points to "world" -- you don't have to allocate it anything. That is the same as this:

    Code:
     pinterval = &interval;
    C programming resources:
    GNU C Function and Macro Index -- glibc reference manual
    The C Book -- nice online learner guide
    Current ISO draft standard
    CCAN -- new CPAN like open source library repository
    3 (different) GNU debugger tutorials: #1 -- #2 -- #3
    cpwiki -- our wiki on sourceforge

  10. #10
    {Jaxom,Imriel,Liam}'s Dad Kennedy's Avatar
    Join Date
    Aug 2006
    Location
    Alabama
    Posts
    1,065
    Quote Originally Posted by violatro View Post
    Code:
    static struct Subinterval *pinterval=malloc( sizeof(struct Subinterval*) );
    Okay, so if I'm reading the above code correctly, you have a pointer to a struct Subinterval and you are requesting memory for a pointer to a struct Subinterval.

    HOWEVER,

    What I think you want to do is to create memory for the size of the struct Subinterval, not a pointer to that.
    Code:
    static struct Subinterval *pinterval = malloc(sizeof(struct Subinterval));
    OR
    Code:
    static struct Subinterval *pinterval = malloc(sizeof(*pinterval));

  11. #11
    Registered User
    Join Date
    May 2010
    Posts
    50
    I have fixed it editing the source code. I thought that it was a reliable source, but it was not!
    ok, thank you guys for the lectures and the suggestions!
    ai confini della conoscenza

  12. #12
    spurious conceit MK27's Avatar
    Join Date
    Jul 2008
    Location
    segmentation fault
    Posts
    8,300
    Quote Originally Posted by Kennedy View Post
    Okay, so if I'm reading the above code correctly, you have a pointer to a struct Subinterval and you are requesting memory for a pointer to a struct Subinterval.

    HOWEVER,

    What I think you want to do is to create memory for the size of the struct Subinterval, not a pointer to that.
    In fact not. The OP is assigning the address of an existing struct to it (for whatever reason):
    Code:
    pinterval = &interval;
    S/he does not need to malloc any memory at all for this purpose, it will just be subsequently LEAKED.
    C programming resources:
    GNU C Function and Macro Index -- glibc reference manual
    The C Book -- nice online learner guide
    Current ISO draft standard
    CCAN -- new CPAN like open source library repository
    3 (different) GNU debugger tutorials: #1 -- #2 -- #3
    cpwiki -- our wiki on sourceforge

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. *** glibc detected *** free(): invalid next size
    By kraghavan in forum C++ Programming
    Replies: 3
    Last Post: 05-11-2010, 07:17 AM
  2. *** glibc detected *** a.out: realloc()
    By msshapira in forum C Programming
    Replies: 9
    Last Post: 01-27-2009, 09:49 AM
  3. glibc detected malloc(): memory corruption
    By totalnewbie in forum C Programming
    Replies: 6
    Last Post: 01-12-2009, 06:21 AM
  4. Replies: 7
    Last Post: 11-26-2007, 01:11 PM
  5. *** glibc detected *** free(): invalid next size
    By icebabe in forum C Programming
    Replies: 2
    Last Post: 05-24-2006, 12:09 PM