http://d.puremagic.com/issues/show_bug.cgi?id=4150

           Summary: std.signal causes memory corruption and heisenbugs
           Product: D
           Version: 2.041
          Platform: Other
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Phobos
        AssignedTo: nobody@puremagic.com
        ReportedBy: nfxjfg@gmail.com


--- Comment #0 from nfxjfg@gmail.com 2010-05-02 20:33:25 PDT ---
Created an attachment (id=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)

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

http://d.puremagic.com/issues/show_bug.cgi?id=4150


Bernard Helyer <blood.of.life@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |blood.of.life@gmail.com


--- Comment #1 from Bernard Helyer <blood.of.life@gmail.com> 2010-05-02 21:21:13 PDT ---
It appears that you need more than one CPU for the attached program to trigger at all.

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

http://d.puremagic.com/issues/show_bug.cgi?id=4150



--- Comment #2 from Bernard Helyer <blood.of.life@gmail.com> 2010-05-02 21:24:53 PDT ---
Err, that is to say, more than one Core (or CPU I suppose).

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

http://d.puremagic.com/issues/show_bug.cgi?id=4150


nfxjfg@gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |WONTFIX


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

http://d.puremagic.com/issues/show_bug.cgi?id=4150


Brad Roberts <braddr@puremagic.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
                 CC|                            |braddr@puremagic.com
         Resolution|WONTFIX                     |


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

http://d.puremagic.com/issues/show_bug.cgi?id=4150


Denis Shelomovskij <verylonglogin.reg@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |verylonglogin.reg@gmail.com
         Depends on|                            |9606


--- Comment #3 from Denis Shelomovskij <verylonglogin.reg@gmail.com> 2013-02-27 15:06:35 MSK ---
Filed the source Issue 9606.

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

http://d.puremagic.com/issues/show_bug.cgi?id=4150



--- Comment #4 from Denis Shelomovskij <verylonglogin.reg@gmail.com> 2013-02-27 19:57:10 MSK ---
(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.

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