[ 
https://issues.apache.org/jira/browse/LUCY-315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Serkan Mulayim updated LUCY-315:
--------------------------------
    Description: 
A possible memory leak in the usage of SortSpec in IndexSearcher.

You can find the simple code at the end of this description demonstrating the 
issue. (sorry JIRA does not allow me to attach a file). Please do not 
concentrate on the 2 functions, testing_get_query and testing_get_schema. They 
do not cause any memory leaks, and not included in the code.

Please see the line   "Hits *hits = IxSearcher_Hits(searcher, (Obj*)query, 0, 
10,  sortSpec);" in the code. 

When we use a SortSpec in the searcher "IxSearcher_Hits(searcher, (Obj*)query, 
0, 10,  sortSpec)", valgrind detects a memory leak (24 bytes definitely lost). 

When we change ONLY one line to "IxSearcher_Hits(searcher, (Obj*)query, 0, 10,  
NULL)", valgrind does not detect the memory leaks.  The only difference is 
changing the sortSpec variable with NULL. In the code SortSpec is still being 
created the same way and DECREFfed the same way.  I suspect that the issue is 
in DECREF(searcher) and it is not cleaning up some objects in searcher that are 
related to the sortSpec.

Valgrind command is "valgrind --leak-check=full --show-leak-kinds=all  
vectortest".

Output when sortSpec is passed into the IxSearcher_Hits, valgrind output is as 
following:

==67956== LEAK SUMMARY:
==67956==    definitely lost: 24 bytes in 1 blocks
==67956==    indirectly lost: 0 bytes in 0 blocks
==67956==      possibly lost: 0 bytes in 0 blocks
==67956==    still reachable: 223,323 bytes in 4,919 blocks
==67956==         suppressed: 34,896 bytes in 427 blocks


Output when NULL is passed into the IxSearcher_Hits, valgrind output is as 
following:

==67818== LEAK SUMMARY:
==67818==    definitely lost: 0 bytes in 0 blocks
==67818==    indirectly lost: 0 bytes in 0 blocks
==67818==      possibly lost: 0 bytes in 0 blocks
==67818==    still reachable: 223,323 bytes in 4,919 blocks
==67818==         suppressed: 34,896 bytes in 427 blocks

-----------------------------------------Code: 
test.c-----------------------------------------------

#include <stdio.h>
#include <stdlib.h>
#include <string.h>


#define CFISH_USE_SHORT_NAMES
#define LUCY_USE_SHORT_NAMES
#include "Lucy/Plan/Schema.h"
#include "Lucy/Plan/StringType.h"
#include "Lucy/Plan/FullTextType.h"
#include "Lucy/Analysis/EasyAnalyzer.h"
#include "Lucy/Index/Indexer.h"
#include "Lucy/Search/QueryParser.h"
#include "Lucy/Search/RangeQuery.h"
#include "Lucy/Search/ANDQuery.h"
#include "Lucy/Search/SortRule.h"
#include "Lucy/Search/SortSpec.h"
#include "Lucy/Search/Hits.h"
#include "Lucy/Document/HitDoc.h"
#include "Lucy/Search/IndexSearcher.h"

#include "Clownfish/Vector.h"
#include "Clownfish/String.h"

#define SEARCH_FIELD_INGESTION_DATE "ingestionDate"

static Query* testing_get_query(Schema *schema, const char * query_str, const 
char* startDate, const char *endDate);
static Schema* testing_get_schema(char* lang);

int main() \{
        lucy_bootstrap_parcel();

        Schema* schema = testing_get_schema("en");
        String *folder = Str_newf("%s/%s", "searchIndex", "testIndex1");
        Query *query = testing_get_query(schema, "hello", "0000000000000", 
"9999999999999");

        IndexSearcher *searcher = IxSearcher_new((Obj*) folder);

        String *field_date_str = Str_newf(SEARCH_FIELD_INGESTION_DATE);
        SortRule *sortRule = SortRule_new(SortRule_FIELD, field_date_str, 0);

        Vector *sortRules = Vec_new(1);
        Vec_Push(sortRules, (Obj*) sortRule);
        SortSpec *sortSpec = SortSpec_new(sortRules);

        Hits *hits = IxSearcher_Hits(searcher, (Obj*) query, 0, 10,  sortSpec);

        DECREF(field_date_str);
        DECREF(sortRules);
        DECREF(sortSpec);
        DECREF(schema);
        DECREF(folder);
        DECREF(query);
        DECREF(hits);
        DECREF(searcher);
\}

--------------------------------------------------------------------------------------------------------


  was:
A possible memory leak in the usage of SortSpec in IndexSearcher.

