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.
control: -1 unreproducible 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? this is a separate bug, let's track it at https:/bugs.debian.org/753460
On Sun, 13 Jul 2014 20:21:00 -0400 Daniel Kahn Gillmor <dkg@fifthhorseman.net> wrote: <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, 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.
Control: retitle 753461 faketime causes some complex runtime environments (including firefox) to hang Control: tags 753461 - unreproducible Control: tags 753461 + upstream Control: forwarded 753461 https://github.com/wolfcw/libfaketime/issues/373 I've just replicated the reporeted behavior with firefox 96.0.3-1 on debian testing, using a simple testing profile in safe mode: faketime 2022-01-01 firefox -P test -no-remote -safe-mode this hangs indefinitely, presumably due to some of the concerns that Wolfgang outlines above. I don't think this is something that we can fix in debian, but i've noted it in the upstream bugtracker.