Bug#753461: faketime stable breaks iceweasel 24.6
On Sun, 13 Jul 2014 20:21:00 -0400 Daniel Kahn Gillmor d...@fifthhorseman.net wrote: control: -1 unreproducible On 07/02/2014 01:19 AM, Charles Evans wrote: on a 4core Athlon2: faketime -m -f -1s iceweasel iceweasel uses 200% CPU forever, but generally works. faketime -m -f -10s iceweasel iceweasel uses 300% CPU forever, but generally works. faketime -m -f +10s iceweasel iceweasel takes about 10s to react, not useable. I see marginally slower behavior (and more CPU) when i run faketime -m yesterday iceweasel, but i don't see the unusable behavior you're describing. I've tried it on powerpc and i386 machines. Can you help me reproduce it somehow? snip (I answered this many days ago, but it seems to have vanished. possibly not the only email I sent to do so.) The problem is with offset timing: faketime -m -f -1s iceweasel sets the clock to appear to run 1s behind. the -f +1s and -f -1s cause problems. BTW I updated to the backport Version: 0.9.6-1~bpo70+1 and it still has many of the same problems: -1s pegs 2 cores at 100% forever. +1s makes large menus that scroll do so extremely slowly. -- Charles Evans charlesev...@chartertn.net -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#753461: faketime stable breaks iceweasel 24.6
Charles, it's hard to comment this profoundly without giving it some serious and time-consuming debugging first. Anyway, I assume that your problem persists with both offsets and start-at dates even when LD_PRELOADing libfaketime directly, i.e., without the faketime wrapper. In this case, the observed behavior is quite typical for applications which load system libraries (including time-related functions) themselves at run-time. It basically means that the LD_PRELOAD mechanism is somewhat bypassed by the application, which loads the real (not the faking) library again after the linker has loaded the faking library. Strange things (such as slow reactions with few-seconds-offsets or endless hangs with larger offsets) occur when the application is multi-threaded and one thread sees a faked time while another one uses the real system time, and both try to synchronize. If that's the case with iceweasel (idk for sure atm), there's nothing libfaketime can do because that's a limitation of the LD_PRELOAD mechanism. This is what makes faketime unusable with a few complex runtime environments, such as the Sun Java JDK/JRE, and there currently are no stable solutions known except for making the application explicitly libfaketime-aware. That said, unless we figure out that this is a libfaketime-internal bug and not a LD_PRELOAD limitation, there's little hope that it can be changed anytime soon. I'd actually be very happy about any suggestions on what to change about libfaketime to make it work with such applications. Charles Evans mailto:charlesev...@chartertn.net 5. August 2014 19:08 On Sun, 13 Jul 2014 20:21:00 -0400 snip (I answered this many days ago, but it seems to have vanished. possibly not the only email I sent to do so.) The problem is with offset timing: faketime -m -f -1s iceweasel sets the clock to appear to run 1s behind. the -f +1s and -f -1s cause problems. BTW I updated to the backport Version: 0.9.6-1~bpo70+1 and it still has many of the same problems: -1s pegs 2 cores at 100% forever. +1s makes large menus that scroll do so extremely slowly.
Bug#753461: faketime stable breaks iceweasel 24.6
control: -1 unreproducible On 07/02/2014 01:19 AM, Charles Evans wrote: on a 4core Athlon2: faketime -m -f -1s iceweasel iceweasel uses 200% CPU forever, but generally works. faketime -m -f -10s iceweasel iceweasel uses 300% CPU forever, but generally works. faketime -m -f +10s iceweasel iceweasel takes about 10s to react, not useable. I see marginally slower behavior (and more CPU) when i run faketime -m yesterday iceweasel, but i don't see the unusable behavior you're describing. I've tried it on powerpc and i386 machines. Can you help me reproduce it somehow? newer version segfaults on stable here. this is a separate bug, let's track it at https:/bugs.debian.org/753460 --dkg signature.asc Description: OpenPGP digital signature
Bug#753461: faketime stable breaks iceweasel 24.6
Package: faketime Version: 0.8-1 Severity: normal on a 4core Athlon2: faketime -m -f -1s iceweasel iceweasel uses 200% CPU forever, but generally works. faketime -m -f -10s iceweasel iceweasel uses 300% CPU forever, but generally works. faketime -m -f +10s iceweasel iceweasel takes about 10s to react, not useable. newer version segfaults on stable here. -- System Information: Debian Release: wheezy/sid APT prefers stable APT policy: (990, 'stable'), (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), (500, 'oldstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.4.4 (SMP w/4 CPU cores; PREEMPT) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C) Shell: /bin/sh linked to /UNIONFS/bin/bash Versions of packages faketime depends on: ii libc6 2.13-33 faketime recommends no packages. faketime suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
