D issues are now tracked on GitHub. This Bugzilla instance remains as a read-only archive.
Issue 11594 - synchronized causing segfault instead of Error.
Summary: synchronized causing segfault instead of Error.
Status: RESOLVED FIXED
Alias: None
Product: D
Classification: Unclassified
Component: druntime (show other issues)
Version: D2
Hardware: All All
: P2 normal
Assignee: No Owner
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-11-24 11:42 UTC by Shammah Chancellor
Modified: 2017-08-16 13:22 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description Shammah Chancellor 2013-11-24 11:42:32 UTC
I'm not sure why this segfaults, since core.sync.mutex has an in contract to check for null?  I am compiling in debug mode.

import std.stdio;

private Object mut;// = new Object();                                                                                                                                        

void lockedFunction()
{
  synchronized(mut)  //I asume this makes does auto mutex = new Mutex(mut) and then mutex.lock()?
    {
      writefln("Whoops");
    } //mutex.unlock();?

   /* Also results in segfault:
  auto mutex = new Mutex(mut);
  mutex.lock();
      writefln("Whoops");
  mutex.unlock();
*/
}

void main()
{
  lockedFunction();
}
Comment 1 Vladimir Panteleev 2017-07-05 19:01:47 UTC
I can't reproduce this with either today's compiler or 2.064.

In your code, you have:

private Object mut;// = new Object();

Does that mean that you instantiate it somewhere? Because if it's not instantiated (i.e. your code is ran verbatim), it does result is a segmentation fault as you described, but only because the object used for locking is null.

If you can still reproduce this today and can provide a complete test case, please reopen.
Comment 2 Shammah Chancellor 2017-07-05 21:58:28 UTC
(In reply to Vladimir Panteleev from comment #1)
> I can't reproduce this with either today's compiler or 2.064.
> 
> In your code, you have:
> 
> private Object mut;// = new Object();
> 
> Does that mean that you instantiate it somewhere? Because if it's not
> instantiated (i.e. your code is ran verbatim), it does result is a
> segmentation fault as you described, but only because the object used for
> locking is null.
> 
> If you can still reproduce this today and can provide a complete test case,
> please reopen.

The issue is that when compiled in debug mode, the "in" contract on core.sync.mutex is not checked.  This should generate an exception detailing where the error was made when you try to synchronize on an uninitialized object, rather than a segfault (when in debug mode)
Comment 3 github-bugzilla 2017-07-06 10:51:41 UTC
Commit pushed to master at https://github.com/dlang/druntime

https://github.com/dlang/druntime/commit/a2ead6dd04efdfeb283b72daf167e85fe8db9c49
Fix issue 11594: Check if the monitor is null in _d_monitorenter

In case of

```
        synchronized (null)
        {
                // ...
        }
```

runtime will try to access __monitor field on a null,
without checking if it's a null and it will segfault,
leaving programmer clueless.

https://issues.dlang.org/show_bug.cgi?id=11594
Comment 4 Vladimir Panteleev 2017-07-07 06:25:11 UTC
Oops, looks like I misunderstood the issue. Thanks for the clarification; and for the fix, Nemanja.
Comment 5 github-bugzilla 2017-08-07 12:25:55 UTC
Commit pushed to newCTFE at https://github.com/dlang/druntime

https://github.com/dlang/druntime/commit/a2ead6dd04efdfeb283b72daf167e85fe8db9c49
Fix issue 11594: Check if the monitor is null in _d_monitorenter
Comment 6 github-bugzilla 2017-08-16 13:22:33 UTC
Commit pushed to stable at https://github.com/dlang/druntime

https://github.com/dlang/druntime/commit/a2ead6dd04efdfeb283b72daf167e85fe8db9c49
Fix issue 11594: Check if the monitor is null in _d_monitorenter