Bug 8924 – Delegate becomes invalid after a while

Status
RESOLVED
Resolution
INVALID
Severity
critical
Priority
P2
Component
dmd
Product
D
Version
D2
Platform
x86_64
OS
Linux
Creation time
2012-10-31T15:45:00Z
Last change time
2012-11-01T06:59:47Z
Assigned to
nobody
Creator
malteskarupke

Attachments

IDFilenameSummaryContent-TypeSize
1158delegateBug.dRun this file and you should get a segmentation fault.text/x-dsrc11422

Comments

Comment #0 by malteskarupke — 2012-10-31T15:45:46Z
Created attachment 1158 Run this file and you should get a segmentation fault. I have a bug that was quite a mess to figure out because it seemed to happen randomly. It turns out that a delegate with stack references becomes invalid after the program has run for a while. I don't have a concise repro-case, but I've attached a file which shows the problem somewhat concisely. If you run it you should see a segmentation fault. In that file you'll see a loop in line 437, which counts from 0 to 10000. If I change that loop to count only to 1000, the bug doesn't happen. So if you don't experience the bug, try changing it to 100000 and see if the bug then happens. That loop simply does unrelated work and the amount of times it runs shouldn't affect the bug at all, but somehow it does. If I'm doing something invalid in the code, it should crash right away and not work at first and then stop working after a while.
Comment #1 by maxim — 2012-11-01T05:02:53Z
It seems that the problem is introduced by someUnrelatedComplexity function. If it is dropped, everything works fine. If everything is dropped but someUnrelatedComplexity, everything still works fine, however valgrind complains about many errors related using non initialized variables and erroneous conditional jumps in gc_gcx_mark() and fullcollect(). Keeps everything same to your attachment causes similar errors (but because of already corrupted heap your code segfaults in disconnect function on accessing slots.length). Reducing number of loops as you propose, makes errors gone.
Comment #2 by malteskarupke — 2012-11-01T06:59:47Z
I've debugged it further and it was an issue with the garbage collector. I was using malloc and free but I wasn't calling GC.addRange and GC.removeRange. This now provides me with another problem because I specifically did not want the garbage collector to know about that memory, so that it wouldn't keep certain objects alive. Unfortunately that means that it then collects too much. I'll find a solution, but this bug is closed.