'invalid fastbin entry (free)
I am trying to find the cause for:
*** glibc detected *** ...: invalid fastbin entry (free): 0x00007fc384ced120 ***
The program dumped core, so I was able to trace this back to a destructor of a very simple class similar to this:
class foo : public foo_base
{
...
...
std::vector<boost::weak_ptr<bar> > vec;
}
The destructor is virtual in foo_base
and not implemented in foo
The vector vec
is only assigned to in the constructor and not modified thereafter.
The address mentioned by the glibc error is identical to vec._M_impl._M_start
Where could I start searching for the cause?
Knowing what a fastbin is, how can it be invalid?
Could this be a double free situation, or would glibc definitely raise a
double free
in this case?
Solution 1:[1]
To "answer" my own question:
I was able to rule out a double free situation, because it turned out that all foo
instances were always (correctly) kept in smart pointers.
A memory corruption bug has recently been found. It is impossible to confirm this to have been the cause for the original problem, but it seems reasonable.
The problem was never reproduced.
Solution 2:[2]
This may be due to a bug in glibc
.
The RedHat Advisories provide additional details:
https://rhn.redhat.com/errata/RHBA-2014-0480.html
To identify if you are affected by this bug:
rpm -qa | grep glibc
If your version of glibc
is 2.12
and doesn't have a .149
or later suffix, then your server may be affected by this issue.
Solution 3:[3]
For me this error came out of pytorch torch api for c++
I'm a noob still at the subject, but error rises when:
torch::Tensor var = torch::zeros({1, 1}, torch::kFloat32);
torch::Tensor foo = torch::full({1, 1}, val, torch::kFloat32);
It went away when:
torch::Tensor var = torch::zeros({1, 1}, torch::kFloat64);
torch::Tensor foo = torch::full({1, 1}, val, torch::kFloat64);
Sources
This article follows the attribution requirements of Stack Overflow and is licensed under CC BY-SA 3.0.
Source: Stack Overflow
Solution | Source |
---|---|
Solution 1 | idefixs |
Solution 2 | J. Chomel |
Solution 3 | savethebeesandseeds |