celix-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexander Broekhuis (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CELIX-213) SEGFAULT occurs due to memory access after memory is free'd
Date Tue, 03 Feb 2015 08:26:34 GMT

    [ https://issues.apache.org/jira/browse/CELIX-213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14302944#comment-14302944

Alexander Broekhuis commented on CELIX-213:

There are a couple of things here:
An entry should only be added if it conforms to the condition (store->debug or level !=
DEBUG), this condition is checked in the addEntry and in the thread. So entries destroyed
by the thread should not have been in the entries list. But as you mentioned, the addEntry
function does a cleanup (and destroy) if the number of log entries exceeds a certain threshold.
If multiple log entries are added in a short period of time, I can see how this might fail.

To prevent this, I've moved the trimming to after the condition has been send, and I've added
a remove of the entry from the listenerEntries list. Also added locking to prevent multiple
threads accessing the listenerEntries list at the same time.

If this still fails, can you give me some steps how to reproduce this?

> SEGFAULT occurs due to memory access after memory is free'd
> -----------------------------------------------------------
>                 Key: CELIX-213
>                 URL: https://issues.apache.org/jira/browse/CELIX-213
>             Project: Celix
>          Issue Type: Bug
>            Reporter: Daniel Parker
>            Assignee: Alexander Broekhuis
> log_listenerThread() accesses entries from the 'listenerEntries' list.  However, if the
corresponding entry had been removed and destroyed from the 'entries' list in log_addEntry(),
then accesses to it are invalid and can cause segfaults to occur.
> One solution is to remove the entry from the 'listenerEntries' list in log_addEntry()
to prevent it from being accessed later.
> Alternately, a reference count field could be added to the entry so that the system knows
when the entry can be destroyed.
> Additionally, it looks like log_listenerThread() and log_addEntry() can potentially modify
the 'listenerEntries' list at the same time so it needs another mutex for that list or a redesign
of how the other mutexes are locked or something.

This message was sent by Atlassian JIRA

View raw message