[Mesa-dev] [PATCH 1/4] intel/aubinator: Allow for the case where the ascii85 decode fails

Jason Ekstrand jason at jlekstrand.net
Thu Dec 28 14:26:25 UTC 2017


On December 28, 2017 08:24:03 Jason Ekstrand <jason at jlekstrand.net> wrote:

> On December 28, 2017 01:30:11 Kenneth Graunke <kenneth at whitecape.org> wrote:
>
>> On Wednesday, December 27, 2017 3:13:42 PM PST Jason Ekstrand wrote:
>>> On December 27, 2017 17:06:43 Kenneth Graunke <kenneth at whitecape.org> wrote:
>>>
>>> > On Wednesday, December 27, 2017 12:58:12 PM PST Jason Ekstrand wrote:
>>> >> ---
>>> >>  src/intel/tools/aubinator_error_decode.c | 6 ++++--
>>> >>  1 file changed, 4 insertions(+), 2 deletions(-)
>>> >>
>>> >> diff --git a/src/intel/tools/aubinator_error_decode.c
>>> >> b/src/intel/tools/aubinator_error_decode.c
>>> >> index d6fbfe0..f0c5b5b 100644
>>> >> --- a/src/intel/tools/aubinator_error_decode.c
>>> >> +++ b/src/intel/tools/aubinator_error_decode.c
>>> >> @@ -350,8 +350,10 @@ read_data_file(FILE *file)
>>> >>           uint32_t *data = NULL;
>>> >>           int count = ascii85_decode(line+1, &data, line[0] == ':');
>>> >>           if (count == 0) {
>>> >> -            fprintf(stderr, "ASCII85 decode failed.\n");
>>> >> -            exit(EXIT_FAILURE);
>>> >> +            fprintf(stderr, "ASCII85 decode of %s at 0x%08"PRIx64"
>>> failed.\n",
>>> >> +                    sections[sect_num].buffer_name,
>>> >> +                    sections[sect_num].gtt_offset);
>>> >> +            continue;
>>> >>           }
>>> >>           sections[sect_num].data = data;
>>> >>           sections[sect_num].count = count;
>>> >>
>>> >
>>> > What's the rationale, here?  At this point, you've got a malformed file.
>>> > What do we gain by supporting invalid file formats?
>>>
>>> Because there's a decent chance (I've got multiple files on my laptop that
>>> are this way) that other BOs will decompress ok.  I still don't know why
>>> aubinator is failing to decompress things.
>>>
>>> --Jason
>>
>> Are they just from old pre-ascii85 support kernels or something?
>
> Nope, 4.14 or 4.13.

I should be more specific.  It's not ascii85 decide that fails, it's zlib 
decompression.  I have no idea why.




More information about the mesa-dev mailing list