Mailing List archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[vdr] Re: thread safeness II (was: Re: Re: solved: segment faultsfrom osdtelext plugin)



Clemens Kirchgatterer wrote:
Rainer Zocholl <UseNet-Posting-Nospam-74308-@zocki.toppoint.de> wrote:


 static char *buffer = NULL;
 const char *p = s;

[..]


 return s; <======== is derivated from buffer, which is
 "(re)malloced"
           ( that will work every elegantly in single threading, but
             in multithreading two tasks overwrites or invalidates
             the memory of the other.)
}

why is buffer "static" when it contains an malloc pointer?
Is it it worth?

static is needed in this case. buffer would get lost between subsequent
calls to strescape otherwise. realloc on a NULL pointer is the same as
malloc and would produce a memleak.


So why no mutex while using that buffer?

is the function called from multiple threads? if yes there should be a
mutex around it.

[..] many suspect functions



Even if now it is absolutely clear for the programmer never to call
that code from different tasks: There is nothing that will
inhibit that "abuse", espacially in plugins.
"But here it is working" does not proof anything in a multithreaded
environemt. Here works also everthing. When i attach the debugger...
The timing windows are so small that they may never occure on a slow
machine(because the threads have never to sleep).

full ack.


Too the problem does not show up when it is caused.
For example the above implicit "free" may release memory that is still
pointed by a task which is sleeping for 24h hours.
So the segfault may occure 24h later, but only if meanwhile nothing
alloced memory in the same area. Then that third, totally unrelated function may show "funny effects"...happy debugging...

i would like to hear a comment from klaus, if he is sure not to call any
of these functions with static locals from different threads.

clemens
I am currently working in a totally different area (audio track handling,
AC3 over DVB via firmware) and so I'm afraid I can't get involved in this discussion
right now. I'll get back to this later.

Klaus




Home | Main Index | Thread Index