You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hbase.apache.org by "Nick Dimiduk (Jira)" <ji...@apache.org> on 2020/03/26 16:53:00 UTC

[jira] [Resolved] (HBASE-23258) Reconsider the DBB memory leak in the exceptional paths.

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

Nick Dimiduk resolved HBASE-23258.
----------------------------------
    Fix Version/s:     (was: 2.3.0)
                       (was: 3.0.0)
       Resolution: Not A Problem

Closing -- it is believed that this was addressed by HBASE-22480.

> Reconsider the DBB memory leak in the exceptional paths.
> --------------------------------------------------------
>
>                 Key: HBASE-23258
>                 URL: https://issues.apache.org/jira/browse/HBASE-23258
>             Project: HBase
>          Issue Type: Bug
>            Reporter: Zheng Hu
>            Assignee: Zheng Hu
>            Priority: Major
>
> Have a discussion with [~anoop.hbase],  we find still have some exceptional paths which we did not handle DBB#release correctly. More details are the following: 
> {code}
> > HFileReaderImpl#validateBlockType - When throws Exception, the get block is gone. Want to return?
> Yeah, we've two cases to validateBlockType. one is reading from cache, another one is reading from hfile. 
> we've abstracted the block for both cache types and hfiles ( ex release the block from heap will donothing), so
> here seems we should do release if throws IOException.
> > Only inside another condition we return and evict block
> readBlock - The got block is unused when we throw Exception on DBE type mismatch
> Em..we return null finally , seems the block also need to release the block.
> {code}
> Will take a look around  all the exceptional paths and consider any other DBB leak issues.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)