Created attachment 621
test program
The attached program shows that std.signal sometimes emits signals on objects
free'd by the GC. Essentially, this can lead to memory corruption and
heisenbugs.
Note that the test program isn't really deterministic. On my Core 2 Duo, it
takes some seconds until the assertion fails. Sometimes it segfaults as well.
Looking into std.signal, there are several problems:
- Signal.emit doesn't check if the objects are still alive (probably the cause
for this bug)
- it calls rt_detachDisposeEvent on a possibly dead object in Signal.~this (may
be the cause for the segfault)
- it silently assumes the context ptr of a delegate is a D object (unrelated to
this bug)
Comment #1 by b.helyer — 2010-05-02T21:21:13Z
It appears that you need more than one CPU for the attached program to trigger at all.
Comment #2 by b.helyer — 2010-05-02T21:24:53Z
Err, that is to say, more than one Core (or CPU I suppose).
Comment #3 by verylonglogin.reg — 2013-02-27T04:06:35Z
Filed the source Issue 9606.
Comment #4 by verylonglogin.reg — 2013-02-27T08:57:10Z
(In reply to comment #0)
> Looking into std.signal, there are several problems:
> - Signal.emit doesn't check if the objects are still alive (probably the cause
> for this bug)
> - it calls rt_detachDisposeEvent on a possibly dead object in Signal.~this (may
> be the cause for the segfault)
These are thread-related issues as GC collects and calls finalizers from different thread. See Issue 9606.
> - it silently assumes the context ptr of a delegate is a D object (unrelated to
> this bug)
This is documented now but still too bad. See Issue 9603.
Comment #5 by bugzilla — 2019-11-19T16:22:46Z
Works for me. As this is not deterministic, I leave it open. Maybe someone else could also check?
Comment #6 by robert.schadek — 2024-12-01T16:13:21Z