Hi all,

I'm trying to execute a program written in c and I get this message:

*** glibc detected *** ./program-name : free(): invalid next size (normal): 0x08a78dc0 ***

While compiling I don't get any error message and I'm sure the problem doesn't come from the program because it's been already used. So that I think that the problem is in the version of glibc that I use.

Here is what I have installed on my ubuntu 11.10
-gcc version 4.6.1
-libglib2.0

I tryed to type "rpm -q glibc" and it says that it's not installed, but when I type "sudo apt-get install glibc" I get the following answer: "impossible to find the package"

I am not an expert, neither with c language nor with Linux, so I have no idea where the problem could be!

Thanks a lot!!

Ashotti

the 20 questions part .....
1)What program?
2)where did you get it ?
3)what command(s) are you using to invoke it ?
4)what commands did you use to do that ?
( the build line would be nice )
WTF ?
boggles the mind
Why would you think that a red hat software installer would run on a Debian based OS ?
Ubuntu DOSE NOT use " Red hat Package Manager "

You are wrong. The problem you reported is definitely caused by a bug in that program. Bugs don't always have symptoms, so previous testing without seeing this problem means absolutely nothing.

You are wrong.

Linux expertise is irrelevant to this problem. Expertise in C may be required. In any large program, this kind of bug is hard for a beginner to find. It is especially hard if you start out "knowing" things that aren't true, such as demonstrated in your initial statements about the problem.

If the program is small enough to post the whole source code, then you ought to do so. Any expert can likely spot this kind of bug with just a quick skim through the source code.

If the program is large, you would need to learn how to debug this kind of bug.

the answers:

it's a program for filter data, I don't think it's importan to know what the program is supposed to do

from the person who used it before, that's why I think it could be a problem with glibc

./program-name

(compiling)

I used: gcc program-name.c -o program-name -lm

because before writing in this forum I tryed to google "how to get the version of glibc" and this is what I found.
How could I be supposed to know that rpm is "Red hat Package Manager" if I'm just a beginner in using Ubuntu?

because if it is a 15 year old program it will NOT easily run on a new operating system
( and yes i do sometimes need to run very old fortran and C code )
on what operating system did they run this program?
i am betting it was not on ubuntu 11.10

std. for a one file program that is using lib math


so what it looks like you are experiencing is trying to run a program WROTE for a very different operating system

ask that person what OS they used

Thanks for all the answers.

The program is not so old because it was run in 2007.

I will definitely ask for the OS that was used.

But now I am a bit confused becaused I don't know if I have to find the root of the problem in the
program or in the differencies between the OS used.

Could Valgrind help me somehow?

Thanks again!

Do you also not understand the significance of this specific error?

The age and prior OS of the program are not relevant.

There is a specific kind of bug in the program. The bug was there during the prior use. The symptom was apparently not there during the prior use. The OP believes the lack of prior symptom is significant information. For some other type of bug, it might be. For this type of bug, lack of prior symptom is common and is not diagnostically useful.

Not relevant.

Wrong. What the Ashotti is experiencing is a program with a bug in it. That bug was symptom free in prior use due to what would seem (after you understood it) to be a bizarre accident. It is far less bizarre in real life once you consider that this kind of bug is fairly common and ordinarily the programmer would find and fix it. But by some improbable accident the bug was originally symptom free. So the bug was hidden until someone moved the program to a different environment. The different environment is actually irrelevant to the bug, but relevant to the improbable accident that caused the bug to be symptom free. You aren't trying to diagnose the accident that made the bug symptom free. You are trying to diagnose the bug. So the change of environment is not diagnostically useful info.

In theory, this is exactly the kind of problem Valgrind is supposed to identify. In practice, my own experience with Valgrind has not been that good. I'm also exceptionally good at diagnosing these by other means. So I would not try Valgrind if it were my problem. But what is right for you is not the same as what is right for me. For you, Valgrind is better than any other specific suggestion I could make with the available info.

BTW, the most common programming error with this symptom is to allocate a buffer and then use slightly more than the whole buffer. If you had moved from a 32 bit OS to a 64 bit OS, then such an error could be from non portable coding making assumptions about the sizes of data types. But I deduce you are using 32 bit Ubuntu, so I don't think the allocation overrun (if there is one) is caused by portability errors in a 32 bit to 64 bit migration.

