You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avro.apache.org by "Scott Banachowski (JIRA)" <ji...@apache.org> on 2009/11/18 20:26:39 UTC

[jira] Updated: (AVRO-210) Memory leak with recursive schemas when constructed by hand

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

Scott Banachowski updated AVRO-210:
-----------------------------------

    Status: Patch Available  (was: Open)

I went ahead and fixed this in patch AVRO-211.

Since the 2 issues touched the sames lines of code, 2 patches would be conflicting, so I just did it all in a single patch.


> Memory leak with recursive schemas when constructed by hand
> -----------------------------------------------------------
>
>                 Key: AVRO-210
>                 URL: https://issues.apache.org/jira/browse/AVRO-210
>             Project: Avro
>          Issue Type: Bug
>          Components: c++
>            Reporter: Thiruvalluvan M. G.
>
> Schema consists of a node or bunch of nodes. These nodes are represented as intrusive pointers of nodes (NodPtr). Since the intrusive pointers use reference counts, recursive schemas which result in cycles of intrusive pointers lead to memory leak. The following code, when compiled and run, causes the memory to grow steadily:
> {code:title=test.cc|borderStyle=solid}
> #include <unistd.h>
> #include "Schema.hh"
> int main(int argc, char** argv)
> {
>     const int count1 = 10;
>     const int count2 = 1000;
>     for (int i = 0; i < count1; i++) {
>         for (int j = 0; j < count2; j++) {
>             avro::RecordSchema rec("LongList");
>             rec.addField("value", avro::LongSchema());
>             avro::UnionSchema next;
>             next.addType(avro::NullSchema());
>             next.addType(rec);
>             rec.addField("next", next);
>             rec.addField("end", avro::BoolSchema());
>         }
>         sleep(1);
>     }
> }
> {code}
> The leak should not happen when we build the schema by parsing a JSON schema file. This is because the current implementation does not use pointers for symbolic links; it uses symbols and there is a symbol table that resolves the symbols at runtime. But unfortunately the nested schema file generates an error. I'll file a separate JIRA for that.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.