2

我正在研究一个查询处理器,它从内存中读取长长的文档 ID 列表并查找匹配的 ID。当它找到一个时,它会创建一个包含 docid(一个 int)和文档的排名(一个 double)的 DOC 结构,并将其推送到优先级队列中。我的问题是,当搜索的单词有很长的列表时,当我尝试将 DOC 推送到队列时,出现以下异常: QueryProcessor.exe 中 0x7c812afb 处的未处理异常:Microsoft C++ 异常:std: :bad_alloc 在内存位置 0x0012ee88..

当单词有一个简短的列表时,它可以正常工作。我尝试在代码中的多个位置将 DOC 推送到队列中,它们都可以工作到某一行;之后,我收到上述错误。我完全不知道出了什么问题,因为读入的最长列表小于 1 MB,并且我释放了我分配的所有内存。当我尝试将 DOC 推送到有容量容纳它的队列上时,为什么会突然出现 bad_alloc 异常(我使用了一个保留了足够空间的向量作为优先级队列的底层数据结构)?

我知道如果不看所有代码几乎不可能回答这样的问题,但是在这里发布太长了。我正在尽我所能,并焦急地希望有人能给我一个答案,因为我无能为力。

NextGEQ 函数逐块读取压缩的 docid 块列表。也就是说,如果它发现块中的 lastdocid(在一个单独的列表中)大于传入的 docid,它会解压块并搜索,直到找到正确的。每个列表都以关于列表的元数据开始,其中包含每个压缩块的长度和块中的最后一个 docid。data.iquery 指向元数据的开头;data.metapointer 指向元数据中函数当前所在的位置;并且 data.blockpointer 指向未压缩 docid 块的开头,如果有的话。如果它看到它已经解压缩,它只是搜索。下面,当我第一次调用该函数时,它解压了一个块并找到了docid;之后推送到队列中。第二次,它没有 甚至需要解压;也就是说,没有分配新的内存,但在那之后,推送到队列会产生一个 bad_alloc 错误。

编辑:我清理了我的代码,以便它应该编译。我还添加了 OpenList() 和 NextGEQ 函数,虽然后者很长,因为我认为问题是由其中某处的堆损坏引起的。非常感谢!

struct DOC{

    long int docid;
    long double rank;

public:
    DOC()
    {
        docid = 0;
        rank = 0.0;
    }

    DOC(int num, double ranking)
    {
        docid = num;
        rank = ranking;

    }

     bool operator>( const DOC & d ) const {
       return rank > d.rank;
    }

      bool operator<( const DOC & d ) const {
       return rank < d.rank;
    }
    };

struct listnode{

int* metapointer;
int* blockpointer;
int docposition;
int frequency;
int numberdocs;
int* iquery;
listnode* nextnode;

};

void QUERYMANAGER::SubmitQuery(char *query){

    listnode* startlist;

        vector<DOC> docvec;
        docvec.reserve(20);
        DOC doct;


    //create a priority queue to use as a min-heap to store the documents and rankings;


        priority_queue<DOC, vector<DOC>,std::greater<DOC>> q(docvec.begin(), docvec.end());

        q.push(doct);

    //do some processing here; startlist is a pointer to a listnode struct that starts the   //linked list

        //point the linked list start pointer to the node returned by the OpenList method

        startlist = &OpenList(value);
        listnode* minpointer;
        q.push(doct);


        //start by finding the first docid in the shortest list
            int i = 0;
            q.push(doct);
            num = NextGEQ(0, *startlist);
            q.push(doct);
            while(num != -1)
               {

            q.push(doct);

    //the is where the problem starts - every previous q.push(doct) works; the one after
    //NextGEQ(num +1, *startlist) gives the bad_alloc error

            num = NextGEQ(num + 1, *startlist);

         //this is where the exception is thrown
            q.push(doct);               
        }

    }



//takes a word and returns a listnode struct with a pointer to the beginning of the list
//and metadata about the list 
listnode QUERYMANAGER::OpenList(char* word)
{
    long int numdocs;

    //create a new node in the linked list and initialize its variables


    listnode n;
    n.iquery = cache -> GetiList(word, &numdocs);
    n.docposition = 0;
    n.frequency = 0;
    n.numberdocs = numdocs;

   //an int pointer to point to where in the metadata you are
    n.metapointer = n.iquery;
    n.nextnode = NULL;
  //an int pointer to point to the uncompressed block of data, if there is one
    n.blockpointer = NULL;



    return n;


}


