Error: "corrupted size vs. prev_size Aborted"
Hey!
I am not sure what this error means, never got it before. I don't know why would I get this error when my code was running perfectly few days ago?
I am not sure what this error means, never got it before. I don't know why would I get this error when my code was running perfectly few days ago?
|
|
Last edited on
https://stackoverflow.com/questions/49628615/understanding-corrupted-size-vs-prev-size-glibc-error
You wrote past the end of an array.
You wrote past the end of an array.
Okay, I get it I guess. I ran valgrind as well since it seems that there could be either memory not being freed or something that's freed twice. Valgrind shows there's a memory leak at two functions specifically. The problem, I have freed everything there (that I can see) and checked for my arrays if I've written past them (again I don't see anything).
Let me rephrase that. I stated something too specifically when I should have been more general.
You, directly or indirectly, wrote to memory you shouldn't have. There's multiple ways this might have happened. it might have been by literally writing beyond the end of an array, but there are other ways. A double free is another. Incorrectly using certain standard functions can also do that. Valgrind should help you to, tediously, find the culprit.
You, directly or indirectly, wrote to memory you shouldn't have. There's multiple ways this might have happened. it might have been by literally writing beyond the end of an array, but there are other ways. A double free is another. Incorrectly using certain standard functions can also do that. Valgrind should help you to, tediously, find the culprit.
> I don't know why would I get this error when my code was running perfectly few days ago?
Do you use git / mercurial / anything ?
You should be making at least daily commits to your local repo. Or better yet, after every edit/test cycle which improved the program in some way.
With a repo, you could have done a diff between what "worked" and what is broken.
With a repo, you could have checked out an older 'working' version, run it under valgrind to see if it was as good as you imagine it to be.
If you're doing any programming which is more than the single file throw away homework, it's the next essential tool right up there with the debugger.
Memory problems are insidious. It's all too easy for the first mistake to go unnoticed. By the time you actually notice, it could be a long time and a lot of changes. Worse still, where the problem shows up is often not where the real root cause is.
Valgrind is good for finding leaks in otherwise well behaved programs.
If you're looking for memory overruns and use-after-free problems, I'd suggest https://elinux.org/Electric_Fence
Run the program linked with electric fence in the debugger.
Oh, and never equate "working" as "bug-free".
You only have to see the regular stream of patches for pretty much everything you use to understand this.
Do you use git / mercurial / anything ?
You should be making at least daily commits to your local repo. Or better yet, after every edit/test cycle which improved the program in some way.
With a repo, you could have done a diff between what "worked" and what is broken.
With a repo, you could have checked out an older 'working' version, run it under valgrind to see if it was as good as you imagine it to be.
If you're doing any programming which is more than the single file throw away homework, it's the next essential tool right up there with the debugger.
Memory problems are insidious. It's all too easy for the first mistake to go unnoticed. By the time you actually notice, it could be a long time and a lot of changes. Worse still, where the problem shows up is often not where the real root cause is.
Valgrind is good for finding leaks in otherwise well behaved programs.
If you're looking for memory overruns and use-after-free problems, I'd suggest https://elinux.org/Electric_Fence
Run the program linked with electric fence in the debugger.
Oh, and never equate "working" as "bug-free".
You only have to see the regular stream of patches for pretty much everything you use to understand this.
@salem c
Thanks for the suggestion! I started committing everything on a more daily basis to avoid these problems in the future.
Thanks for the suggestion! I started committing everything on a more daily basis to avoid these problems in the future.
Topic archived. No new replies allowed.