0

I works on recommendation system. And my program contains the following code:

#include<vector>
using namespace std;
#define MAX_KEYWORD_NUM 2048
struct keyword_t
{
    char* str;
    int* p;
    //other stuff
};
class Myclass
{
public:
    bool add_keyword(keyword_t &keyword);
    int getValueFromConfigurationFile(const char *);
    bool reset()
private:
    vector<keyword_t>_keywords_vec;
    vector<keyword_t*>_pkeywords_vec;
    Myclass();
    //other stuff
};
Myclass::Myclass()
{
    _keywords_vec.reserve(MAX_KEYWORD_NUM);
}
bool Myclass::reset()
{
    _pkeywords_vec.clear();
    _keywords_vec.clear();
}
bool Myclass::add_keyword(keyword_t& keyword)
{
    int limit = getValueFromConfigurationFile("limit");
    int _keywords_num = _keywords_vec.size();
    if (_keywords_num >= limit) 
    {
        return false;
    }
    _keywords_vec.push_back(keyword);
    keyword_t* p_kw = &_keywords_vec[_keywords_num];
    _pkeywords_vec.push_back(p_kw);
    return true;
}

I define an object of Myclass in a thread and this thread will continually process incoming requests using this object.

Obviously, there is a potential problem in function add_keyword. That is if limit is greater than MAX_KEYWORD_NUM, _keywords_vec will be reallocated and all previous elements will probably be in different memory address. So, the pointers previously pushed into _pkeywords_vec will be dangling pointers and this will probably cause a core dump.

I do several experiments on it. However I got conflicting results.

Experiment A:

set the "limit" in configuration file to :3000, start the program, and it soon generates a core dump within one or two minutes.

Experiment B:

set the "limit" in configuration file to :2048, start the program, and after several minutes, change it to 3000. it also soon generates a core dump.

Experiment C:

set the "limit" in configuration file to :2048, start the program, and after some six hours, change it to 3000. it DO NOT generate any core dump and works perfectly well even for several days. I have make sure that limit has been changed to 3000 in this case.

All the experiments can be replicated.

How to explain Experiment C? Since Experiment C has been replicated thousands of times (different random requests), it is not likely that this is only undefined behavior. The possibility to generate core dump is obviously greater in Experiment A and B. So there should be something different between A\B and C.

Thanks.

user3458102
  • 21
  • 4
  • 3
    _"How to explain Experiment C?"_ - [Undefined Behavior](https://en.wikipedia.org/wiki/Undefined_behavior). – Captain Obvlious Nov 14 '15 at 18:01
  • 2
    Undefined behavior means, well ***undefined***. Expect nasal demons or your fridge exploding, nothing less. – πάντα ῥεῖ Nov 14 '15 at 18:13
  • Please point to the section in the standard that requires a core dump in any of these cases. – molbdnilo Nov 14 '15 at 18:17
  • Possible duplicate: [Undefined, unspecified and implementation-defined behavior](http://stackoverflow.com/questions/2397984/undefined-unspecified-and-implementation-defined-behavior). – n. m. could be an AI Nov 14 '15 at 18:35
  • Thanks. I have provided more info in my post – user3458102 Nov 14 '15 at 19:13
  • 1
    The answer is still the same. Undefined Behavior. It's undefined. It's not defined. Thus it can be **anything**. Even if you would go into the bowls of the dissasembled object and figured out the exact reason this is happening, a simple unrelated change in code, compiler update or another target will render your findings irrelevant. Undefined is undefined. – bolov Nov 14 '15 at 19:16
  • A crash is just the best thing you can hope for with UB. Your code can appear to work just fine, until it converts your customer's data into new virus code, taking out a quarter of our civilization. – Christopher Creutzig Nov 14 '15 at 22:26

0 Answers0