On Fri, Feb 2, 2018 at 5:13 PM, mikhail <mikhail.v.gavrilov at 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
