walt <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], excerpted below, on Wed, 06 Aug 2008 18:59:41 +0000:
> I must admit that David's gdb trace does look like a program that's at > least doing a good imitation of useful work, but there's no way to know > how fast pan is doing it. His trace does mention values being optimized > out, so I wonder if this problem has something to do with the compiler > flags used during compilation. Dunno, but gcc-64 might have issues > there that gcc-32 doesn't. FWIW, here's my CFLAGS, CXXFLAGS, and LDFLAGS: CFLAGS="-march=k8 -pipe -msse3 -O2 -frename-registers -fweb -fmerge-all- constants -fgcse-sm -fgcse-las -fgcse-after-reload -ftree-vectorize - fdirectives-only -freorder-blocks-and-partition -combine" CXXFLAGS="-march=k8 -pipe -msse3 -O2 -frename-registers -fweb -fmerge-all- constants -fgcse-sm -fgcse-las -fgcse-after-reload -ftree-vectorize - fdirectives-only" LDFLAGS="-Wl,-z,now,--as-needed,-O1,--hash-style=gnu,--sort-common" That's what my entire system is compiled with, except the packages where Gentoo has found one that doesn't work and replaced or downgraded strength as part of their ebuild scripts. (BTW, man gcc is quite informative on C(XX)FLAGS, and seems to be getting even more so with each gcc release. I've not found a similar doc for LDFLAGS, unfortunately, so have just picked them up as I found them.) I agree on the iffiness of the X thing, but I don't have a better explanation, unless perhaps it /is/ X but X updating is stalled waiting for pan to process a callback or some such, and pan's too busy to notice. One thing tho, it's sure using that fd, whether it's a regular file or a socket or whatever, for both input and output during this period. That's actually one of the reasons I think it's a socket, as I don't expect both input and output like that to a regular file is very common. Two things would be nice. 1) Timestamps on either/both the strace and the gdb, do either of them support that? Then we could see how long it's spending on the poll before returning, for instance. 2) Is there a way to query the system for the path of a fd from another process (with sufficient privs, of course, to prevent cross-user leaks)? It'd sure be nice to find out what that fd it's cycling on is, for sure. Of course, one could get it if they traced pan from startup, but that'd be a HUGE trace to worth thru by the time it hung. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman _______________________________________________ Pan-users mailing list Pan-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/pan-users
