From: Russell E. O. <ro...@uw...> - 2013-10-02 00:15:37
|
I distribute a Mac application using matplotlib. Recent versions that use matplotlib 1.3.0 fail to run on some new accounts. The symptoms are that the application never finishes loading and a task named "fc-list" takes up 100% of a core -- for as long as we've let it run (a good fraction of an hour). The only solution we've found is to copy ~/.matplotlib from an account where it works to the new account. It is reproducible on some machines, but unfortunately not mine. When I create a new account on my machine I do not see the problem. Thus I have not yet been able to come up with a minimal case that shows the problem. I'll try to get more info. Is this is a known issue? -- Russell |
From: Michael D. <md...@st...> - 2013-10-02 12:35:58
|
I haven't heard of this issue before. fc-list comes from the fontconfig project. It is used to get a list of all of the fonts installed on the system. It sounds like there is some bug there -- the usual culprit is that there is a slightly non-standard font installed on the system and fontconfig has a hard time parsing it. You could try updating fc-list (it's in all the major package managers). As for a workaround from our end, we could try to set a timeout on fc-list and just skip it if it takes too long. We can't rely on it being there on a Mac at all, so already we gracefully degrade to a less thorough search for fonts when fc-list can't be found. Mike On 10/01/2013 08:15 PM, Russell E. Owen wrote: > I distribute a Mac application using matplotlib. > > Recent versions that use matplotlib 1.3.0 fail to run on some new > accounts. The symptoms are that the application never finishes loading > and a task named "fc-list" takes up 100% of a core -- for as long as > we've let it run (a good fraction of an hour). > > The only solution we've found is to copy ~/.matplotlib from an account > where it works to the new account. > > It is reproducible on some machines, but unfortunately not mine. When I > create a new account on my machine I do not see the problem. Thus I have > not yet been able to come up with a minimal case that shows the problem. > I'll try to get more info. > > Is this is a known issue? > > -- Russell > > > ------------------------------------------------------------------------------ > October Webinars: Code for Performance > Free Intel webinars can help you accelerate application performance. > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from > the latest Intel processors and coprocessors. See abstracts and register > > http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel -- _ |\/|o _|_ _. _ | | \.__ __|__|_|_ _ _ ._ _ | ||(_| |(_|(/_| |_/|(_)(/_|_ |_|_)(_)(_)| | | http://www.droettboom.com |
From: Russell E. O. <ro...@uw...> - 2013-10-02 17:34:22
|
In article <524...@st...>, Michael Droettboom <md...@st...> wrote: > I haven't heard of this issue before. > > fc-list comes from the fontconfig project. It is used to get a list of > all of the fonts installed on the system. It sounds like there is some > bug there -- the usual culprit is that there is a slightly non-standard > font installed on the system and fontconfig has a hard time parsing it. > You could try updating fc-list (it's in all the major package managers). > > As for a workaround from our end, we could try to set a timeout on > fc-list and just skip it if it takes too long. We can't rely on it > being there on a Mac at all, so already we gracefully degrade to a less > thorough search for fonts when fc-list can't be found. Thanks for the advice. A defective font is an interesting possibility. I was wrong it's new in 1.3.0; turns out it's seen in much older versions of my application (back to using mpl 1.0.0), but apparently on few machines. The issue showed up when I added some fancy animated strip charts to my application (which may be a coincidence), not when I upgraded mpl. I'm surprised the timeout on fc-list isn't working. Maybe something else is also using fc-list, but the fix is to add an ~/.matplotlib dir, which suggests it's an mpl issue. -- Russell |
From: Michael D. <md...@st...> - 2013-10-02 17:56:01
|
On 10/02/2013 01:34 PM, Russell E. Owen wrote: > In article <524...@st...>, > Michael Droettboom <md...@st...> > wrote: > >> I haven't heard of this issue before. >> >> fc-list comes from the fontconfig project. It is used to get a list of >> all of the fonts installed on the system. It sounds like there is some >> bug there -- the usual culprit is that there is a slightly non-standard >> font installed on the system and fontconfig has a hard time parsing it. >> You could try updating fc-list (it's in all the major package managers). >> >> As for a workaround from our end, we could try to set a timeout on >> fc-list and just skip it if it takes too long. We can't rely on it >> being there on a Mac at all, so already we gracefully degrade to a less >> thorough search for fonts when fc-list can't be found. > Thanks for the advice. A defective font is an interesting possibility. > > I was wrong it's new in 1.3.0; turns out it's seen in much older > versions of my application (back to using mpl 1.0.0), but apparently on > few machines. > > The issue showed up when I added some fancy animated strip charts to my > application (which may be a coincidence), not when I upgraded mpl. > > I'm surprised the timeout on fc-list isn't working. We don't currently do a timeout -- we make a blocking call to fc-list. I was only suggesting it as a possible fix for this problem. > Maybe something else > is also using fc-list, but the fix is to add an ~/.matplotlib dir, which > suggests it's an mpl issue. When you copy over the .matplotlib dir, you copy over the font cache. When matplotlib finds a font cache, it doesn't need to generate a list of fonts, so thus doesn't need to call fc-list. But copying font caches from one machine to another is unlikely to work (the set of fonts and their locations is quite likely different). Worse yet, if matplotlib attempts to look up a font and finds that it isn't where the cache says it is, it regenerates the cache again, and thus you could get this hanging anyway. Mike > > -- Russell > > > ------------------------------------------------------------------------------ > October Webinars: Code for Performance > Free Intel webinars can help you accelerate application performance. > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from > the latest Intel processors and coprocessors. See abstracts and register > > http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel -- _ |\/|o _|_ _. _ | | \.__ __|__|_|_ _ _ ._ _ | ||(_| |(_|(/_| |_/|(_)(/_|_ |_|_)(_)(_)| | | http://www.droettboom.com |
From: Russell E. O. <ro...@uw...> - 2013-10-04 20:31:00
|
In article <524...@st...>, Michael Droettboom <md...@st...> wrote: > On 10/02/2013 01:34 PM, Russell E. Owen wrote: > > In article <524...@st...>, > > Michael Droettboom <md...@st...> > > wrote: > > > >> I haven't heard of this issue before. > >> > >> fc-list comes from the fontconfig project. It is used to get a list of > >> all of the fonts installed on the system. It sounds like there is some > >> bug there -- the usual culprit is that there is a slightly non-standard > >> font installed on the system and fontconfig has a hard time parsing it. > >> You could try updating fc-list (it's in all the major package managers). > >> > >> As for a workaround from our end, we could try to set a timeout on > >> fc-list and just skip it if it takes too long. We can't rely on it > >> being there on a Mac at all, so already we gracefully degrade to a less > >> thorough search for fonts when fc-list can't be found. > > Thanks for the advice. A defective font is an interesting possibility. > > > > I was wrong it's new in 1.3.0; turns out it's seen in much older > > versions of my application (back to using mpl 1.0.0), but apparently on > > few machines. > > > > The issue showed up when I added some fancy animated strip charts to my > > application (which may be a coincidence), not when I upgraded mpl. > > > > I'm surprised the timeout on fc-list isn't working. > > We don't currently do a timeout -- we make a blocking call to fc-list. > I was only suggesting it as a possible fix for this problem. Sorry. I read too hastily. If it's not too hard to code a time limit, it sounds like a good idea. > > Maybe something else > > is also using fc-list, but the fix is to add an ~/.matplotlib dir, which > > suggests it's an mpl issue. > > When you copy over the .matplotlib dir, you copy over the font cache. > When matplotlib finds a font cache, it doesn't need to generate a list > of fonts, so thus doesn't need to call fc-list. But copying font caches > from one machine to another is unlikely to work (the set of fonts and > their locations is quite likely different). Worse yet, if matplotlib > attempts to look up a font and finds that it isn't where the cache says > it is, it regenerates the cache again, and thus you could get this > hanging anyway. Thank you for that warning. As a followup: one of the two computers had 3 copies of fc-list (one from darwinports, one in /usr/local/bin and the on provided with Apple's X11). Making sure Apple's version ran seems to have cleared up the problem, based on one test. So we may have a fix. I really appreciate the help. -- Russell |