freeing stuff (c)

Euphoric Nightmare · 2005-09-10 22:36:02

Here's my question:

In C, after I free something that i've calloc'ed or malloc'ed, can I start over and use those variables again with malloc?

I have a while loop that malloc's a bunch of stuff, and a the end of my loop it frees them. During the second iteration, it always segfaults, with a a strtod error (according to gdb). gdb also reveals that the everything that was previously malloc'ed is now empty.

I realized my pseudo code examples are quite annoying, but if anyone has any suggestiong i would appreciate that. If it would help to look at my source, i could link to it or something.

EDIT: I should also mention that when i take out my free statements everything runs great.

Dusty · 2005-09-10 23:07:15

I understand the question (I think I do, anyway), but I have a question in response. Why are you freeing the variables if you are not done with them? Calls to free and malloc take time. Why not allocate the memory before the loop, if possible, and free it afterwards?

Of course, in python you don't have to worry about this stuff. Java neither, come to think.

Dusty

Euphoric Nightmare · 2005-09-11 00:03:18

Dusty wrote:

I understand the question (I think I do, anyway), but I have a question in response. Why are you freeing the variables if you are not done with them? Calls to free and malloc take time. Why not allocate the memory before the loop, if possible, and free it afterwards?
Of course, in python you don't have to worry about this stuff. Java neither, come to think.
Dusty

The reason I'm freeing these is because the amount of space needed is variable. i might need enough space for 5 chars 2 doubles, etc., the next iteration might need 25 chars 6 doubles, etc. I thought it would be best to allocate the space as I need it.

Dusty · 2005-09-11 00:18:39

I am not a C programmer, so don't know the answer. malloc and free are the reasons I'm not a C programmer. :-D

It might help to post some code.

Dusty

Euphoric Nightmare · 2005-09-11 01:07:45

http://www.sitesled.com/members/enightmare/calc.c

I have some pointers defined in the loop, but it should be before the while loop, i just changed that to test something. I also have one of the free calls commented out. That should also not be commented out. Again I was testing.

EDIT: i think i just found a mistake in posting the code. I didn't free all of the *element's. But thats obviously not causing the segfaults, because if i take out the free statements it never segfaults.

I apologize if my code isn't neat enough.

Dusty · 2005-09-11 01:36:33

Euphoric Nightmare wrote:

http://www.sitesled.com/members/enightmare/calc.c

hmm, yeah, that's C. I really can't help. I can read it, but not debug it, lol. I would have expected somebody else to have posted by now, but I don't know how many C programmers we have here...

I apologize if my code isn't neat enough.

<jab>If your code was neat enough, it would be python.</jab>

Dusty

awalk · 2005-09-11 03:13:25

The variable "operators" is a character array, which you've allocated with calloc. You only need to free(operators) at the end, not the individual elements.

Hmm, that's probably the error you found. It still crashes... *keeps looking*

You're freeing inString in the while loop; do it immediately after. In fact, since you're only ever allocating inString and inString2 once each, to a static number of characters, you may as well allocate them on the stack.

Valgrind is an excellent tool for debugging. Much simpler to use than GDB.

Last, but not least, the logic for handling the "exit" string isn't correct. Type it in in the first iteration, and you'll see what I mean. Unless of course it's meant to go through the entire loop of the body until the 2nd iteration, and then quit

Euphoric Nightmare · 2005-09-11 03:37:33

awalk wrote:

The variable "operators" is a character array, which you've allocated with calloc. You only need to free(operators) at the end, not the individual elements.
Hmm, that's probably the error you found. It still crashes... *keeps looking*
You're freeing inString in the while loop; do it immediately after. In fact, since you're only ever allocating inString and inString2 once each, to a static number of characters, you may as well allocate them on the stack.
Valgrind is an excellent tool for debugging. Much simpler to use than GDB.
Last, but not least, the logic for handling the "exit" string isn't correct. Type it in in the first iteration, and you'll see what I mean. Unless of course it's meant to go through the entire loop of the body until the 2nd iteration, and then quit

Your first suggestion...on operators--I noticed that just after i posted it.

I can't believe I didn't catch me freeing inString. I bet thats what's causing the crash. I'll have to fix that tomorrow.

