[vdr] Might the NPTL problem be related to the STILLPICTURE hack? (Was: Re: Cutting recordings hangs vdr 1.3.x)

[Javier Marcet <lists@marcet.info>]

* Stefan Huelswitt <s.huelswitt@gmx.de> [040211 00:10]:

> > vdr # gdb --pid=10478
> [...]
> > Detaching from program: /bin/su, process 10478
> Ok, this seems to be the su command from runvdr. Not usefull
> here.
> > vdr # gdb --pid=10480
> [...]
> > Reading symbols from /usr/src/vdr/PLUGINS/lib/libvdr-analogtv.so.1.3.4...done.
> > Loaded symbols for /usr/src/vdr/PLUGINS/lib/libvdr-analogtv.so.1.3.4
> Just to be sure: try without all plugins.
I'll do it next time.

> > (gdb) bt
> > #0  0xffffe410 in ?? ()
> > #1  0xbff7efe8 in ?? ()
> > #2  0x00000002 in ?? ()
> > #3  0x4bfc7a5b in siglongjmp () from /lib/libpthread.so.0
> This locks strange, as all line should resolve to a specific
> location like the last line. Either the stackframe is allready
> corrupted or gdb isn't able to interpret the data.
Take into account, that there is not a race, only a slowdown -to
terrible times, but a slowdown after all, not a crash-, althouh some
times the card crsahes (or vdr, I'm not sure, what I see is that vdr is
restarted and the card is reinitiated).

> Anyways, I think it would be more usefull to start gdb with
> "gdb vdr 10480" (if 10480 is the vdr pid). This way gdb is able
> to attach all the threads ("info threads"). Now you can select
> every thread ("thread x") and backtrace them seperately. This
> will give a complete view of the things.
All right, that sound more straighforward than running several gdbs.

> So far I cannot contribute anything usefull to solve the problem.
What I've been observing by vdr's behavior, is that it has something to
do with STILLPICTURE.
I say this because when I set a mark point, in principle there is no
problem, vdr slowdowns to no avail when I pess 7 or 9 to move to a mark
point, just when the STILLPICTURE has to be shown.
It gets shown eventually, but after a long delay.
Furthermore, if I do several presses of 7/9 to move among several mark
point, vdr ends crashing.
The more movements I try, the sooner it crashes.
Although, since those actions are being kept in a buffer -- remomber
vdr is in a terrible slowness at that moment, so its responses are
anything but in real time --, I'm not sure whether the crash is caused
by the same code which produces the lags in vdr's response time, or by
some abuse of that buffer.

P.S. Sorry for the delay in responding this time. I had some problems on
my system, including a stupid 'rm -fr' which affected my /usr tree and
while trying to fix the oddity, I also lost my /etc, -- shudder! :(.

I had to rebuild all my system from scratch.
Thankfully, I could recover some of my /etc files by carefully scanning
an image of the partition affected which I took before erasing everything
prior to the new install... everything else had to be redone.

I'm mostly done by now, though, ready to fix the annoyance users get on
NPTL enabled systems. I am sure than just chaging the glibc with nptl
with one without it, cures the problem. But I don't like the solution.


--
Javier Marcet <javier@marcet.info>


--
Info:
To unsubscribe send a mail to ecartis@linuxtv.org with "unsubscribe vdr" as subject.