crash: linklist_critical_enter: critical regions?
Hi,
I was wondering if someone recognizes the following and perhaps could tip me where to look for the problem.
When I paste-replace a number of subpatchers, each containing about 30 of my objects, max crashes. The chance that the crash occurs depends on how many subpatchers I replace and what type of computer I use. If I replace only 4 subpatchers, the crash never occurs. If I replace 64 subpatchers, the crash always occurs. The crash is more likely to occur on a macbook than on a macpro.
The crash has the following call stack:
0 com.cycling74.MaxMSP46 0x000df831 linklist_critical_enter(_linklist*) + 9 (linklist.c:25)
1 com.cycling74.MaxMSP46 0x000e0194 linklist_objptr2index + 30 (linklist.c:241)
2 com.cycling74.MaxAPI 0x018119e4 linklist_objptr2index + 37
3 com.opuslocus.oo.call 0x41e1e9ed oo_FreeObj + 82 (oo_call.c:386)
4 com.cycling74.MaxMSP46 0x000681e1 freeobject + 255 (utilities.c:429)
The code looks like this (including line numbers):
384 if(x->o_targetscope && x->o_targetscope->s_callers)
385 {
386 index = linklist_objptr2index(x->o_targetscope->s_callers, x);
387 if(index > -1) linklist_chuckindex(x->o_targetscope->s_callers, index);
388 }
s_callers is a linklist in object A that is accessed by multiple objects B. When a new object B is created, it adds items to this linklist and when an object B is removed, it chucks items from this linklist. So, when paste-replacing a lot of both objects A and B, there's a lot of creating, adding and chucking in this linklist.
Is this a case where I should start using critical regions?
I tried this:
critical_enter(0);
if(x->o_targetscope && x->o_targetscope->s_callers)
{
index = linklist_objptr2index(x->o_targetscope->s_callers, x);
if(index > -1) linklist_chuckindex(x->o_targetscope->s_callers, index);
}
critical_exit(0);
But this didn't change the problem.
All ideas are welcome.
Cheers,
Mattijs
Okaaayyy..
You won't believe this, but there is a (completely unrelated, afaik) javascript object in the same subpatcher. As soon as I remove this javascript object, the error stops occurring.
I'm completely at a loss but the error is gone. Now to find a way to access the script name inside my patch without using this javascript. .... ....
Mattijs
Yeah ... the intermittent crash-at-quit problems often seem to implicate the same code. I'd looked at adding a critical region around that code earlier, with no improvement. The linklist functions do appear to use their own critical regions where necessary anyway.
It's likely this is not anything to do with the s_callers code ... if something else is stomping on memory somewhere, the linklist could be getting screwed up, or maybe it's just stomping on stuff in the Max API? Perhaps the javascript removal is just affecting which areas of memory are getting stomped?
Might be time to look very closely at all the assigment (especially strings), allocation and free() operations in our code. Sigh.
Although now I think of a possible relation between the javascript and the crash: the javascript and the external both access the 'varname' of their containing patcher.. could there be a conflict there?
Btw, talking about critical regions only makes sense when there is a potential interference problem with the scheduler and the queue thread, right? And the paste-replace action completely takes place in the low priority queue. Is that correct? In that case it's no use talking about critical regions here.
Mattijs
It would be very unusual for this to cause crashing, unless there is
read-write access. Sounds to me like it's only reading, which should
be pretty safe, unless something is modifying the linked list behind
the scenes.
Critical regions are important on multi-processor machines, where
several processing tasks might be happening at once. You might try
disabling one of your processors to see if the problem disappears.
jb
Am 04.01.2008 um 11:41 schrieb Mattijs Kneppers:
>
> Although now I think of a possible relation between the javascript
> and the crash: the javascript and the external both access the
> 'varname' of their containing patcher.. could there be a conflict
> there?
>
> Btw, talking about critical regions only makes sense when there is a
> potential interference problem with the scheduler and the queue
> thread, right? And the paste-replace action completely takes place
> in the low priority queue. Is that correct? In that case it's no use
> talking about critical regions here.
>
> Mattijs
> --
> SmadSteck - http://www.smadsteck.nl
> Hard- and software for interactive audiovisual sampling