On 21 Apr 2005 Stefan Huelswitt <s.huelswitt at gmx.de> wrote:
Markku Tavasti wrote:
With version 0.9.12 of the plugin I get the following (Intel Celeron 433Mhz, output via OSS, black background) :
- Only stable when playing streams over network.
- Always crashes (well VDR takes 99% of CPU time) when playing songs
from harddrive which are "new" (ie. no id3-tag got scanned). The next time the song gets played it works, besides this :
- Frequent crashes when changing songs from harddrive (again, VDR takes
99% of CPU time),
AFAIS, the plugin got some ugly race conditions concering threads.
This might be possible, but I don't know how to debug this as nothing of it happens on my machine (playing a lot song from harddisc, right now for 6 hours continiously).
My suggestion is that somebody with that problem, please wait until vdr hangs with 100% cpu and then hook gdb to this process to see which thread it is and where it hangs.
I'm sorry, but I'm currently rather busy with other stuff, so that I cannot spent time on this myself. I'm be back on this in a week or two...
Hi,
first, my apologies for my really late reply.
Back to the problem above: I did a backtrace with gdb, and it seems the plugin itself isn't the problem (my setup?), read() blocks infinitely trying to read the mp3-file. I don't know why and I'm asking for your help/comments.
Oh, here's the backtrace: (gdb) thread 2 [Switching to thread 2 (Thread -1320977488 (LWP 4039))]#0 0xb7f796a1 in __read_nocancel () from /lib/tls/libpthread.so.0 (gdb) bt #0 0xb7f796a1 in __read_nocancel () from /lib/tls/libpthread.so.0 #1 0xb76cc58c in cStream::Stream (this=0x93610c8, data=@0xb1427618, len=@0xb142761c, rest=0x93611d0 "") at stream.c:271 #2 0xb76d30e6 in cScanID3::DoScan (this=0x9361170) at decoder-mp3.c:39 #3 0xb76d1f6e in cMP3Decoder::Start (this=0x935f7a8) at decoder-mp3.c:159 #4 0xb76cae7d in cMP3Player::Action (this=0x9360580) at player-mp3.c:1798 #5 0x080ef2a2 in cThread::StartThread () #6 0xb7f74b63 in start_thread () from /lib/tls/libpthread.so.0 #7 0xb7e2918a in clone () from /lib/tls/libc.so.6 (gdb) *sigh*
Today I tried to set O_NONBLOCK to the open()-calls (the code does a "do{ r = read(...); }while(r!=-1 && r != EINTR);" at stream.c:271 so this works out-of-the-box), then again I tried a select() on the filedescriptor before stream.c:271. None of the mentioned worked.
I can comment out the call to doScan() in cMP3Player::Action to avoid scanning id3-tags. This makes the plugin work without id3-tags though (as one might expect...).
That's all I can think of for now, if you need more information, please let me know.
Martin Cap macap20001@compuserve.de wrote:
Today I tried to set O_NONBLOCK to the open()-calls (the code does a "do{ r = read(...); }while(r!=-1 && r != EINTR);" at stream.c:271
shouldn't it be: while(r!=-1 && errno != EINTR); ?
best regards ... clemens
Clemens Kirchgatterer clemens@1541.org wrote:
Martin Cap macap20001@compuserve.de wrote:
Today I tried to set O_NONBLOCK to the open()-calls (the code does a
"do{ r = read(...); }while(r!=-1 && r != EINTR);" at stream.c:271
shouldn't it be: while(r!=-1 && errno != EINTR); ?
when i think about it, i'd rather do { r = read(...); } while (r >= 0 || ((r < 0) && (errno == EINTR)));
b.t.w. doesn't that eat cpu like crazy when O_NONBLOCK is set?
clemens
On 24 Jul 2005 Martin Cap macap20001@compuserve.de wrote:
Today I tried to set O_NONBLOCK to the open()-calls (the code does a "do{ r = read(...); }while(r!=-1 && r != EINTR);" at stream.c:271 so
I'll come back to the details later (rather busy lately).
The code actually is:
do { r=read(fd,buffer+fill,MP3FILE_BUFSIZE-fill); } while(r==-1 && errno==EINTR);
The return code for a unsatisfied read request in non-blocking mode is EAGAIN.
But normaly the plugin uses mmap() to read the file (if you haven't disabled this by intent), so that the code part you mentioned isn't used at all.
Regards.
Clemens Kirchgatterer wrote:
Martin Cap macap20001@compuserve.de wrote:
Today I tried to set O_NONBLOCK to the open()-calls (the code does a "do{ r = read(...); }while(r!=-1 && r != EINTR);" at stream.c:271
shouldn't it be: while(r!=-1 && errno != EINTR); ?
You're right, that's the way it is written in the code, sorry.
Clemens Kirchgatterer wrote:
Martin Cap macap20001@compuserve.de wrote:
Today I tried to set O_NONBLOCK to the open()-calls (the code does a
"do{ r = read(...); }while(r!=-1 && r != EINTR);" at stream.c:271
shouldn't it be: while(r!=-1 && errno != EINTR); ?
when i think about it, i'd rather do { r = read(...); } while (r >= 0 || ((r < 0) && (errno == EINTR)));
b.t.w. doesn't that eat cpu like crazy when O_NONBLOCK is set?
Sure it does. The strange things is, it also does without O_NONBLOCK set. The call to read() blocks infinitely and puts CPU-usage to 99%. I don't know the cause for this, as I'm the only one with this strange behavior in combiantion with the mp3-plugin.
Martin Cap wrote:
Clemens Kirchgatterer wrote:
Martin Cap macap20001@compuserve.de wrote:
Today I tried to set O_NONBLOCK to the open()-calls (the code does a
"do{ r = read(...); }while(r!=-1 && r != EINTR);" at stream.c:271
shouldn't it be: while(r!=-1 && errno != EINTR); ?
when i think about it, i'd rather do { r = read(...); } while (r >= 0 || ((r < 0) && (errno == EINTR)));
b.t.w. doesn't that eat cpu like crazy when O_NONBLOCK is set?
Sure it does.
How about putting in a sched_yield() or usleep() call then?
Carsten.
Stefan Huelswitt wrote:
On 24 Jul 2005 Martin Cap macap20001@compuserve.de wrote:
The code actually is:
do { r=read(fd,buffer+fill,MP3FILE_BUFSIZE-fill); } while(r==-1 && errno==EINTR);
The return code for a unsatisfied read request in non-blocking mode is EAGAIN.
Exactly.
But normaly the plugin uses mmap() to read the file (if you haven't disabled this by intent), so that the code part you mentioned isn't used at all.
Hu ! I haven't changed anything the first time I compiled and ran the plugin and it did not work then. How could this happen ? I will have to check this first. Thanks for your help so far and I'll get back to this later this evening.
Carsten Koch wrote:
when i think about it, i'd rather do { r = read(...); } while (r >= 0 || ((r < 0) && (errno == EINTR)));
b.t.w. doesn't that eat cpu like crazy when O_NONBLOCK is set?
Sure it does.
How about putting in a sched_yield() or usleep() call then?
Good idea, thanks. First I'll try what Stefan suggested (ie. is mmap disabled?).
Martin Cap wrote:
Stefan Huelswitt wrote:
But normaly the plugin uses mmap() to read the file (if you haven't disabled this by intent), so that the code part you mentioned isn't used at all.
Hu ! I haven't changed anything the first time I compiled and ran the plugin and it did not work then. How could this happen ? I will have to check this first. Thanks for your help so far and I'll get back to this later this evening.
Hu, Hu ! I reinstalled the plugin from sources and still don't have no such luck. I played with the code as I said in my initial mail, which made the backtrace wrong, here's the correct one. Sorry for the extra confusion !
#0 0xb7f446a1 in __read_nocancel () from /lib/tls/libpthread.so.0 #1 0xb7692e32 in cStream::Stream (this=0x92bab70, data=@0xb1385618, len=@0xb138561c, rest=0x7ff9 <Address 0x7ff9 out of bounds>) at stream.c:256 #2 0xb7699b66 in cScanID3::DoScan (this=0x92bac18) at decoder-mp3.c:38 #3 0xb76989ee in cMP3Decoder::Start (this=0x92baad0) at decoder-mp3.c:155 #4 0xb769165d in cMP3Player::Action (this=0x92829a0) at player-mp3.c:1798 #5 0x080ef2a2 in cThread::StartThread () #6 0xb7f3fb63 in start_thread () from /lib/tls/libpthread.so.0 #7 0xb7df418a in clone () from /lib/tls/libc.so.6
So the dead-lock happens at line 256. Strange, obviously. (I can output what r + errno give me when returning from read() and post it here.)
I demand that Clemens Kirchgatterer may or may not have written...
Martin Cap macap20001@compuserve.de wrote:
Today I tried to set O_NONBLOCK to the open()-calls (the code does a "do{ r = read(...); }while(r!=-1 && r != EINTR);" at stream.c:271
shouldn't it be: while(r!=-1 && errno != EINTR); ?
That looks wrong too.
while (r != -1 || errno == EINTR);
On 25 Jul 2005 Martin Cap macap20001@compuserve.de wrote:
#0 0xb7f446a1 in __read_nocancel () from /lib/tls/libpthread.so.0 #1 0xb7692e32 in cStream::Stream (this=0x92bab70, data=@0xb1385618, len=@0xb138561c, rest=0x7ff9 <Address 0x7ff9 out of bounds>) at stream.c:256 #2 0xb7699b66 in cScanID3::DoScan (this=0x92bac18) at decoder-mp3.c:38 #3 0xb76989ee in cMP3Decoder::Start (this=0x92baad0) at decoder-mp3.c:155 #4 0xb769165d in cMP3Player::Action (this=0x92829a0) at player-mp3.c:1798 #5 0x080ef2a2 in cThread::StartThread () #6 0xb7f3fb63 in start_thread () from /lib/tls/libpthread.so.0 #7 0xb7df418a in clone () from /lib/tls/libc.so.6
So the dead-lock happens at line 256. Strange, obviously. (I can output what r + errno give me when returning from read() and post it here.)
Without loocking at the details, I still cannot understand why this code part is reached.
For me there are only 3 ways for this: 1.) You have disabled USE_MMAP at the beginning of stream.c 2.) The file is bigger than MAX_MMAP_SIZE (currently 32mb) 3.) mmap() failed for some reason (should give syslog entry if run in debug loglevel)
Regards.
Stefan Huelswitt wrote:
Without loocking at the details, I still cannot understand why this code part is reached.
For me there are only 3 ways for this: 1.) You have disabled USE_MMAP at the beginning of stream.c 2.) The file is bigger than MAX_MMAP_SIZE (currently 32mb) 3.) mmap() failed for some reason (should give syslog entry if run in debug loglevel)
Hi,
when running the plugin (actually vdr) in debug-mode, I get the following messages on the console (the plugin-thread again locks the computer with 99% CPU-usage):
"mgr: background scan thread started (pid=3868) mgr: scanning (id3) somemp3-file.mp3 mad: id3-scan, lost sync 4952594c 45425343 SOME_COMMENTS_TAG mad: id3-scan, lost sync 00000000 07000000 mgr: waiting for bgr release ... (pass2=0 nono=(nil) scan=0x8299b30)"
Maybe this helps a little ?!
On 31 Jul 2005 Martin Cap macap20001@compuserve.de wrote:
Stefan Huelswitt wrote:
Without loocking at the details, I still cannot understand why this code part is reached.
For me there are only 3 ways for this: 1.) You have disabled USE_MMAP at the beginning of stream.c 2.) The file is bigger than MAX_MMAP_SIZE (currently 32mb) 3.) mmap() failed for some reason (should give syslog entry if run in debug loglevel)
when running the plugin (actually vdr) in debug-mode, I get the following messages on the console (the plugin-thread again locks the computer with 99% CPU-usage):
"mgr: background scan thread started (pid=3868) mgr: scanning (id3) somemp3-file.mp3 mad: id3-scan, lost sync 4952594c 45425343 SOME_COMMENTS_TAG mad: id3-scan, lost sync 00000000 07000000 mgr: waiting for bgr release ... (pass2=0 nono=(nil) scan=0x8299b30)"
Maybe this helps a little ?!
Actualy, not :(
What happens was already known (atleast to me). The plugin gets stuck inside the read() call (see your backtrave earlier). In this case this is the background scan thread. Later on the foreground manager thread (mgr) wait for some reaction of the background thread, which never happens -> deadlock.
For me there is still the question, why the plugin reaches the offending code part (read) as this shouldn't happen if mmap() works. Try to find out that (see my points above), e.g. add some debug output to cStream::Open() and Stream().
Regards.
-
Carsten Koch -
Clemens Kirchgatterer -
Darren Salt -
Martin Cap -
s.huelswitt＠gmx.de