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