Community
cancel
Showing results for 
Search instead for 
Did you mean: 
skittlebrau
Beginner
146 Views

GPA 3.0: Crash collecting trace data

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?
0 Kudos
11 Replies
Neal_Pierman
Valued Contributor I
146 Views

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
Beginner
146 Views

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
Valued Contributor I
146 Views

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
Beginner
146 Views

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
Valued Contributor I
146 Views

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
Valued Contributor I
146 Views

Hello,

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

Regards,

Neal
skittlebrau
Beginner
146 Views

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
Valued Contributor I
146 Views

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
Beginner
146 Views

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
New Contributor I
146 Views

Is there a autofix of errors?
Kate
Neal_Pierman
Valued Contributor I
146 Views

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
Reply