Mailing List archive

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

[vdr] Re: solved: segment faults from osdtelext plugin



luca@ventoso.org(Luca Olivetti)  04.12.04 18:20


>Rainer Zocholl wrote:
>>
>> After replacing all obviously/known not thread save clib calls
>> with their thread save counterparts osdteletext now runs!
>>
>> I would not waste any time to investigate which of those
>> calls are the minimum or why the seg faults are caused in detail.
>> There is no adavantage using non-thread save functions in a
>> multithreaded environment. The overhead is neglectable.

>Interesting. I've asked google and it told me that the tls ("thread
>local storage") version of the library doesn't need the _r version of
>the functions, and that could explain why not everybody is seeing the
>problem.
>However, that doesn't explain why *I* was not seeing it, since I'm
>running vdr with LD_ASSUME_KERNEL=2.4.1:

>[vdr@vdr vdr]$ LD_ASSUME_KERNEL=2.4.1 ldd vdr
>         linux-gate.so.1 =>  (0xffffe000)
>         libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x4002c000)
>         libpthread.so.0 => /lib/i686/libpthread.so.0 (0x4004b000)
>         libdl.so.2 => /lib/libdl.so.2 (0x4009d000)
>         libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x400a0000)
>         libm.so.6 => /lib/i686/libm.so.6 (0x40160000)
>         libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x40183000)
>         libc.so.6 => /lib/i686/libc.so.6 (0x4018c000)
>                           ^^^^ normal, non thread safe, version
>         /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)



Now i think i (maybe) know what's going on... with the recommandation
to set LD_ASSUME_KERNEL=2.4.1!

If you don't set it, you will get "thread local data",
not just an reentrant "ctime".
If you now define a mutex, that mutex will be thread local!(?)
So the entire locking will not work as intended?


Rainer





Home | Main Index | Thread Index