> gees... wtf is an anon_inode... first time i've seen that... and my quick > investigation shows that that is the epoll fd itself... so - something is > closing the epoll fd. only 3 ways that happens. > 1. _ecore_get_epoll_fd() detects that current epoll fd and the pid it > was create in dont match - so a child is running the same ecore loop, or
Adding an "ERR" message inside _ecore_get_epoll_fd, I do not see the msg when the BAD-FD problem appears. > 2. if epoll_ctl() reports EBADF errno - then ecore closes and re-creates > the epoll fd, or I put an ERR message after each epoll_ctl in ecore_main.c, checking the output of epoll_ctl for EBADF, but again the message does not appear when the problem comes. > 3. if ecore_shutdown actually shuts ecore down. given what you mention > about the bads_rem... Again adding a message to the code, ecore_shutdown is not triggered shortly before or alongside with the flood of the BAD-FD messages. (although ecore_shutdown seem to be run shortly after logging in gdm - is that part of E17 initialization ?). Please note, that appart of the flood of the error messages, E17 seem to work normally (of course slowed down by the extensive disk usage and only until .xsession-errors fills the disk space). Restarting E17 (from E17 menu) sometimes stops the problem, but it most cases I have to restart gdm. > the question is what fd went bad? it's not the ecore poll one as that > seems legit. it's some other one. Well, but how can I find that out ? Is there a way to get filename or some unique-id from inside _ecore_main_select ? Thanks, Pavel >> Hi, thanks for the advices - logging the fd's, the problem happens exactly >> when this fd disappears: >> >> /proc/5721/fd/3 -> anon_inode:[eventpoll] >> >> No other changes in the fd list. The observation is based on two >> occurances only, since the problem was happening much less frequently in >> the last weeks. I was not able to google-out any related issue. Did the >> disappearing eventpoll anonymous inode give you some idea what could be >> happening ? The only straightforward "experiment" I have in mind is to try >> disable ANON_INODES in kernel (BTW: using latest stable 2.6.36.2), but I >> am affraid it will bring much more other problems. >> >> Pavel >> >> >> On Thu, 9 Dec 2010, Carsten Haitzler wrote: >> >>> On Fri, 26 Nov 2010 09:59:19 +0100 (CET) Pavel Reznicek >>> <[email protected]> said: >>> >>> look at /proc/PID/fd >>> (PID being the pid of e). see what fd's you have - or not >>> and how they change over time (ls -l will show you which fd's point where). >>> write a script to log them often (every second?) and see if the log at the >>> time the problem shows up shows you anything interesting (what fd went >>> away? what fd appeared? etc.) >>> >>> i don't see this problem at all. >>> >>>> Hello, >>>> >>>> I am regularly hitting a bug mentioned here: >>>> >>>> http://www.mail-archive.com/[email protected]/msg27014.html >>>> >>>> Using latest SVN revision 54923 compiled via easy_e17 script on debian >>>> squeeze. The problem usually happens after few hours or running e17 or >>>> when graphics used "extensively" (typically when playing film). However, >>>> there is no concrete recipe how to reproduce it. >>>> >>>> Would you either have an idea, what could be going wrong or give me some >>>> instruction, how to try to debug it ? >>>> >>>> Thanks, >>>> Pavel >>>> >>>> ------------------------------------------------------------------------------ >>>> Increase Visibility of Your 3D Game App & Earn a Chance To Win $500! >>>> Tap into the largest installed PC base & get more eyes on your game by >>>> optimizing for Intel(R) Graphics Technology. Get started today with the >>>> Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. >>>> http://p.sf.net/sfu/intelisp-dev2dev >>>> _______________________________________________ >>>> enlightenment-users mailing list >>>> [email protected] >>>> https://lists.sourceforge.net/lists/listinfo/enlightenment-users >>>> >>> >>> >>> -- >>> ------------- Codito, ergo sum - "I code, therefore I am" -------------- >>> The Rasterman (Carsten Haitzler) [email protected] >>> >>> >>> ------------------------------------------------------------------------------ >>> This SF Dev2Dev email is sponsored by: >>> >>> WikiLeaks The End of the Free Internet >>> http://p.sf.net/sfu/therealnews-com >>> _______________________________________________ >>> enlightenment-users mailing list >>> [email protected] >>> https://lists.sourceforge.net/lists/listinfo/enlightenment-users >>> >> >> ------------------------------------------------------------------------------ >> Lotusphere 2011 >> Register now for Lotusphere 2011 and learn how >> to connect the dots, take your collaborative environment >> to the next level, and enter the era of Social Business. >> http://p.sf.net/sfu/lotusphere-d2d >> _______________________________________________ >> enlightenment-users mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/enlightenment-users >> > > > -- > ------------- Codito, ergo sum - "I code, therefore I am" -------------- > The Rasterman (Carsten Haitzler) [email protected] > > ------------------------------------------------------------------------------ Gaining the trust of online customers is vital for the success of any company that requires sensitive data to be transmitted over the Web. Learn how to best implement a security strategy that keeps consumers' information secure and instills the confidence they need to proceed with transactions. http://p.sf.net/sfu/oracle-sfdevnl _______________________________________________ enlightenment-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-users
