[SOLVED] problem in executing c program: glibc detected
Linux - NewbieThis Linux forum is for members that are new to Linux.
Just starting out and have a question?
If it is not in the man pages or the how-to's this is the place!
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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!
1)What program?
2)where did you get it ?
3)what command(s) are you using to invoke it ?
Quote:
While compiling I don't get any error message
4)what commands did you use to do that ?
( the build line would be nice )
Quote:
I tryed to type "rpm -q glibc"
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 "
I'm sure the problem doesn't come from the program because it's been already used.
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.
Quote:
So that I think that the problem is in the version of glibc that I use.
You are wrong.
Quote:
I am not an expert, neither with c language nor with Linux, so I have no idea where the problem could be!
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.
it's a program for filter data, I don't think it's importan to know what the program is supposed to do
Quote:
where did you get it ?
from the person who used it before, that's why I think it could be a problem with glibc
Quote:
what command(s) are you using to invoke it ?
./program-name
Quote:
what commands did you use to do that ?
(compiling)
I used: gcc program-name.c -o program-name -lm
Quote:
Why would you think that a red hat software installer would run on a Debian based OS ?
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?
t's a program for filter data, I don't think it's importan to know what the program is supposed to do
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 )
Quote:
from the person who used it before, that's why I think it could be a problem with glibc
on what operating system did they run this program?
i am betting it was not on ubuntu 11.10
Quote:
gcc program-name.c -o program-name -lm
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
because if it is a 15 year old program it will NOT easily run on a new operating system
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.
Quote:
operating system did they run this program?
i am betting it was not on ubuntu 11.10
Not relevant.
Quote:
so what it looks like you are experiencing is trying to run a program WROTE for a very different operating system
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.
Quote:
Originally Posted by Ashotti
Could Valgrind help me somehow?
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.
Quote:
it's a program for filter data, I don't think it's importan to know what the program is supposed to do
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.
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.
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!
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?
Quote:
I just changed the code declaring coordx[N] and coordy[N] at the beginning without using the allocatable memory
That just changed the symptom. Probably the program now produces a wrong answer instead of the error messages.
Quote:
I would be quite surprise if the problem stems simply from the use of the malloc function!
I'm glad to see you understand that.
Quote:
I hope that what I want to say is understandable even though I'm not able to use a technical jargon!
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.
That just changed the symptom. Probably the program now produces a wrong answer instead of the error messages.
ok, this is even worse!
Quote:
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.
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:
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.
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).
Where did N come from in the code you posted earlier?
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!
The value of N is unknown before starting the code because it is the size of the file read at the beginning.
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.
Quote:
while(!feof(coordf),idum<N)
That has the same meaning in C as simply:
while(idum<N)
which might be correct.
Quote:
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!
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.
Quote:
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).
Wow, I'm really happy for that.
I really appreciate your help and I really thank you!!!!
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.