C++ stack overflow on desctruction of Set::View

Question

Hi,
I've encountered a problem when querying large sets of data from coherence.
Gven the following code;
          // load cache with a large data set
          char buff[128] = {0};
          for( int i = 0; i < 100000; ++i )
               sprintf_s(buff,128,"key%05d",i);
               // random binary data
               int len = 128 + rand() % 512;
               Array<octet_t>::Handle hab = Array<octet_t>::create(len);
               hCache->put(String::create(buff),hab);
        // query the cache, and print the results
          struct tmpIt
               Filter::View          vAll;
               Set::View               vSetResult;
          tmpIt *t = new tmpIt;
          t->vAll = AlwaysFilter::create();
                t->vSetResult = hCache->entrySet(t->vAll);
          // iterate over the results
          int ncount = 0;
        for (Iterator::Handle hIter = t->vSetResult->iterator(); hIter->hasNext(); )
            Map::Entry::View vEntry = cast<Map::Entry::View>(hIter->next());
               String::View     vKey   = cast<String::View>(vEntry->getKey());
            Object::View     vValue = vEntry->getValue();
               Array<octet_t>::Handle dt = cast<Array<octet_t>::Handle>(vEntry->getValue());
               ncount++;
               if( (ncount % 2000) == 0 )
                    std::cout << ncount << std::endl;
          // delete the struct, thus forcing the destruction of vSetResult
          delete t;On deleting the struct 't' causes a stack overflow deep within coherence. I'm guessing there's some kind of recursive delete that works on smaller data sets.
Can you please advise me on what to do in this situation, as this has put a halt to my coherence integrartion :)
Cheers
Rich
Edited by: user9929344 on 22-Oct-2008 01:57

Answer 1

Hi Rich,
I've tried your test out in a few environments using both debug and release builds and have not been able to reproduce the issue. My guess is that it may have something to do with your build settings. Can you try building it using the build.cmd script which we ship with the product. This can be done by creating a new subdirectory under examples for your test, for instance "overflow", place you source code in that directory and then from the examples directory run "build overflow". You can then run the test by executing "run overflow". This is how I've tested an all seems to be ok. Assuming this resolves the issues on your side, you can have a look at the compiler/linker settings used in the build.cmd script and try applying them to your build process. If this does not resolve the issue, it would be useful if you could send us a fully buildable example (and build script) which reproduces it. Also if you could include the OS and compiler versions that would help.
In testing your source code I ran into a few small things I thought I should point out to you.
- while loading if you batch your puts into a local HashMap and then do periodic hCache->putAll() operations loading will be faster:
     // load cache with a large data set
        char buff[128] = {0}; 
        Map::Handle hMapBatch = HashMap::create();
          for( int i = 0, c = atoi(argv[2]); i < c; ++i )
               sprintf(buff,"key%05d",i);
               // random binary data
               int len = 128 + rand() % 512;
               Array<octet_t>::Handle hab = Array<octet_t>::create(len);
               hMapBatch->put(String::create(buff),hab);
               if ((i % 2000) == 0)
                    hCache->putAll(hMapBatch);
                    hMapBatch->clear();
                    std::cout << "loaded " << i << std::endl;
        hCache->putAll(hMapBatch);
        hMapBatch->clear(); - During iteration you should not cast the values back to Handles, but rather only to Views. It is not guaranteed that the cache will return non-const references to the data.
I did validate that the test did not fail prior to making the above modifications.
thanks,
mark