You can find the simple code at the end of this description demonstrating the 
issue. (sorry JIRA does not allow me to attach a file). Please do not 
concentrate on the 2 functions, testing_get_query and testing_get_schema. They 
do not cause any memory leaks, and not included in the code.

Please see the line   "Hits *hits = IxSearcher_Hits(searcher, (Obj*)query, 0, 
10,  sortSpec);" in the code. 

When we use a SortSpec in the searcher "IxSearcher_Hits(searcher, (Obj*)query, 
0, 10,  sortSpec)", valgrind detects a memory leak (24 bytes definitely lost). 

When we change ONLY one line to "IxSearcher_Hits(searcher, (Obj*)query, 0, 10,  
NULL)", valgrind does not detect the memory leaks.  The only difference is 
changing the sortSpec variable with NULL. In the code SortSpec is still being 
created the same way and DECREFfed the same way.  I suspect that the issue is 
in DECREF(searcher) and it is not cleaning up some objects in searcher that are 
related to the sortSpec.

Valgrind command is "valgrind --leak-check=full --show-leak-kinds=all  
vectortest".

Output when sortSpec is passed into the IxSearcher_Hits, valgrind output is as 
following:

==67956== LEAK SUMMARY:
==67956==    definitely lost: 24 bytes in 1 blocks
==67956==    indirectly lost: 0 bytes in 0 blocks
==67956==      possibly lost: 0 bytes in 0 blocks
==67956==    still reachable: 223,323 bytes in 4,919 blocks
==67956==         suppressed: 34,896 bytes in 427 blocks


Output when NULL is passed into the IxSearcher_Hits, valgrind output is as 
following:

==67818== LEAK SUMMARY:
==67818==    definitely lost: 0 bytes in 0 blocks
==67818==    indirectly lost: 0 bytes in 0 blocks
==67818==      possibly lost: 0 bytes in 0 blocks
==67818==    still reachable: 223,323 bytes in 4,919 blocks
==67818==         suppressed: 34,896 bytes in 427 blocks

-----------------------------------------Code: 
test.c-----------------------------------------------

#include <stdio.h>
#include <stdlib.h>
#include <string.h>


#define CFISH_USE_SHORT_NAMES
#define LUCY_USE_SHORT_NAMES
#include "Lucy/Plan/Schema.h"
#include "Lucy/Plan/StringType.h"
#include "Lucy/Plan/FullTextType.h"
#include "Lucy/Analysis/EasyAnalyzer.h"
#include "Lucy/Index/Indexer.h"
#include "Lucy/Search/QueryParser.h"
#include "Lucy/Search/RangeQuery.h"
#include "Lucy/Search/ANDQuery.h"
#include "Lucy/Search/SortRule.h"
#include "Lucy/Search/SortSpec.h"
#include "Lucy/Search/Hits.h"
#include "Lucy/Document/HitDoc.h"
#include "Lucy/Search/IndexSearcher.h"

#include "Clownfish/Vector.h"
#include "Clownfish/String.h"

#define SEARCH_FIELD_INGESTION_DATE "ingestionDate"

static Query* testing_get_query(Schema *schema, const char * query_str, const 
char* startDate, const char *endDate);
static Schema* testing_get_schema(char* lang);

int main() \{
        lucy_bootstrap_parcel();

        Schema* schema = testing_get_schema("en");
        String *folder = Str_newf("%s/%s", "searchIndex", "testIndex1");
        Query *query = testing_get_query(schema, "hello", "0000000000000", 
"9999999999999");

        IndexSearcher *searcher = IxSearcher_new((Obj*)folder);

        String *field_date_str = Str_newf(SEARCH_FIELD_INGESTION_DATE);
        SortRule *sortRule = SortRule_new(SortRule_FIELD, field_date_str, 0);

        Vector *sortRules = Vec_new(1);
        Vec_Push(sortRules, (Obj*) sortRule);
        SortSpec *sortSpec = SortSpec_new(sortRules);

        Hits *hits = IxSearcher_Hits(searcher, (Obj*)query, 0, 10,  sortSpec);

        DECREF(field_date_str);
        DECREF(sortRules);
        DECREF(sortSpec);
        DECREF(schema);
        DECREF(folder);
        DECREF(query);
        DECREF(hits);
        DECREF(searcher);
\}

--------------------------------------------------------------------------------------------------------



