GPA 3.0: Crash collecting trace data

[skittlebrau]

I added a bunch of trace statements to our app via the Platform View API. Things run fine until I actually attach the System Analyzer and start collecting data. Then our app crashes in tal_push_api.h, line 153 (TAL_PUSH_BEGIN_NAMED_TASK_H).

In one instance, I did get it to collect data for a while before crashing, but mostly it crashes immediately, though not in the very first call to TAL_BeginNamedTaskH. In the one "good" case, I could not get the trace data to show. When I hit the pause button, a dialog saying "Connecting" came up but it just got stuck there. I could hit cancel and resume the game but could never get a populated Platform View.

Is there some limit on the amount of data you can collect? I did wire alot of calls to this since we had an existing system of macros for our own internal tracking. These are not in extreme inner-loops or anything like that, however.

Any suggestions on how I can troubleshoot this?

[Neal_Pierman]

Hello,

First of all, could you please include a copy of the output here from running gpa_system_inspector (you can find a copy in the GPA install area)? At the same time, please verify that you have the latest version of GPA installed (build 117271), as there were a number of known issues with previous versions of Platform View that were fixed in this latest build.

As to your question, there are limits, and there are some things you can do to reduce the amount of data collected. So in parallel I'll work on this and some other suggestions that will help debug the issue.

Regards,

Neal

ps-> if running with Intel graphics, also please check that you have the latest driver installed as well

[skittlebrau]

Thanks for the quick response. I am indeed on 117271. Here is the gpa_system_inspector results:

Environment:

(Intel GPA System Inspector)

Windows 7, 64-bit DEP enabled

Num Processors: 4

Memory: 4093MB

Driver 0:

Device: NVIDIA GeForce 8800 GTX

Provider: NVIDIA

Date: 6-7-2010

Version: 8.17.12.5721

VendorId: 10de

ProductId: 191

Stepping: a2

No support for GPA Instrumentation

GPA install directory: C:\Program Files\Intel\GPA v3.0\

GPA version: 3.0.117271

Current user is in Administrators group: YES

Environment:(Intel GPA System Inspector)Windows 7, 64-bit DEP enabledNum Processors: 4Memory: 4093MBDriver 0: Device: NVIDIA GeForce 8800 GTX Provider: NVIDIA Date: 6-7-2010 Version: 8.17.12.5721 VendorId: 10de ProductId: 191 Stepping: a2 No support for GPA InstrumentationGPA install directory: C:\Program Files\Intel\GPA v3.0\GPA version: 3.0.117271Current user is in Administrators group: YES

When I have the tracing code disabled, everything works fine for me, including Platform View (with just its built-in tracing). The only oddity that I observed is that I cannot enable instrumentation globally and must instead launch the app via the monitor app. (From reading the forums, it sounds like this is a common interaction with AVG perhaps)

By the way, I apologize for the wall of text -- how can I insert blank lines into these forums?

[Neal_Pierman]

Hello,

Let's first of all see whether you're just collecting too much data, and therefore are having issues with the buffer. Please try configuring GPA Platform View to collect less data and/or increase the buffer size, and see whether this results in any change in your results:

[skittlebrau]

I increased the buffer size to 48 megs, which was the highest it let me set it. It still caused our app to crash immediately when attached. I'm sure there is probably some issue with how I have tried to integrate it, but I'm not sure where to begin. Is the failure mode for sending too much data a crash in the app being profiled?

[Neal_Pierman]

Hi,

Two things I can suggest:

• remove all but one simple set of trace calls to see if you can get this to work with your application, and if that works then try adding more
• use the macros rather than the api calls (I'm doing more checking on this to see the +/- of this approach)

Regards,

Neal

[Neal_Pierman]

Hello,

Any update in the status of this? Anything more that I can do to help?

Regards,

Neal

[skittlebrau]

Sorry, I have been have fighting other fires and haven't been able to get around to testing it with minimal (but non-zero) trace data yet. Hopefully I can get back to it soon...

[Neal_Pierman]

Hello,

One other option is that I might be able to get you "debug" versions of the libraries, so that we can get a better handle on what's going on when the crash occurs. Please let me know if you would like to pursue this option.

Also, one thing that the development team has mentioned is that when they've seen similar symptoms to what you mentioned, the culprit if often a bad pointer being passed to the routines. I'm not sure this helps your specific situation, but I thought I would mention it to see if this might trigger something for you.

Regards,

Neal

[skittlebrau]

I added some logging to my macro and while sitting at the main menu there isn't a ton of spam to the system, so maybe the debug libraries might be helpful.

Here's the data from my logging. The begin lines are TAL_BeginNamedTaskH calls. The hex digits are the handle IDs I am sending in (as created withTAL_GetStringHandle) -- and seem to be plausibly correct. The end messages are TAL_EndTask calls.

intel begin TitanSoundUpdate=8000003F

intel end

intel begin Render=80000001

intel begin RenderParticles=8000000F

intel end

intel begin RenderParticles=8000000F

intel end

intel begin RenderUI=8000000E

intel end

intel begin RenderPresent=80000007

intel end

intel end

The only difference I notice when launching from the monitor is that the handles are somewhat higher (maybe it injects it's own tags first). This still works fine until the analyzer app is actually attached to the app at which point it instantly crashes.

[kalculusinc]

Is there a autofix of errors?

Kate

[Neal_Pierman]

Hello,

Thanks for your question.

I'm not sure exactly what you are looking for here. The GPA product does attempt to ignore errors when those errors do not affect the running of the program. But in some cases it is not possible to proceed due to the nature of the specific error that we've encountered. But to help debug these issues GPA will create a "crash file" (XML format) that does contain some information about what was happening when the error was encountered, and often we can use this to help debug the problem.

Hopefully this helped answer your question. If not, please let me know.

Regards,

Neal