[PATCH 0/6] Add call thumbnails to apitrace GUI

[José Fonseca]

On Fri, Jul 13, 2012 at 7:07 AM, José Fonseca <jose.r.fonseca at gmail.com> wrote:
> On Wed, Jun 20, 2012 at 9:59 PM, Dan McCabe <zen3d.linux at gmail.com> wrote:
>> On 06/20/2012 10:08 AM, Dan McCabe wrote:
>>>
>>> On 06/20/2012 05:37 AM, José Fonseca wrote:
>>>>
>>>> Dan,
>>>>
>>>> I'm not a Qt expert, but the series looks good to me overall.
>>>>
>>>> However I'm seeing segfaults with certain traces.
>>>>
>>>> For example, when I do
>>>>
>>>>    wget
>>>> http://people.freedesktop.org/~jrfonseca/traces/cinebench-r11-test.trace
>>>>    ./qapitrace cinebench-r11-test.trace
>>>>
>>>> and then press Ctrl+T, I get
>>>>
>>>>    error: invalid snapshot stream encountered
>>>>    ASSERT: "process.state() != QProcess::Running" in file
>>>> /home/jfonseca/projects/apitrace/gui/retracer.cpp, line 409
>>>>    Aborted
>>>>
>>>> This doesn't not happen with master. It could be a random race
>>>> condition that existed before, but becomes more frequent with your
>>>> series.
>>>>
>>>> Jose
>>>>
>>>> On Fri, Jun 1, 2012 at 9:40 PM, Dan McCabe<zen3d.linux at gmail.com>  wrote:
>>>>>
>>>>> This patch set adds support for drawing the thumbnails of calls to
>>>>> the apitrace GUI app.
>>>
>>> Thanks. I will investigate.
>>>
>> While I haven't had the time to look further into this issue, the message
>> "error: invalid snapshot stream encountered" is indicative of something
>> (possibly an error in glretrace) polluting the input for qapitrace from
>> glretrace. But I will look into it in more detail.
>
> I thought of that, but glretrace didn't change, andI checked the data
> glretrce is sending, and it is pristine..
>
> It's either a latent problem in QProcess or BlockingIODevice (e.g,
> Brian Paul also reported corruption reading JSON with
> BlockingIODevice, which is why I had to disabel on commit
> 95b4056d6a126a90e8e4e046e250ee4d75a1e8db ), or just a new bug in the
> patch series.
>
> So my suggestion to narrow this is:
> - See if  disabling BlockingIODevice fixes (even if this fixes this is
> not a solution, as this will call all screenshots to be stored in
> memory -- impossible for big traces)
> - bisect which of the patches of the new series induces the problem

I fixed this.

The problem was that in certain cases, glretrace was mixing JSON state
with the PNM snapshots, due to commit
64deca6fafdc67e007ca220470df5c37849fc36c .

The code is not very stable yet though -- I'm getting infinite loops
and inifine memory allocation.

Jose