bad_alloc with no memory leak?
Pages: 12
|
|
From that we can see that you got some segmentation faults in your process about 1 day after the computer start with a different PID each time, probably in a development phase.
Then after about 3.5 days, you got a divide error somewhere in your process (probably a divizion by 0).It doesn't tell if it is in your code or in a library code however.
The divisions in the code you posted don't seem to be the problem, maybe in GetFrequency? But i don't see how a division by zero would cause a bad alloc exception so maybe it is not related at all
I believe it's a compiler problem related to the operating system. File-memory mapping is a very nasty function and makes a lot of problems... I don't think my code has a problem. Especially that, like I said, it worked when I reduced the size of the mapped part of the file!!! which is basically nothing related to the functionality of the program!!!
The allocation problem happens when defining a vector< vector<double> >, and assigning it to the output return of another function.
It's a bug. I bet!!!!
Thank you for everything :)
The allocation problem happens when defining a vector< vector<double> >, and assigning it to the output return of another function.
It's a bug. I bet!!!!
Thank you for everything :)
I could finally resolve the problem. It's a bug in many linux systems.
So the problem was, that my class mmap_cpp was re-using a function mmap_cpp::openfile();. This function involves unmapping the current map, closing the previously opened file, and reopening the new file, and mapping again.
It's definitely not effective to do it this way (I fixed it by adding a function mmap_cpp::remap()), nevertheless, the system shouldn't cause such exceptions.
I'm not sure how this error can be reported. This error showed up with different names under many Linux operating systems:
Ubuntu: Unable to open file, openfile simply returns -1 at non-specific points.
Mint: Unable to open file, open file simply returns -1 at non-specific points.
Fedora: Segmentation fault at some unpredictable specific point.
Cent OS: std::bad_alloc exception at some unpredictable specific point.
Note: error at specific point means that the system throws the error at the same point when the program is re-run many times.
All these operating systems threw these problems with the same code. Isn't this an obvious bug that has to be reported?
So the problem was, that my class mmap_cpp was re-using a function mmap_cpp::openfile();. This function involves unmapping the current map, closing the previously opened file, and reopening the new file, and mapping again.
It's definitely not effective to do it this way (I fixed it by adding a function mmap_cpp::remap()), nevertheless, the system shouldn't cause such exceptions.
I'm not sure how this error can be reported. This error showed up with different names under many Linux operating systems:
Ubuntu: Unable to open file, openfile simply returns -1 at non-specific points.
Mint: Unable to open file, open file simply returns -1 at non-specific points.
Fedora: Segmentation fault at some unpredictable specific point.
Cent OS: std::bad_alloc exception at some unpredictable specific point.
Note: error at specific point means that the system throws the error at the same point when the program is re-run many times.
All these operating systems threw these problems with the same code. Isn't this an obvious bug that has to be reported?
I could finally resolve the problem. It's a bug in many linux systems. |
What makes you say the bug is in Linux systems? It sounds to me like the bug is in your mmap_cpp<> class.
Because every operating system is giving a different error that has nothing to do with the behavior of the code. I mean, how could we get this different errors just because we reopen the same file many times rather than remapping it? does it make sense?
It's possible if your code is relying on undefined behavior, either at the language level or at the system level. The fact that different kernel versions are crashing your code at random points, or that the same kernel crashes your code with memory-related errors on the same point at random, is consistent with memory corruption by the application code.
I'm not saying that it's impossible to find a bug in the Linux kernel. I'm saying it's just much, much, much more likely that you're making a mistake than there being a bug in code thousands of people use and review every day. If you're going to report a bug, at least be completely sure that your code isn't buggy by running it through Valgrind, or try to reproduce the bug in the smallest code possible, so that you can have more solid evidence than "it crashes consistently". Otherwise you'll just get ignored.
I'm not saying that it's impossible to find a bug in the Linux kernel. I'm saying it's just much, much, much more likely that you're making a mistake than there being a bug in code thousands of people use and review every day. If you're going to report a bug, at least be completely sure that your code isn't buggy by running it through Valgrind, or try to reproduce the bug in the smallest code possible, so that you can have more solid evidence than "it crashes consistently". Otherwise you'll just get ignored.
Libraries on different systems are implemented differently, compiled with different options/etc. I think it is perfectly reasonable that a low level error (such as a memory problem) could show up differently on different systems.
You haven't posted all of your code, so I can't really analyze it. I could be talking garbage, but my instinct is that you are not calling munmap before closing the file, and you are in fact running out of process address space, not memory.
You haven't posted all of your code, so I can't really analyze it. I could be talking garbage, but my instinct is that you are not calling munmap before closing the file, and you are in fact running out of process address space, not memory.
Thank you for your answers, guys
I have showed Valgring results already at the beginning of these posts. Please check the result! it says my program manages memory perfectly. I'm very careful with memory management, since I use templates and std containers.
Under very strict conditions, the code has worked on Cent OS (explained in a previous post). I can't really get the right indications out of all this. I mean, all I do is mapping and unmapping and opening and closing files, which is all done automatically with no memory leaks, and which Valgrind has agreed to... how could I be doing a mistake? debuggers show errors at stupid places, like in an assignment of vectors (which doesn't make sense at all), and some times segmentation faults at resizing a vector! How would you handle such an error??? Even ddd (the debugger) failed in catching it!!
I'm just suggesting reporting this error because I'm out of options!!!! what could I do else to make sure the code has a bug? and btw, where can I report this? anyone has experience in such reporting, and whether it would go easily?
I have showed Valgring results already at the beginning of these posts. Please check the result! it says my program manages memory perfectly. I'm very careful with memory management, since I use templates and std containers.
Under very strict conditions, the code has worked on Cent OS (explained in a previous post). I can't really get the right indications out of all this. I mean, all I do is mapping and unmapping and opening and closing files, which is all done automatically with no memory leaks, and which Valgrind has agreed to... how could I be doing a mistake? debuggers show errors at stupid places, like in an assignment of vectors (which doesn't make sense at all), and some times segmentation faults at resizing a vector! How would you handle such an error??? Even ddd (the debugger) failed in catching it!!
I'm just suggesting reporting this error because I'm out of options!!!! what could I do else to make sure the code has a bug? and btw, where can I report this? anyone has experience in such reporting, and whether it would go easily?
| debuggers show errors at stupid places, like in an assignment of vectors (which doesn't make sense at all), and some times segmentation faults at resizing a vector! |
EDIT: Just so you know the kind of hard to find bug you may be facing here: one time I was getting crashes like you're getting now. They were all over the place; when opening files, when allocating memory, when freeing memory. There was no pattern. After running the program through Valgrind many times and watching its behavior very carefully, calling the debugger at just the right time revealed I was using an uninitialized variable as a switch expression, which wreak all sorts of havoc with the allocations that happened inside and propagated undefined behavior non-deterministically. This is why I'm almost completely sure it's a bug in your code.
Last edited on
OK. I'll do my deepest checks for uninitialised variables, and everything else possible. But this will take a while!
Thank you :)
Thank you :)
Topic archived. No new replies allowed.
Pages: 12