On Fri, Feb 2, 2018 at 5:13 PM, mikhail <mikhail.v.gavri...@gmail.com> wrote:
> On Thu, 2018-02-01 at 21:31 +0100, Marek Olšák wrote:
>>
>> Valgrind doesn't show any memory-related issue with Mesa. It does show
>> an issue with "New Unity Project". This can corrupt the heap and cause
>> a random crash on the next call of malloc/free/new/delete:
>>
>> ==17721== Mismatched free() / delete / delete []
>> ==17721==    at 0x4C311E8: operator delete(void*) (vg_replace_malloc.c:576)
>> ==17721==    by 0xD4482C: ??? (in /home/mikhail/New Unity Project/aaa.x86_64)
>> ==17721==    by 0xD315D8: ??? (in /home/mikhail/New Unity Project/aaa.x86_64)
>> ==17721==    by 0x4FD79A: ??? (in /home/mikhail/New Unity Project/aaa.x86_64)
>> ==17721==    by 0x7E6350: ??? (in /home/mikhail/New Unity Project/aaa.x86_64)
>> ==17721==    by 0x8197CC: ??? (in /home/mikhail/New Unity Project/aaa.x86_64)
>> ==17721==    by 0x4608A1: ??? (in /home/mikhail/New Unity Project/aaa.x86_64)
>> ==17721==    by 0x5D7B009: (below main) (libc-start.c:308)
>> ==17721==  Address 0x1f6bf470 is 0 bytes inside a block of size 220 alloc'd
>> ==17721==    at 0x4C308B7: operator new[](unsigned long)
>> (vg_replace_malloc.c:423)
>> ==17721==    by 0xD47CF3: ??? (in /home/mikhail/New Unity Project/aaa.x86_64)
>> ==17721==    by 0xD3EF39: ??? (in /home/mikhail/New Unity Project/aaa.x86_64)
>> ==17721==    by 0x4FD712: ??? (in /home/mikhail/New Unity Project/aaa.x86_64)
>> ==17721==    by 0x7E2B8D: ??? (in /home/mikhail/New Unity Project/aaa.x86_64)
>> ==17721==    by 0x818B52: ??? (in /home/mikhail/New Unity Project/aaa.x86_64)
>> ==17721==    by 0x4603F1: ??? (in /home/mikhail/New Unity Project/aaa.x86_64)
>> ==17721==    by 0x5D7B009: (below main) (libc-start.c:308)
>> ==17721==
>> ==17721== Mismatched free() / delete / delete []
>> ==17721==    at 0x4C311E8: operator delete(void*) (vg_replace_malloc.c:576)
>> ==17721==    by 0xD44843: ??? (in /home/mikhail/New Unity Project/aaa.x86_64)
>> ==17721==    by 0xD315D8: ??? (in /home/mikhail/New Unity Project/aaa.x86_64)
>> ==17721==    by 0x4FD79A: ??? (in /home/mikhail/New Unity Project/aaa.x86_64)
>> ==17721==    by 0x7E6350: ??? (in /home/mikhail/New Unity Project/aaa.x86_64)
>> ==17721==    by 0x8197CC: ??? (in /home/mikhail/New Unity Project/aaa.x86_64)
>> ==17721==    by 0x4608A1: ??? (in /home/mikhail/New Unity Project/aaa.x86_64)
>> ==17721==    by 0x5D7B009: (below main) (libc-start.c:308)
>> ==17721==  Address 0x1f6bf590 is 0 bytes inside a block of size 220 alloc'd
>> ==17721==    at 0x4C308B7: operator new[](unsigned long)
>> (vg_replace_malloc.c:423)
>> ==17721==    by 0xD47ED7: ??? (in /home/mikhail/New Unity Project/aaa.x86_64)
>> ==17721==    by 0xD3EF39: ??? (in /home/mikhail/New Unity Project/aaa.x86_64)
>> ==17721==    by 0x4FD712: ??? (in /home/mikhail/New Unity Project/aaa.x86_64)
>> ==17721==    by 0x7E2B8D: ??? (in /home/mikhail/New Unity Project/aaa.x86_64)
>> ==17721==    by 0x818B52: ??? (in /home/mikhail/New Unity Project/aaa.x86_64)
>> ==17721==    by 0x4603F1: ??? (in /home/mikhail/New Unity Project/aaa.x86_64)
>> ==17721==    by 0x5D7B009: (below main) (libc-start.c:308)
>>
>> Marek
>
>
> Tak  said: We'll investigate, but if that were the case, wouldn't it affect 
> the intel driver the same way?

There are several factors making radeonsi more vulnerable to heap corruption:
- radeonsi has a lot of running threads, unlike intel
- radeonsi uses LLVM, which is a big user of new/delete to the extent
of making new/delete/malloc/free a little slower for Mesa and Unity.

Closed-source drivers use their own allocator for memory allocations
(usually jemalloc), so they are immune to such Unity bugs.

Marek
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Reply via email to