Go to content Go to navigation Go to search

Up! Going faster for fun and profit · Jul 19, 09:21 AM

I found some bare bones instructions here for writing LD_PRELOAD wrappers. I used them to make a library that seems to speed up time for a program, and it’s really useful for testing.

I got frustrated with a test suite with 1000+ tests that would go through the same tests over and over again, waiting 5 seconds here and 30 seconds there. It got to the point where it could take a whole day to run the suite, which can really slow down development. The irony being that this suite, when watched with strace or pstack, was rarely actually doing work. It spent most of the time just waiting.

I first thought of modifying all the waits to make them shorter, scale them all down. But it was a large task and there was always the risk of testing something that is different to the shipped code, or worse… shipping with the short timeouts which would make the product behave very strangely! So the idea of a generic way of speeding up any waiting process was more appealing.

The trick doesn’t really make the computer any faster, it just makes it lie to the test process whenever something time related should happen. I only needed to wrap the APIs that our test process used and that was ‘time’, ‘gettimeofday’, ‘nanosleep’ and ‘select’. There are other system calls that use time related parameters but I left them alone. The first time one of those was called, my library takes note of the real time. Any further references to the system time return the start time plus a scaled version of the difference between the current time and the start time. So if our speedup factor is 10, and we start a speeded up process at 9AM, after one second passes in real time the process can ask for the time and it will report 9:00:10.

The same scale factor is applied to any functions that specify an interval, so a ‘nanosleep’ for 500ms would call the real ‘nanosleep’ with a scaled parameter of only 50ms.

This does really speed up tests, which is a huge benefit, but there’s more. By applying ridiculous speed factors, you can really stress a program, effectively simulating a heavily loaded system or one that is trying to handle too great a workload. It’s a cheap and easy stress test that can find some race conditions. I think it’s the greatest con-trick since fakeroot!

  1. I have read through that guide and that’s how I ended up here. I’m a programming novice (started a few weeks ago). You have created a library that I am in need of and have been trying to create for days now. It controls the exact syscalls i’ve been trying to hijack. Are you willing to send me the source code? I’m really lost right now. Thanks for any help you could provide me.


    — Frank    Jul 27, 03:45 AM    #

  2. Hi Frank. Sorry, I wrote the code for work so can’t hand it out. However all the information you really need is in the link I gave, plus the man pages for the syscalls you want to hijack. If you like, mail me what you have so far and I’ll give you some hints.


    — Cam    Aug 15, 11:32 PM    #

  3. An interesting variation is to switch the arithmetic around to make a program run much slower than was intended. This can be used for example, to cheat at flash games and get huge scores…


    — Cam    Nov 20, 06:51 PM    #
All fields are optional. Any email address won't be published on your comment.
After previewing your comment, you must submit it, if you want it to appear on the site.
  Textile Help

  ·