> Memory leak in sortSpec
> -----------------------
>
>                 Key: LUCY-315
>                 URL: https://issues.apache.org/jira/browse/LUCY-315
>             Project: Lucy
>          Issue Type: Bug
>          Components: C bindings
>    Affects Versions: 0.6.0
>            Reporter: Serkan Mulayim
>
> A possible memory leak in the usage of SortSpec in IndexSearcher.
> You can find the simple code at the end of this description demonstrating the 
> issue. (sorry JIRA does not allow me to attach a file). Please do not 
> concentrate on the 2 functions, testing_get_query and testing_get_schema. 
> They do not cause any memory leaks, and not included in the code.
> Please see the line   "Hits *hits = IxSearcher_Hits(searcher, (Obj*)query, 0, 
> 10,  sortSpec);" in the code. 
> When we use a SortSpec in the searcher "IxSearcher_Hits(searcher, 
> (Obj*)query, 0, 10,  sortSpec)", valgrind detects a memory leak (24 bytes 
> definitely lost). 
> When we change ONLY one line to "IxSearcher_Hits(searcher, (Obj*)query, 0, 
> 10,  NULL)", valgrind does not detect the memory leaks.  The only difference 
> is changing the sortSpec variable with NULL. In the code SortSpec is still 
> being created the same way and DECREFfed the same way.  I suspect that the 
> issue is in DECREF(searcher) and it is not cleaning up some objects in 
> searcher that are related to the sortSpec.
> Valgrind command is "valgrind --leak-check=full --show-leak-kinds=all  
> vectortest".
> Output when sortSpec is passed into the IxSearcher_Hits, valgrind output is 
> as following:
> ==67956== LEAK SUMMARY:
> ==67956==    definitely lost: 24 bytes in 1 blocks
> ==67956==    indirectly lost: 0 bytes in 0 blocks
> ==67956==      possibly lost: 0 bytes in 0 blocks
> ==67956==    still reachable: 223,323 bytes in 4,919 blocks
> ==67956==         suppressed: 34,896 bytes in 427 blocks
> Output when NULL is passed into the IxSearcher_Hits, valgrind output is as 
> following:
> ==67818== LEAK SUMMARY:
> ==67818==    definitely lost: 0 bytes in 0 blocks
> ==67818==    indirectly lost: 0 bytes in 0 blocks
> ==67818==      possibly lost: 0 bytes in 0 blocks
> ==67818==    still reachable: 223,323 bytes in 4,919 blocks
> ==67818==         suppressed: 34,896 bytes in 427 blocks
> -----------------------------------------Code: 
> test.c-----------------------------------------------
> #include <stdio.h>
> #include <stdlib.h>
> #include <string.h>
> #define CFISH_USE_SHORT_NAMES
> #define LUCY_USE_SHORT_NAMES
> #include "Lucy/Plan/Schema.h"
> #include "Lucy/Plan/StringType.h"
> #include "Lucy/Plan/FullTextType.h"
> #include "Lucy/Analysis/EasyAnalyzer.h"
> #include "Lucy/Index/Indexer.h"
> #include "Lucy/Search/QueryParser.h"
> #include "Lucy/Search/RangeQuery.h"
> #include "Lucy/Search/ANDQuery.h"
> #include "Lucy/Search/SortRule.h"
> #include "Lucy/Search/SortSpec.h"
> #include "Lucy/Search/Hits.h"
> #include "Lucy/Document/HitDoc.h"
> #include "Lucy/Search/IndexSearcher.h"
> #include "Clownfish/Vector.h"
> #include "Clownfish/String.h"
> #define SEARCH_FIELD_INGESTION_DATE "ingestionDate"
> static Query* testing_get_query(Schema *schema, const char * query_str, const 
> char* startDate, const char *endDate);
> static Schema* testing_get_schema(char* lang);
> int main() \{
>       lucy_bootstrap_parcel();
>       Schema* schema = testing_get_schema("en");
>       String *folder = Str_newf("%s/%s", "searchIndex", "testIndex1");
>       Query *query = testing_get_query(schema, "hello", "0000000000000", 
> "9999999999999");
>       IndexSearcher *searcher = IxSearcher_new((Obj*) folder);
>       String *field_date_str = Str_newf(SEARCH_FIELD_INGESTION_DATE);
>       SortRule *sortRule = SortRule_new(SortRule_FIELD, field_date_str, 0);
>       Vector *sortRules = Vec_new(1);
>       Vec_Push(sortRules, (Obj*) sortRule);
>       SortSpec *sortSpec = SortSpec_new(sortRules);
>       Hits *hits = IxSearcher_Hits(searcher, (Obj*) query, 0, 10,  sortSpec);
>       DECREF(field_date_str);
>       DECREF(sortRules);
>       DECREF(sortSpec);
>       DECREF(schema);
>       DECREF(folder);
>       DECREF(query);
>       DECREF(hits);
>       DECREF(searcher);
> \}
> --------------------------------------------------------------------------------------------------------



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to