[Issue 11777] [ICE] Compiler segfault in `callfunc` in `e2ir.c`

[d-bugmail at puremagic.com]

https://d.puremagic.com/issues/show_bug.cgi?id=11777



--- Comment #4 from Denis Shelomovskij <verylonglogin.reg at gmail.com> 2013-12-24 16:10:31 MSK ---
(In reply to comment #2)
> https://github.com/D-Programming-Language/dmd/commit/89e778a9eee645d2975cbb134e5cfd578bc1ab01
> 
> This will be much more likely to stay fixed if you can find a reduced test
> case...

Please, no. Memory corruption cause must be detected. I will investigate today.

> A possible way to find it would be to NULL out the array instead of freeing.

Nop. MS CRT already marks uninitialized and freed memory appropriately, it also
checks previously freed memory isn't changed when allocation returns previously
freed pointer.

> Please confirm it's fixed in your program.

Of course the bug is detriggered as I'm the pull author. )

(In reply to comment #3)
> DustMite can be used to reduce AND obfuscate test cases. I'd be glad to assist
> in using DustMite if you're having any problems applying it - just contact me.

Thanks, but I don't think it will help a lot with random memory corruption.



So, the investigation:

`callfunc` is unrelated, just a random victim who was unlucky to first access
corrupted memory. There are random failures in other functions too. Here is the
guilty code, it is in from `Scope::pop`: 
---
for (size_t i = 0; i < dim; i++)
    enclosing->fieldinit[i] |= fieldinit[i]; // line 2
mem.free(fieldinit); // line 3
---

The issue trace:
1. There is a `Scope` with `fieldinit` and there is another reference to
`fieldinit`.
2. `Scope::pop` `free`-s `fieldinit` at line 3.
3. This memory is reused for different purpose.
4. Now there is another scope with same `fieldinit`.
5. `Scope::pop` executed with such scope as `enclosing` and corrupts reused
memory at line 2.
6. Random crashed/wrong code/whatever.

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------