[jira] [Updated] (GEODE-8535) Coredump while putting an entry to a LocalRegion

["Mario Salazar de Torres (Jira)" <ji...@apache.org>]

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

Mario Salazar de Torres updated GEODE-8535:
-------------------------------------------
    Attachment: coredump.log
                notifications-no-massif.log

> Coredump while putting an entry to a LocalRegion
> ------------------------------------------------
>
>                 Key: GEODE-8535
>                 URL: https://issues.apache.org/jira/browse/GEODE-8535
>             Project: Geode
>          Issue Type: Bug
>          Components: native client
>    Affects Versions: 1.13.0
>            Reporter: Mario Salazar de Torres
>            Priority: Major
>         Attachments: coredump.log, notifications-no-massif.log
>
>
> The scenario is the following:
> *GIVEN* concurrency-checks-enabled=true (as default) for the region in which the put operation is happening.
> *GIVEN* tombstone-timeout=10ms
> *WHENEVER* a huge load (hundreds per second) of LOCAL_CREATE, LOCAL_DESTROY notifications are received in the client for the same region and consecutive keys, as below example shows:
> {code:java}
> t_0: LOCAL_CREATE for key entry-1
> t_1: LOCAL_DESTROY for key entry-1
> t_2: LOCAL_CREATE for key entry-2
> t_3: LOCAL_DESTROY for key entry-2
> ·
> ·
> ·
> t_(2*(n-1)): LOCAL_CREATE for key entry-n
> t_(2*n-1): LOCAL_DESTROY for key entry-n{code}
> *THEN* the application crashes, in many different places, but as for the case reported here, whenever trying access the virtual destructor pointing of the ExpiryHandlerTask, which turns out to be nullptr.
>  
> Find segmentation report attached as *coredump.log* and also, geode-native debug log attached as *notifications-no-massif.log*
>  



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