Search Results

Search found 3 results on 1 pages for 'refcounting'.

Page 1/1 | 1 

  • Why did instruments report a leak while its ref count did become zero

    - by bromj
    Hello guys, green hand i am. I'm using instruments, and it did a great help to me so far, but I'm confused now 'cause it report a memory leak to me while its leaked block history shows me that the ref count of that memory had finally become 0. What does it mean? It's really embarrassing that I couldn't post a image here... so I have to describe it in text. Hope it would be clear enough for you: Event Type || RefCt || Responsible Library || Responsible Caller Malloc         || 1        || MyWeather              || +[ForecastData parseSingleForecastWithXMLElement:] Autorelease||           || MyWeather              || +[ForecastData parseSingleForecastWithXMLElement:] Retain         || 2        || MyWeather              || +[ForecastData parseWithData:] Release      || 1        || Foundation              || +[NSAutoreleasePool drain:] Retain         || 2        || Foundation              || +[NSThread initWithTarget:selector:object:] Release      || 1        || Foundation              || +[NSString compare:options:] Release      || 0        || MyWeather              || +[RootViewController dealloc] Any help will be appreciated~

    Read the article

  • Are memory barriers necessary for atomic reference counting shared immutable data?

    - by Dietrich Epp
    I have some immutable data structures that I would like to manage using reference counts, sharing them across threads on an SMP system. Here's what the release code looks like: void avocado_release(struct avocado *p) { if (atomic_dec(p->refcount) == 0) { free(p->pit); free(p->juicy_innards); free(p); } } Does atomic_dec need a memory barrier in it? If so, what kind of memory barrier? Additional notes: The application must run on PowerPC and x86, so any processor-specific information is welcomed. I already know about the GCC atomic builtins. As for immutability, the refcount is the only field that changes over the duration of the object.

    Read the article

  • new operator overwriting an existing object

    - by dvpdiner2
    I have a custom FastStack class, implemented as a fixed size array and an index into that array. In my copy constructor, I allocate the array and then assign each object from the copy's array into the new array. There's some refcounting in the objects on the stack, hence assignment is used rather than a simple copy. The problem is that when allocating the array, it sometimes overwrites part of the other stack's array. As can be expected, this leads to eventual segmentation faults when that data is dereferenced. class FastStack { private: int m_size, m_ptr; ObjectRef* m_stack; public: FastStack(int size) : m_size(size), m_ptr(-1) { m_stack = new ObjectRef[m_size]; } FastStack(const FastStack& copy) : m_size(copy.m_size), m_ptr(copy.m_ptr) { long a = (long)copy.m_stack[0]; m_stack = new ObjectRef[m_size]; if ((long)copy.m_stack[0] != a) fprintf(stderr, "\nWe have a serious problem!\n\n"); for (int i = 0; i <= m_ptr; i++) m_stack[i] = copy.m_stack[i]; } ~FastStack() { delete[] m_stack; } }; class ObjectRef { private: DataObj* m_obj; public: ObjectRef() : m_obj(0) { } ObjectRef(DataObj* obj) : m_obj(obj) { if (m_obj) m_obj->addRef(); } ObjectRef(const ObjectRef& obj) : m_obj(obj.m_obj) { if (m_obj) m_obj->addRef(); } ~ObjectRef() { if (m_obj) m_obj->delRef(); } ObjectRef& operator=(DataObj* obj) { if (obj) obj->addRef(); if (m_obj) m_obj->delRef(); m_obj = obj; return *this; } ObjectRef& operator=(const ObjectRef& obj) { if (obj.m_obj) obj.m_obj->addRef(); if (m_obj) m_obj->delRef(); m_obj = obj.m_obj; return *this; } }; I see that "We have a serious problem!" line shortly before a segfault, and stepping through it with gdb I can see that one of the ObjectRefs created by new has the same address as the other stack's array. My first instinct is to say that new should never be allocating memory that is already in use, but that clearly seems to be the case here and I am at a complete loss as to what can be done. Added: At the time that I see this happen, m_size = 2 and m_ptr = 0.

    Read the article

1