Thread: [Mplayerplug-in-devel] came across a crash
Brought to you by:
kdekorte
From: Greg H. <mp...@am...> - 2005-07-12 06:03:45
Attachments:
crash.txt
|
I am using CVS copy of mplayerplug-in from Fri or Sat. I enabled debug and the very tail end of my log is attached. of interest is the fact that Actual Size and Play Size are both 0x0. i.e. this is an initialized, but unused playlist node. As an aside, I note that nsPluginInstance::shut() is calling deleteNode without first obtaining the mutex lock (granted, at this point in time, the player thread is "supposed to be dead" ...) I'm not sure, yet, how the uninitialized node came to be on the node list. I hit a url that referenced a avi file, and just as mplayer was loading, and before mplayer started, I reloaded the browser page (thereby canceling the mplayer). I *think* I saw mplayer saying something about "generating playlist" or "waiting for playlist". can't really remember, it all happen quite quickly. +---------------------------------------------------------------------+ Please also check the log file at "/dev/null" for additional information. (from /var/log/Xorg.setup.log) | Greg Hosler gr...@ho... | +---------------------------------------------------------------------+ |
From: Kevin D. <kde...@ya...> - 2005-07-12 13:23:02
|
On Tuesday 12 July 2005 12:04 am, Greg Hosler wrote: > I am using CVS copy of mplayerplug-in from Fri or Sat. > > I enabled debug and the very tail end of my log is attached. > > of interest is the fact that Actual Size and Play Size are both 0x0. > > i.e. this is an initialized, but unused playlist node. > > As an aside, I note that nsPluginInstance::shut() is calling deleteNode > without first obtaining the mutex lock (granted, at this point in time, t= he > player thread is "supposed to be dead" ...) > > I'm not sure, yet, how the uninitialized node came to be on the node list. > > I hit a url that referenced a avi file, and just as mplayer was loading, > and before mplayer started, I reloaded the browser page (thereby canceling > the mplayer). I *think* I saw mplayer saying something about "generating > playlist" or "waiting for playlist". can't really remember, it all happen > quite quickly. > Greg, I assume you are the one posting in the forum about this problem as well.=20 Is there an HTML page you click the link on or are you just selecting a URL= ?=20 If you clicking on a link, can you send me the source to that page.=20 Also, can you send me you mplayerplug-in.conf file I have added the lock around deleteList in shut, but it should not make muc= h=20 of a difference at the point.=20 I have a Fedora Core 3 machine and an Ubuntu 5.04 machine here at my locati= on=20 and I cannot make current CVS crash when switching between a movie and a we= b=20 page and so I can't crash it.=20 So can you tell me what Distro you are running and perhaps what version of= =20 glibc? Thanks, Kevin |
From: Greg H. <mp...@am...> - 2005-07-12 14:27:38
|
On 12-Jul-2005 Kevin DeKorte wrote: > On Tuesday 12 July 2005 12:04 am, Greg Hosler wrote: >> I am using CVS copy of mplayerplug-in from Fri or Sat. >> >> I enabled debug and the very tail end of my log is attached. >> >> of interest is the fact that Actual Size and Play Size are both 0x0. >> >> i.e. this is an initialized, but unused playlist node. >> >> As an aside, I note that nsPluginInstance::shut() is calling deleteNode >> without first obtaining the mutex lock (granted, at this point in time, the >> player thread is "supposed to be dead" ...) >> >> I'm not sure, yet, how the uninitialized node came to be on the node list. >> >> I hit a url that referenced a avi file, and just as mplayer was loading, >> and before mplayer started, I reloaded the browser page (thereby canceling >> the mplayer). I *think* I saw mplayer saying something about "generating >> playlist" or "waiting for playlist". can't really remember, it all happen >> quite quickly. >> > > Greg, > > I assume you are the one posting in the forum about this problem as well. actually, not. The person in the forum is a collegue of mine, however, we're both trying to locate the source of the crashes that we're both expeciancing. > Is there an HTML page you click the link on or are you just selecting a URL? > If you clicking on a link, can you send me the source to that page. The application is an internal one, so I can't point you at a web page, but I do not believe that that makes a difference. This is *so* easy to reproduce... I am attaching the web page source code, but the web page is java script generated, so I do not think that that will be of much value. I JUST tried reproducing the problem (successfully, log file attached), as follow. point the browser at an avi file. as the file is loading to play, click in the url bar and hit return (as opposed to hitting the reload button, which ALSO will crash the plugin/browser in the EXACTLY same fashion, by the way - just tried, and verified!) > Also, can you send me you mplayerplug-in.conf file attached. > I have added the lock around deleteList in shut, but it should not make much > of a difference at the point. I will re-pull CVS, and try with th elatest in another short while. definately a bit later today. > I have a Fedora Core 3 machine and an Ubuntu 5.04 machine here at my location > and I cannot make current CVS crash when switching between a movie and a web > page and so I can't crash it. > > So can you tell me what Distro you are running and perhaps what version of > glibc? a pretty stock fedora core 3, all up2dated. glibc = # rpm -q glibc glibc-2.3.5-0.fc3.1 > Thanks, best rgds, -Greg > > Kevin +---------------------------------------------------------------------+ Please also check the log file at "/dev/null" for additional information. (from /var/log/Xorg.setup.log) | Greg Hosler gr...@ho... | +---------------------------------------------------------------------+ |
From: Kevin D. <kde...@ya...> - 2005-07-12 21:29:02
|
On Tuesday 12 July 2005 08:28 am, Greg Hosler wrote: > On 12-Jul-2005 Kevin DeKorte wrote: > > On Tuesday 12 July 2005 12:04 am, Greg Hosler wrote: > >> I am using CVS copy of mplayerplug-in from Fri or Sat. > >> > >> I enabled debug and the very tail end of my log is attached. > >> > >> of interest is the fact that Actual Size and Play Size are both 0x0. > >> > >> i.e. this is an initialized, but unused playlist node. > >> > >> As an aside, I note that nsPluginInstance::shut() is calling deleteNode > >> without first obtaining the mutex lock (granted, at this point in time, > >> the player thread is "supposed to be dead" ...) > >> > >> I'm not sure, yet, how the uninitialized node came to be on the node > >> list. > >> > >> I hit a url that referenced a avi file, and just as mplayer was loadin= g, > >> and before mplayer started, I reloaded the browser page (thereby > >> canceling the mplayer). I *think* I saw mplayer saying something about > >> "generating playlist" or "waiting for playlist". can't really remember, > >> it all happen quite quickly. > > > > Greg, Greg, Can you make it crash if you set nomediacache=3D0 in the config file? set cachemin=3D1024 cache-percent=3D10 It should stop caching and start playing when it reaches 2048K downloaded i= f=20 the file is larger than 10MB, but it will download the entire media to your= =20 machine.=20 Also, the html you sent didn't have the embed tag in it. I was hoping to se= e=20 if there was anything odd in there.=20 It also looks the the mplayer you are using is NLS enabled. Is it possible = to=20 build one that is not NLS enabled and see if that changes anything? Also, I have ran mplayerplug-in via valgrind and did some other debugging a= nd=20 I still have been unable to duplicate the crash you are having. As a note=20 =46irefox 1.0.4 is a mess when run under valgrind. Memory leaking everywher= e. Kevin |
From: Greg H. <mp...@am...> - 2005-07-12 22:41:13
|
On 12-Jul-2005 Kevin DeKorte wrote: > On Tuesday 12 July 2005 08:28 am, Greg Hosler wrote: >> On 12-Jul-2005 Kevin DeKorte wrote: >> > On Tuesday 12 July 2005 12:04 am, Greg Hosler wrote: >> >> I am using CVS copy of mplayerplug-in from Fri or Sat. >> >> >> >> I enabled debug and the very tail end of my log is attached. >> >> >> >> of interest is the fact that Actual Size and Play Size are both 0x0. >> >> >> >> i.e. this is an initialized, but unused playlist node. >> >> >> >> As an aside, I note that nsPluginInstance::shut() is calling deleteNode >> >> without first obtaining the mutex lock (granted, at this point in time, >> >> the player thread is "supposed to be dead" ...) >> >> >> >> I'm not sure, yet, how the uninitialized node came to be on the node >> >> list. >> >> >> >> I hit a url that referenced a avi file, and just as mplayer was loading, >> >> and before mplayer started, I reloaded the browser page (thereby >> >> canceling the mplayer). I *think* I saw mplayer saying something about >> >> "generating playlist" or "waiting for playlist". can't really remember, >> >> it all happen quite quickly. >> > >> > Greg, > > Greg, > > Can you make it crash if you set nomediacache=0 in the config file? yup! > set > > cachemin=1024 > cache-percent=10 done. still crashes! > It should stop caching and start playing when it reaches 2048K downloaded if > the file is larger than 10MB, but it will download the entire media to your > machine. The download is unacceptable for our application, unfortunately. Having said that... well, I don't wait for mplayer to actually play the avi. As soon as the page loads, and ESPECIALLY before the player starts, I'll reload the page. The combination of killing off the old mplayer, and near simultaneously loading and starting up a new one seems to be an excellent combination in killing the plugin. I can usually get the plugin to crash w/out a restart simultaneous to the kill off of the old one, so long as the new mplayer hasn't started, yet. I get about a 40% kill rate! > Also, the html you sent didn't have the embed tag in it. I was hoping to see > if there was anything odd in there. to be honest, i do not think that it really matters, I can EASILY get the plugin to crash, using the above sequency (restarting, and killing off the restarted mplayer BEFORE the player actually starts playing). In actual fact, it is not even necessayr to "restart". I frequently get the crash on the very first attempt. i.e. I load the following in the browser url: /<path to avi file> and as soon as the page (as it were, i.e. mplayer) starts to load, HIT THE RELOAD BUTTON!!! This will generally crash the plugin, if not on the 1st or 2nd iteration, then usually within several more iterations. > It also looks the the mplayer you are using is NLS enabled. Is it possible to > build one that is not NLS enabled and see if that changes anything? hmm. I just checked, and I'm told that we do not need NLS. I'll regenerate a new mplayer image and retry. > Also, I have ran mplayerplug-in via valgrind and did some other debugging and > I still have been unable to duplicate the crash you are having. As a note > Firefox 1.0.4 is a mess when run under valgrind. Memory leaking everywhere. memory leaking (pure leaking, as opposed to reusing unfreed memory, or double frees) will NEVER cause a crash, with the possible exception of when you run out of memory, and a malloc returns a null pointer. However, since I can FORCE the crash within 30 seconds of the browser startup, and my machine has 1.5 gb of ram, I really do not suspect that this is related to my crashing problems. Moreover, if I use mozplugger INSTEAD of mplayer plug-in, and do exactly the above sequences, the browser will NEVER crash. Not even once out of 20 ro 30 attempts (which would see from 20 to 40 mplayerplug-in crashes in the same number of attempts...). However, we have the need of being able to control the player with javascript, which mplayer does provide, and mozplugin does not. > Kevin p.s. is there anyway that you can make a tarball of cvs available ? cvs on sourceforge is still not updated, and I really need to re-test against the latest, and then investigate any further problems I might find, asap... best rgds, -Greg Hosler +---------------------------------------------------------------------+ Please also check the log file at "/dev/null" for additional information. (from /var/log/Xorg.setup.log) | Greg Hosler gr...@ho... | +---------------------------------------------------------------------+ |
From: Kevin D. <kde...@ya...> - 2005-07-12 23:12:57
Attachments:
mplayerplug-in-2.99.0.tar.gz
|
On Tuesday 12 July 2005 04:41 pm, Greg Hosler wrote: > On 12-Jul-2005 Kevin DeKorte wrote: > > On Tuesday 12 July 2005 08:28 am, Greg Hosler wrote: > >> On 12-Jul-2005 Kevin DeKorte wrote: > >> > On Tuesday 12 July 2005 12:04 am, Greg Hosler wrote: > >> >> I am using CVS copy of mplayerplug-in from Fri or Sat. > >> >> > >> >> I enabled debug and the very tail end of my log is attached. > >> >> > >> >> of interest is the fact that Actual Size and Play Size are both 0x0. > >> >> > >> >> i.e. this is an initialized, but unused playlist node. > >> >> > >> >> As an aside, I note that nsPluginInstance::shut() is calling > >> >> deleteNode without first obtaining the mutex lock (granted, at this > >> >> point in time, the player thread is "supposed to be dead" ...) > >> >> > >> >> I'm not sure, yet, how the uninitialized node came to be on the node > >> >> list. > >> >> > >> >> I hit a url that referenced a avi file, and just as mplayer was > >> >> loading, and before mplayer started, I reloaded the browser page > >> >> (thereby canceling the mplayer). I *think* I saw mplayer saying > >> >> something about "generating playlist" or "waiting for playlist". > >> >> can't really remember, it all happen quite quickly. > >> > > >> > Greg, > > > > Greg, > > > > Can you make it crash if you set nomediacache=0 in the config file? > > yup! > > > set > > > > cachemin=1024 > > cache-percent=10 > > done. still crashes! > > > It should stop caching and start playing when it reaches 2048K downloaded > > if the file is larger than 10MB, but it will download the entire media to > > your machine. > > The download is unacceptable for our application, unfortunately. Having > said that... > > well, I don't wait for mplayer to actually play the avi. As soon as the > page loads, and ESPECIALLY before the player starts, I'll reload the page. > > The combination of killing off the old mplayer, and near simultaneously > loading and starting up a new one seems to be an excellent combination in > killing the plugin. I can usually get the plugin to crash w/out a restart > simultaneous to the kill off of the old one, so long as the new mplayer > hasn't started, yet. I get about a 40% kill rate! > > > Also, the html you sent didn't have the embed tag in it. I was hoping to > > see if there was anything odd in there. > > to be honest, i do not think that it really matters, I can EASILY get the > plugin to crash, using the above sequency (restarting, and killing off the > restarted mplayer BEFORE the player actually starts playing). In actual > fact, it is not even necessayr to "restart". I frequently get the crash on > the very first attempt. i.e. I load the following in the browser url: > > /<path to avi file> > > and as soon as the page (as it were, i.e. mplayer) starts to load, > > HIT THE RELOAD BUTTON!!! > > This will generally crash the plugin, if not on the 1st or 2nd iteration, > then usually within several more iterations. > > > It also looks the the mplayer you are using is NLS enabled. Is it > > possible to build one that is not NLS enabled and see if that changes > > anything? > > hmm. I just checked, and I'm told that we do not need NLS. I'll regenerate > a new mplayer image and retry. > > > Also, I have ran mplayerplug-in via valgrind and did some other debugging > > and I still have been unable to duplicate the crash you are having. As a > > note Firefox 1.0.4 is a mess when run under valgrind. Memory leaking > > everywhere. > > memory leaking (pure leaking, as opposed to reusing unfreed memory, or > double frees) will NEVER cause a crash, with the possible exception of when > you run out of memory, and a malloc returns a null pointer. However, since > I can FORCE the crash within 30 seconds of the browser startup, and my > machine has 1.5 gb of ram, I really do not suspect that this is related to > my crashing problems. > > Moreover, if I use mozplugger INSTEAD of mplayer plug-in, and do exactly > the above sequences, the browser will NEVER crash. Not even once out of 20 > ro 30 attempts (which would see from 20 to 40 mplayerplug-in crashes in the > same number of attempts...). However, we have the need of being able to > control the player with javascript, which mplayer does provide, and > mozplugin does not. > > > Kevin > > p.s. is there anyway that you can make a tarball of cvs available ? cvs on > sourceforge is still not updated, and I really need to re-test against the > latest, and then investigate any further problems I might find, asap... > > best rgds, > > -Greg Hosler > Greg, Here is the tar file... BTW, I can get it to crash, by pounding on the refresh key (takes about 4-5 presses)... When I do get it to crash I believe firefox is violating the plugin contract of giving me a unique instance of the plugin per instantiation. Kevin |
From: Greg H. <mp...@am...> - 2005-07-13 01:41:11
|
On 12-Jul-2005 Kevin DeKorte wrote: > Greg, > > Here is the tar file... > > BTW, I can get it to crash, by pounding on the refresh key (takes about 4-5 > presses)... yes. > When I do get it to crash I believe firefox is violating the plugin contract > of giving me a unique instance of the plugin per instantiation. I looked at a dump that Jason generated a few hrs ago. I saw 2 instances of callback via 'NewStream'. Apparently firefox thought that the 1st one was not active any more (clearly an error on it's part). Maybe is mPlugin is already set, you can ignore. not really sure what the proper action might be in that case. talk upstream, and see if this is fixed in a newer firefox. if yess, we'll have to upgrade the browser! best rgds, -Greg +---------------------------------------------------------------------+ Please also check the log file at "/dev/null" for additional information. (from /var/log/Xorg.setup.log) | Greg Hosler gr...@ho... | +---------------------------------------------------------------------+ |
From: Kevin D. <kde...@ya...> - 2005-07-13 03:40:45
|
On Tuesday 12 July 2005 07:42 pm, Greg Hosler wrote: > On 12-Jul-2005 Kevin DeKorte wrote: > > Greg, > > > > Here is the tar file... > > > > BTW, I can get it to crash, by pounding on the refresh key (takes about > > 4-5 presses)... > > yes. > > > When I do get it to crash I believe firefox is violating the plugin > > contract of giving me a unique instance of the plugin per instantiation. > > I looked at a dump that Jason generated a few hrs ago. I saw 2 instances = of > callback via 'NewStream'. Apparently firefox thought that the 1st one was > not active any more (clearly an error on it's part). Maybe is mPlugin is > already set, you can ignore. not really sure what the proper action might > be in that case. talk upstream, and see if this is fixed in a newer > firefox. if yess, we'll have to upgrade the browser! > > best rgds, > > -Greg > I tested it with a nightly build of DeerPark and it crashed there as well. = I=20 submitted a bug report via the crash handler. Kevin |
From: Greg H. <gr...@ho...> - 2005-07-13 04:24:06
|
On 12-Jul-2005 Kevin DeKorte wrote: > Greg, > > Here is the tar file... > > BTW, I can get it to crash, by pounding on the refresh key (takes about 4-5 > presses)... > > When I do get it to crash I believe firefox is violating the plugin contract > of giving me a unique instance of the plugin per instantiation. hmm... what might this mean in terms of a fix. is this fixed in newer firefox ? (I'm using 1.0.4 -- mozilla.org only has 1.0.5, so there probably isn't a lot of changes to it). -Greg +---------------------------------------------------------------------+ Please also check the log file at "/dev/null" for additional information. (from /var/log/Xorg.setup.log) | Greg Hosler gr...@ho... | +---------------------------------------------------------------------+ |
From: Kevin D. <kde...@ya...> - 2005-07-13 13:36:05
|
On Tuesday 12 July 2005 10:24 pm, Greg Hosler wrote: > On 12-Jul-2005 Kevin DeKorte wrote: > > Greg, > > > > Here is the tar file... > > > > BTW, I can get it to crash, by pounding on the refresh key (takes about > > 4-5 presses)... > > > > When I do get it to crash I believe firefox is violating the plugin > > contract of giving me a unique instance of the plugin per instantiation. > > hmm... > > what might this mean in terms of a fix. is this fixed in newer firefox ? > (I'm using 1.0.4 -- mozilla.org only has 1.0.5, so there probably isn't a > lot of changes to it). > > -Greg > Greg, I got to QUIT CRASHING....=20 VERY simple fix in plugin.cpp at line 341 add this line (outside the if block) pthread_cancel(player_thread); in plugin-threads.cpp at line 1261 add (above the STATE set) pthread_testcancel(); After I made these two changes I can't get the browser to crash... I have t= wo=20 machines I was able to duplicate the fix on... please let me know if it wor= ks=20 for you. Kevin |
From: Greg H. <mp...@am...> - 2005-07-13 22:58:38
|
On 13-Jul-2005 Kevin DeKorte wrote: > On Tuesday 12 July 2005 10:24 pm, Greg Hosler wrote: >> On 12-Jul-2005 Kevin DeKorte wrote: >> > Greg, >> > >> > Here is the tar file... >> > >> > BTW, I can get it to crash, by pounding on the refresh key (takes about >> > 4-5 presses)... >> > >> > When I do get it to crash I believe firefox is violating the plugin >> > contract of giving me a unique instance of the plugin per instantiation. >> >> hmm... >> >> what might this mean in terms of a fix. is this fixed in newer firefox ? >> (I'm using 1.0.4 -- mozilla.org only has 1.0.5, so there probably isn't a >> lot of changes to it). >> >> -Greg >> > > Greg, > > I got to QUIT CRASHING.... > > VERY simple fix > > in plugin.cpp at line 341 add this line (outside the if block) > > pthread_cancel(player_thread); > > > in plugin-threads.cpp at line 1261 add (above the STATE set) > > pthread_testcancel(); > > After I made these two changes I can't get the browser to crash... I have two > machines I was able to duplicate the fix on... please let me know if it works > for you. > > Kevin Hi, quick question. is this particular fix in the LATEST CVS ? Jason pulled the latest cvs, and it is very very sweet. neither he nor I can _force_ a crash (and believe me, we have tried... ;) one detail that we think has been overlooked in the divy up of the .so and the .xpi files. somehow, somewhere, support of .ogg got dropped. :( I'm looking thru the code. plugin-setup.cpp clearly still supports ogg, but for whetever reason, ogg is not getting registered to any of the 5 plugins. (i.e. go to about:plugins, and you'll see all the content types registered to the various plugins, but ogg is not there). on a side note, I've tried playing with use-mimetypes, and setting it to one, to force the use of the mplayerplug-in.conf file, and (removal of the respective pluginreg.dat files), and I just can't get this to work. This is probably good thing to fix long term, but short term, registering ogg to one of the plugins probably needs to be done. Not sure how to accomplish this. I'm guessing that one of the xpt files needs an update.) thx, and best rgds, -Greg +---------------------------------------------------------------------+ Please also check the log file at "/dev/null" for additional information. (from /var/log/Xorg.setup.log) | Greg Hosler gr...@ho... | +---------------------------------------------------------------------+ |
From: Kevin D. <kde...@ya...> - 2005-07-14 00:49:46
|
> quick question. > > is this particular fix in the LATEST CVS ? Jason pulled the latest cvs, a= nd > it is very very sweet. neither he nor I can _force_ a crash (and believe > me, we have tried... ;) > > one detail that we think has been overlooked in the divy up of the .so and > the .xpi files. somehow, somewhere, support of .ogg got dropped. > > :( > > I'm looking thru the code. plugin-setup.cpp clearly still supports ogg, b= ut > for whetever reason, ogg is not getting registered to any of the 5 plugin= s. > (i.e. go to about:plugins, and you'll see all the content types registered > to the various plugins, but ogg is not there). > > on a side note, I've tried playing with use-mimetypes, and setting it to > one, to force the use of the mplayerplug-in.conf file, and (removal of the > respective pluginreg.dat files), and I just can't get this to work. This = is > probably good thing to fix long term, but short term, registering ogg to > one of the plugins probably needs to be done. Not sure how to accomplish > this. I'm guessing that one of the xpt files needs an update.) > > thx, and best rgds, > > -Greg > Greg, I chatted with Jason about this and it looked like a mistake in the Makefil= e.=20 It was not building things properly.=20 I have committed a fix to CVS... HOWEVER, make sure you run=20 =2E/configure make clean Then=20 make make install That should build the .o files properly. I think it was possible to not do= =20 that before. Kevin |
From: Kevin D. <kde...@ya...> - 2005-07-14 00:52:07
|
On Wednesday 13 July 2005 04:59 pm, Greg Hosler wrote: > Not sure how to accomplish this. I'm > guessing that one of the xpt files needs an update. Greg, The XPT files are the files that tell Mozilla/Firefox about the javascript= =20 support. That is all they do. The plugin -> mimetype mapping is contained within the .so Kevin |