int QUERYMANAGER::NextGEQ(int value, listnode& data)
{
     int lengthdocids;
     int lengthfreqs; 
     int lengthpos;
     int* temp;
     int lastdocid;


     lastdocid = *(data.metapointer + 2);

while(true)
{

         //if it's not the first chunk in the list, the blockpointer will be pointing to the 
        //most recently opened block and docpos to the current position in the block
    if( data.blockpointer && lastdocid >= value)
    {

            //if the last docid in the chunk is >= the docid we're looking for,
            //go through the chunk to look for a match


        //the last docid in the block is in lastdocid; keep going until you hit it
        while(*(data.blockpointer + data.docposition) <= lastdocid)
        {
            //compare each docid with the docid passed in; if it's greater than or equal to it, return a pointer to the docid
             if(*(data.blockpointer + data.docposition ) >= value)
             {

                 //return the next greater than or equal docid
                 return *(data.blockpointer + data.docposition);
             }
             else
             {
                 ++data.docposition;
             }
        }

        //read through the whole block; couldn't find matching docid; increment metapointer to the next block;
        //free the block's memory

        data.metapointer += 3;
        lastdocid = *(data.metapointer + 3);
        free(data.blockpointer);
        data.blockpointer = NULL;
    }


        //reached the end of a block; check the metadata to find where the next block begins and ends and whether 
        //the last docid in the block is smaller or larger than the value being searched for


        //first make sure that you haven't reached the end of the list
            //if the last docid in the chunk is still smaller than the value passed in, move the metadata pointer
           //to the beginning of the next chunk's metadata; read in the new metadata


            while(true)
         //  while(*(metapointers[index]) != 0 )
           {
               if(lastdocid < value && *(data.metapointer) !=0)
               {
               data.metapointer += 3;
               lastdocid = *(data.metapointer + 2);
               }


           else if(*(data.metapointer) == 0)
           {
               return -1;
             }

           else
               //we must have hit a chunk whose lastdocid is >= value; read it in
           {
                //read in the metadata
           //the length of the chunk of docid's is cumulative, so subtract the end of the last chunk 
           //from the end of this chunk to get the length

               //find the end of the metadata


                temp = data.metapointer;

            while(*temp != 0)
            {
                temp += 3;
            }
                temp += 2;
    //temp is now pointing to the beginning of the list of compressed data; use the location of metapointer
    //to calculate where to start reading and how much to read

         //if it's the first chunk in the list,the corresponding metapointer is pointing to the beginning of the query
        //so the number of bytes of docid's is just the first integer in the metadata
                if(  data.metapointer == data.iquery)
                {
                    lengthdocids = *data.metapointer;

                }

                else
                {
                    //start reading from the offset of the end of the last chunk (saved in metapointers[index] - 3)
                    //plus 1 = the beginning of this chunk

                    lengthdocids = *(data.metapointer) - (*(data.metapointer - 3));
                    temp += (*(data.metapointer - 3)) / sizeof(int); 

                   }


           //allocate memory for an array of integers - the block of docid's uncompressed
           int* docblock = (int*)malloc(lengthdocids * 5 );

           //decompress docid's into the block of memory allocated
            s9decompress((int*)temp, lengthdocids /4, (int*) docblock, true);

            //set the blockpointer to point to the beginning of the block
            //and docpositions[index] to 0
            data.blockpointer = docblock;
            data.docposition = 0;
            break;

                }

           } 

}
}

非常感谢,bsg。

4

4 回答 4

1

QUERYMANAGER::OpenList按值返回一个列表节点。startlist = &OpenList(value);然后继续获取返回的临时对象的地址。当临时消失时,您可能能够访问数据一段时间,然后将其覆盖。您可以在堆栈上声明一个非指针 listnode startlist 并直接为其分配返回值吗?然后把其他用途前面的*去掉,看看能不能解决问题。

于 2010-04-08T20:11:55.570 回答
1

您可以尝试的另一件事是用智能指针替换所有指针,特别是类似boost::shared_ptr<>的,具体取决于这实际上是多少代码以及您对自动化任务的舒适程度。智能指针并不是万能的,但它们至少比原始指针更安全。

于 2010-04-08T21:01:10.450 回答
0

假设您有堆损坏并且实际上并没有耗尽内存,那么堆损坏的最常见方法是删除(或释放)同一个指针两次。只需注释掉所有删除(或免费)调用,您就可以很容易地找出这是否是问题所在。这将导致您的程序像筛子一样泄漏,但如果它实际上没有崩溃,您可能已经确定了问题所在。

损坏堆的另一个常见原因是删除(或释放)从未在堆上分配的指针。区分腐败的两种原因并不总是那么容易,但您的首要任务应该是找出腐败是否真的是问题所在。

请注意,如果您要删除的内容具有析构函数,如果不调用该析构函数会破坏程序的语义,则此方法不会很好地工作。

于 2010-04-07T18:08:39.773 回答
0

感谢你的帮助。你是对的,尼尔——我一定设法破坏了我的堆。我仍然不确定是什么原因造成的,但是当我将 malloc(numdocids * 5) 更改为 malloc(256) 时,它神奇地停止了崩溃。我想我应该检查一下我的 malloc 是否真的成功了!再次感谢!BSG

于 2010-04-11T21:33:45.907 回答