That can be important. Best guess, the bug is a buffer overrun. In a program for filtering data, a good follow up guess from a buffer overrun is that the difference (symptom free vs. failing) is in the filename (length of the full directory/.../name string) or content of the data, rather than in the recompile of the program. But guessing is only good if you get lucky. Valgrind or some more expert debugging approach is more reliable.

1 members found this post helpful.

Thanks!

Now it's clear why a program that had no problems before is showing some bugs now.

Unfortunately the code is quite long, so I can't post it here.

It allocates and deallocates severale vectors, the problem could be there, anyway the only thing
I can do is to pass through the code and try to find the problem.
I will try to use Valgrind as starting point.

Thanks a lot for all the suggestions!!

I tried to use Valgrind and I found where the problem is!
The problem is with the malloc function, first the following is defined

coordx=(double *)malloc(N*sizeof(double));
coordy=(double *)malloc(N*sizeof(double));

and few lines after:

coordx[idum]=xbuf;
coordy[idum]=ybuf;


I just changed the code declaring coordx[N] and coordy[N] at the beginning without using the allocatable memory and now everything works properly, but I would be quite surprise if the problem stems simply from the use of the malloc function!

Do you have any suggestion regarding where exactly the problem could be?

I hope that what I want to say is understandable even though I'm not able to use a technical jargon!

Thanks!!

Assuming Valgrind gave you correct info (something I don't completely trust) your change has just changed the symptom, not fixed the bug.

If Valgrind is correct then idum >= N.

In place of N in the malloc, you need a value at least one greater than the largest value that idum can be.

Is the code setting idum simple enough that you can compute the largest possible value for idum at the point the coord arrays are allocated?

That just changed the symptom. Probably the program now produces a wrong answer instead of the error messages.

I'm glad to see you understand that.

Perfect info, except that you didn't say where the value of idum comes from.

Often bugs like this are just off by one. If idum is a loop index ending at N such as
for (idum=1; idum<=N, idum++)
Then you just need (N+1) in place of N inside the malloc. Note those () are needed.

First of all, thanks again!

ok, this is even worse!

idum is an index initialized to zero at the beginning of the loop created to put data into the vectors, here is the part of the code:

idum=0;

while(!feof(coordf))
{
fscanf(coordf,%f,.....,&xbuf,&ybuf,...);
coordx[idum]=xbuf;
coordy[idum]=ybuf;
idum=idum+1;
}

so, if I understood well, I would guess that the problem is in the fact that idum becomes too big, but I have no idea of why this happens.
I tried to put idum=0; exactly at the end of the "while" cycle but it looks like the program doesn't like it.

That use of feof also looks to me like a bug. That is another common mistake. feof is not true until after the first failure to read at the end of the file. When all the data has been read and the file is positioned at the end, feof is still false.

I think the correct way to code that is:
Where did N come from in the code you posted earlier? Apparently, N was supposed to represent the maximum number of coordinates that might be in the file. Is that a number that would be practical to know when the function starts? Or is the whole design flawed?

If N were correct (though that seems doubtful) the bug with feof would be enough to cause the whole symptom. In which case the correction to the feof bug would fix the whole problem.

I never use fscanf in my own code, so I might be overlooking some other detail in my suggested correction. Hopefully other C programmers are reading this thread. I know that my suggestion doesn't make the program reliable in the face of bad input. I was just aiming for working if the input is good. (My own code always aims for reasonable responses to bad input, which rules out such simplistic uses of fscanf).

the part of code I posted before is in a function and the value of N is passed when the function is called by the main().
The value of N is unknown before starting the code because it is the size of the file read at the beginning.

I don't know what the feof is exactly, so I just tried to add a condition to the while cycle as follow:

idum=0;
while(!feof(coordf),idum<N)
{
.....
}

in this way it works because idum never gets bigger than N, but it might simply be, as before, that I just bypassed the problem instead of solving it!

That sounds like you may be saying the file gets read twice: Once before main calls this function (during which it can correctly compute N) and again inside the function that uses N. If that is how it works, then N could be exactly correct.

That has the same meaning in C as simply:
while(idum<N)
which might be correct.
If the value of N the program computed before calling this function was exactly correct, then your change to the while loop will work perfectly (solve the problem rather than bypass it).

I checked with several files and the program reads correctly the value of N and the main passes the correct value to the function.
With the condition I put on idum I don't have the problem anymore.

Wow, I'm really happy for that.

I really appreciate your help and I really thank you!!!!

Ashotti