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

[Rainer Zocholl <UseNet-Posting-Nospam-74308-@zocki.toppoint.de>]

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.

Yes.

If VDR would assume that this tls version lib is used, 
*VDR must check that*!!!
too vdr already uses "locatime_r"..
so i assume:
TLS is not expected/required by VDR.

But of course it would be a more elegant solution to use the
tls-lib but what's with portability?
(debian seesm not to known tls except as transport layer security)
But it is then absolutely mandantory that VDR must check 
the use of the right lib!


>However, that doesn't explain why *I* was not seeing it, since I'm
>running vdr with LD_ASSUME_KERNEL=2.4.1:

I tried both running with and with out:
Both showed the same segfaults...


>[vdr@vdr vdr]$ ldd vdr
>         linux-gate.so.1 =>  (0xffffe000)
>         libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x4002c000)
>         libpthread.so.0 => /lib/tls/libpthread.so.0 (0x4004b000)
>         libdl.so.2 => /lib/libdl.so.2 (0x4005c000)
>         libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x4005f000)
>         libm.so.6 => /lib/tls/libm.so.6 (0x4011f000)
>         libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x40142000)
>         libc.so.6 => /lib/tls/libc.so.6 (0x4014b000)
>                           ^^^ thread local storage version
>         /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
>[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)


Hm, that does not fit, as Klaus recommends LD_ASSUME_KERNEL=2.4.1
because VDR is not working very good multithreaded...


msi:~/video/VDR#  ldd vdr
        libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x4001f000)
        libpthread.so.0 => /lib/libpthread.so.0 (0x4003f000)
        libdl.so.2 => /lib/libdl.so.2 (0x4008e000)
        libstdc++-libc6.2-2.so.3 => /usr/lib/libstdc++-libc6.2-2.so.3 (0x40091000)
        libm.so.6 => /lib/libm.so.6 (0x400da000)
        libc.so.6 => /lib/libc.so.6 (0x400fb000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
msi:~/video/VDR#  LD_ASSUME_KERNEL=2.4.1 ldd vdr
        libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x4001f000)
        libpthread.so.0 => /lib/libpthread.so.0 (0x4003f000)
        libdl.so.2 => /lib/libdl.so.2 (0x4008e000)
        libstdc++-libc6.2-2.so.3 => /usr/lib/libstdc++-libc6.2-2.so.3 (0x40091000)
        libm.so.6 => /lib/libm.so.6 (0x400da000)
        libc.so.6 => /lib/libc.so.6 (0x400fb000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)


really interessting!
No difference.

That explains why i have no change with and without LD_ASSUME_KERNEL...


BTW:
Too i set the compiter flag "-pthread" to enable "reentrancy"
(not to mixup with linkers "-lpthtread")

CXX      ?= g++-3.4
CXXFLAGS ?= -g3 -O2 -pthread -Wall -Woverloaded-virtual

But that did not give any other binary.
(IIRC that cases in which the compiler generates special code
are very seldom and may not occure in g++)



Rainer