As for the exit string handling. I know its not working correctly yet, but I'll fix that later, I'm not particularly worried about it yet.

Thanks for checking out my code....and helping out.

phrakture · 2005-09-12 00:16:34

Ok, let me explain - the problem is that you're thinking of it in a non-C way. Try to think of it this way:

When you malloc something, the "variable" is hanging out in some unknown place.... the only thing you have is a pointer to that unknown place. When you "free" that variable, the pointer is still there, but the place it points to is no longer valid. There is no problem with changing where that pointer points once the location is freed (be very careful though, because that's how you create memory leaks)

Euphoric Nightmare · 2005-09-12 00:22:18

phrakture wrote:

Ok, let me explain - the problem is that you're thinking of it in a non-C way. Try to think of it this way:
When you malloc something, the "variable" is hanging out in some unknown place.... the only thing you have is a pointer to that unknown place. When you "free" that variable, the pointer is still there, but the place it points to is no longer valid. There is no problem with changing where that pointer points once the location is freed (be very careful though, because that's how you create memory leaks)

I completely understand that. However, when I had this problem, I tried everything I could think of (apparently not enough), and I thought maybe I was using free wrong. It turns out, that I was freeing my main input string, and not reallocating it for use, and then attempting to use it again.

z4ziggy · 2005-09-13 03:20:06

if u keep reallocating memory, instead of freeing it each loop cycle, u better use realloc which will use stack memory more efficiently and also make your progy a bit faster (no free on each loop cycle). just remember to free the variable(s) once u done with them.

Euphoric Nightmare · 2005-09-13 04:08:07

I will...I just don't know how to use realloc yet. Scared I guess.

Dusty · 2005-09-13 14:31:52

man realloc

Euphoric Nightmare · 2005-09-13 16:01:14

Dusty wrote:

man realloc

Yeah yeah, I know. I'll do it later sometime.

phrakture · 2005-09-14 05:03:34

Euphoric Nightmare wrote:

Dusty wrote:
man realloc
Yeah yeah, I know. I'll do it later sometime.

Or you can use c++ in all it's glorious RAII wrappers and have no need for {re,m}alloc's

/me jabs C in the ribs

Euphoric Nightmare · 2005-09-14 20:39:46

phrakture wrote:

Euphoric Nightmare wrote:
Dusty wrote:
man realloc
Yeah yeah, I know. I'll do it later sometime.
Or you can use c++ in all it's glorious RAII wrappers and have no need for {re,m}alloc's
/me jabs C in the ribs

Why does everyone try to get me to switch languages all the time??

T-Dawg · 2005-09-14 20:58:12

Euphoric Nightmare wrote:

phrakture wrote:
Euphoric Nightmare wrote:
Yeah yeah, I know. I'll do it later sometime.
Or you can use c++ in all it's glorious RAII wrappers and have no need for {re,m}alloc's
/me jabs C in the ribs
Why does everyone try to get me to switch languages all the time??

why do people quote quotes inside quotes inside quotes?

You guys make me dizzy!

z4ziggy · 2005-09-14 21:15:14

Euphoric Nightmare wrote:

Why does everyone try to get me to switch languages all the time??

coding is like a religion. everyone tries to convert you to his own :twisted:

you'll get used to it... and eventually, you'll become a preacher yourself

and my last note - dont listen to c++ junkies (/me waits patiently for the wise remarks to follow...)

phrakture · 2005-09-14 21:20:28

Euphoric Nightmare wrote:

Why does everyone try to get me to switch languages all the time??

Hey, it's "On Of Those Things(TM)" - C programmers will say C is better and easier to use, and C++ programmers will say the same. I for one am a C++ programmer, though I have a wildly different style than most people. Most C++ people think that Polymorphism/Inheritance are godlike.

Well, that's just wrong. I don't feel those two bring much to the table. What I do like is the "Encapsulation" part of OO, which shows it's worth in C++ style RAII wrappers... for instance:

class xdisplay
{
   Display* d;
public:
   xdisplay() { d = XOpenDisplay(0); }
   ~xdisplay() { XCloseDisplay(d); }
   operator Display*() { return d; }
};

That class gives you the ability to never worry about closing the display or anything, as destuctors are always called (unless is segfaults or some other thing that will take down even the safest apps).

int main()
{
   xdisplay dpy;
   XCreateSimpleWindow(dpy, DefaultRootWindow(dpy), 0, 0, 200, 200, 1,
             BlackPixel(dpy,DefaultScreen(dpy)), WhitePixel(dpy,DefaultScreen(dpy)));

   return 0;
}

Euphoric Nightmare · 2005-09-15 01:32:28

phrakture wrote:

Euphoric Nightmare wrote:
Why does everyone try to get me to switch languages all the time??
Hey, it's "On Of Those Things(TM)" - C programmers will say C is better and easier to use, and C++ programmers will say the same. I for one am a C++ programmer, though I have a wildly different style than most people. Most C++ people think that Polymorphism/Inheritance are godlike.
Well, that's just wrong. I don't feel those two bring much to the table. What I do like is the "Encapsulation" part of OO, which shows it's worth in C++ style RAII wrappers... for instance:
class xdisplay
{
   Display* d;
public:
   xdisplay() { d = XOpenDisplay(0); }
   ~xdisplay() { XCloseDisplay(d); }
   operator Display*() { return d; }
};
That class gives you the ability to never worry about closing the display or anything, as destuctors are always called (unless is segfaults or some other thing that will take down even the safest apps).
int main()
{
   xdisplay dpy;
   XCreateSimpleWindow(dpy, DefaultRootWindow(dpy), 0, 0, 200, 200, 1,
             BlackPixel(dpy,DefaultScreen(dpy)), WhitePixel(dpy,DefaultScreen(dpy)));

   return 0;
}

i guess this is xlib stuff??? I hope i never have to do that stuff. I suppose i may want to hack at graphical stuff (NOT EWL!) someday. However, I will get plenty of C++ practice at school, since it is the primary language at my college, just have to wait forever. And there, i will have the best of both worlds.

phrakture · 2005-09-15 16:04:36

Euphoric Nightmare wrote:

i guess this is xlib stuff??? I hope i never have to do that stuff. I suppose i may want to hack at graphical stuff (NOT EWL!) someday. However, I will get plenty of C++ practice at school, since it is the primary language at my college, just have to wait forever. And there, i will have the best of both worlds.

Yes it's raw xlib... thing is that if you're doing graphical stuff you won't ever need to touch any of this stuff... you'd probably use some toolkit (like gtk/gtkmm)

Euphoric Nightmare · 2005-09-16 17:43:46

phrakture wrote:

Yes it's raw xlib... thing is that if you're doing graphical stuff you won't ever need to touch any of this stuff... you'd probably use some toolkit (like gtk/gtkmm)

Yeah, i was thinking of doing some xlib stuff, but i forget why.

Arch Linux

#1 2005-09-10 22:36:02

freeing stuff (c)

#2 2005-09-10 23:07:15

Re: freeing stuff (c)

#3 2005-09-11 00:03:18

Re: freeing stuff (c)

#4 2005-09-11 00:18:39

Re: freeing stuff (c)

#5 2005-09-11 01:07:45

Re: freeing stuff (c)

#6 2005-09-11 01:36:33

Re: freeing stuff (c)

#7 2005-09-11 03:13:25

Re: freeing stuff (c)

#8 2005-09-11 03:37:33

Re: freeing stuff (c)

#9 2005-09-12 00:16:34

Re: freeing stuff (c)

#10 2005-09-12 00:22:18

Re: freeing stuff (c)

#11 2005-09-13 03:20:06

Re: freeing stuff (c)

#12 2005-09-13 04:08:07

Re: freeing stuff (c)

#13 2005-09-13 14:31:52

Re: freeing stuff (c)

#14 2005-09-13 16:01:14

Re: freeing stuff (c)

#15 2005-09-14 05:03:34

Re: freeing stuff (c)

#16 2005-09-14 20:39:46

Re: freeing stuff (c)

#17 2005-09-14 20:58:12

Re: freeing stuff (c)

#18 2005-09-14 21:15:14

Re: freeing stuff (c)

#19 2005-09-14 21:20:28

Re: freeing stuff (c)

#20 2005-09-15 01:32:28

Re: freeing stuff (c)

#21 2005-09-15 16:04:36

Re: freeing stuff (c)

#22 2005-09-16 17:43:46

Re: freeing stuff (c)

Board footer