Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

qapitrace memory usage explodes after replaying trace with many errors #64

Open
vpelletier opened this Issue · 9 comments

3 participants

@vpelletier

I traced a game ("Two Worlds", available from GOG, ran on linux using wine), which generated a 1GB trace file.
It can load without a problem in qapitrace (memory usage doesn't exceed 150MB after loading).
I can lookup a few individual states with success, and memory usage going up a bit after each lookup (I guess that's just the result of displaying state details).

But after replaying the whole trace, memory usage increases regularly until I kill qapitrace.
I guess is qapitrace filling state details asynchronously from replay end/in parallel to replay, and end up using too much memory. I guess a workaround would be to allow disabling this, if my supposition is correct.

@zackr zackr was assigned
@jrfonseca
Owner

This sounds like a bug, and not intended behavior.

I'll see if this can be reproduced with other traces. (If not we might need the trace, so please keep it around.)

Did you edit the trace before replaying?

@vpelletier

I did not edit the trace.

If it helps reproducing, wine was running in 32 bits and qapitrace was running in 64bits. Both capture and retrace were done with "nouveau" driver.

@zackr
Owner

Without the trace file it's hard to tell. The gui doesn't do anything when replaying the traces. It only captures the state if it's explicitly specified and only for the call which is current right now (the last if clicked on a frame).

So if Vincent is saying that "memory usage increases while the trace is replaying" then it's most likely all in retracer and we would need the trace file to verify because on all the traces that I've seen that doesn't happen. But if Vincent is saying that "memory usage increases with the usage of qapitrace" then yes, that happens. The gui doesn't release the memory for the loaded frames, there should be some upper limit on how much memory it can use but it was never high enough on my todo to worry about it. At least not yet.

@vpelletier

To put some numbers on memory usage:
When done loading the trace: 99MB
Early after replay ends: 400MB
Then, it keeps going up at a rate of ~250MB/s
(all are measured using htop, "RES" column)
So it's actually more "memory increases after replaying trace" (might start while replaying, but the whole replay takes much more than 2 seconds, so increase probably only really occurs near trace end).

Upon closing qapitrace (title bar's X), it segfaults.
It seems that disabling error checking in the replay dialog prevents that problem. Double-buffering option doesn't seem to have any effect on this bug.

When the bug doesn't trigger during a replay, qapitrace stays at 99MB of ram usage.

I would happily upload the trace file somewhere. Any preferred place ?

@zackr
Owner
@vpelletier

Sadly, glretrace (64bits) shows no error at all, and so does looking up an individual state in qapitrace.
glretrace nicely exits when replay is over, so no leak occurs.

I'm trying to run glretrace on 32bits as replay shows glitches which weren't present when I traced. But I broke my 32bits chroot libGL some hours after reporting this bug. I don't know what causes the rendering differences, it might just be mesa/nouveau. It's just that I want to check if the extra glitches might be a hint.

BTW, is there a way to tell what is allocating the extra memory ? If it can be easily demonstrated to come from something outside apitrace (ie, a lib), it might save some time.

@jrfonseca
Owner

BTW, is there a way to tell what is allocating the extra memory ? If it can be easily demonstrated to come from something outside apitrace (ie, a lib), it might save some time.

You could try using valgrind's massif or memcheck tools.

If valgrind is too slow, you could try http://google-perftools.googlecode.com/svn/trunk/doc/heapprofile.html , or if you don't mind trying something new, you can try this too: https://github.com/jrfonseca/memtrail

@vpelletier

I used valgrind. It was really slow to load trace, but retracing was fine (I didn't ask valgrind to trace subprocesses...).
Here is the result:
Part of massif report (report header & detailed peak snapshot), and segfault details:
https://gist.github.com/1672972

I lack non-stripped versions of a few libraries. If that's a problem, just tell me and I'll retry with them installed.

FWIW, I tried memtrail, which segfaulted very early when starting qapitrace. I gave -d a try, but gdb gave (what looks to be) nonsense: tb would print a huge stack (I scrolled past 40k entries, then got bored). Either there is an impressive stack size (or tiny stack entries...) or gdb was just lost.

@jrfonseca
Owner

The peak snapshot just shows normal frame loading. It looks as Zack said -- the gui is loading all the frames to note down the errors.

I think the solution is to store the error list independently of the call list (i.e., don't tag the call list with error icons) or keep the tags also independenly of the trace calls.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.