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 :-( )

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.

"glibc detected" is better than the reverse. :p 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.

> 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.

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".

The problem is, you're trying to free something which you didn't get from malloc.

Quote:

---

Originally Posted by Salem

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?

> 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.

Quote:

---

Originally Posted by violatro

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;

---

Quote:

---

Originally Posted by violatro

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));

---

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!

Quote:

---

Originally Posted by Kennedy

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.