www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Potential regression?

reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
After updating my dmd toolchain to the latest git master today, I
started getting strange random program lockups.  At first I thought it
was caused by passing the wrong druntime options (--DRT-*) that's
incompatible with the latest druntime, but then I started seeing
messages of this sort:

	core.sync.exception.SyncError (0): Unable to unlock mutex.

The program in question uses std.parallelism.parallel to parallelize a
bunch of I/O-heavy tasks.  It has been working fine for many months now.
Did something break recently in std.parallelism or the core.sync.*
utilities that it presumably uses under the hood?


T

-- 
Just because you can, doesn't mean you should.
May 02
parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
On 03/05/2019 01:57, H. S. Teoh wrote:
 After updating my dmd toolchain to the latest git master today, I
 started getting strange random program lockups.  At first I thought it
 was caused by passing the wrong druntime options (--DRT-*) that's
 incompatible with the latest druntime, but then I started seeing
 messages of this sort:
 
 	core.sync.exception.SyncError (0): Unable to unlock mutex.
 
 The program in question uses std.parallelism.parallel to parallelize a
 bunch of I/O-heavy tasks.  It has been working fine for many months now.
 Did something break recently in std.parallelism or the core.sync.*
 utilities that it presumably uses under the hood?
 
Parallel marking by the GC has recently been merged into master which might create a couple of extra threads. Is this causing the failures? Please try disabling it with --DRT-gcopt=parallel:0
May 05
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sun, May 05, 2019 at 11:18:43AM +0200, Rainer Schuetze via Digitalmars-d
wrote:
 On 03/05/2019 01:57, H. S. Teoh wrote:
 After updating my dmd toolchain to the latest git master today, I
 started getting strange random program lockups.  At first I thought
 it was caused by passing the wrong druntime options (--DRT-*) that's
 incompatible with the latest druntime, but then I started seeing
 messages of this sort:
 
 	core.sync.exception.SyncError (0): Unable to unlock mutex.
 
 The program in question uses std.parallelism.parallel to parallelize
 a bunch of I/O-heavy tasks.  It has been working fine for many
 months now.  Did something break recently in std.parallelism or the
 core.sync.* utilities that it presumably uses under the hood?
Parallel marking by the GC has recently been merged into master which might create a couple of extra threads. Is this causing the failures? Please try disabling it with --DRT-gcopt=parallel:0
Turns out, this problem is quite elusive. Running it with --DRT-gcopt=parallel:0 *seems* to make the problem go away, but it's hard to tell because sometimes it takes 10-20 trials before a lockup happens, so I'm not 100% confident --DRT-gcopt=parallel:0 fixes the problem -- I might have just gotten lucky so far. But at least, I've yet to see a lockup with it, whereas I've seen a few lockups when running without it, so perhaps this is the problem? I wish I could narrow it down, but it's going to be hard because it's so unpredictable -- I couldn't use dustmite to reduce the code since the problem can't be reliably reproduced. T -- It is not the employer who pays the wages. Employers only handle the money. It is the customer who pays the wages. -- Henry Ford
May 14
parent reply Exil <Exil gmall.com> writes:
On Wednesday, 15 May 2019 at 00:17:26 UTC, H. S. Teoh wrote:
 On Sun, May 05, 2019 at 11:18:43AM +0200, Rainer Schuetze via 
 Digitalmars-d wrote:
 On 03/05/2019 01:57, H. S. Teoh wrote:
 After updating my dmd toolchain to the latest git master 
 today, I started getting strange random program lockups.  At 
 first I thought it was caused by passing the wrong druntime 
 options (--DRT-*) that's incompatible with the latest 
 druntime, but then I started seeing messages of this sort:
 
 	core.sync.exception.SyncError (0): Unable to unlock mutex.
 
 The program in question uses std.parallelism.parallel to 
 parallelize a bunch of I/O-heavy tasks.  It has been working 
 fine for many months now.  Did something break recently in 
 std.parallelism or the core.sync.* utilities that it 
 presumably uses under the hood?
Parallel marking by the GC has recently been merged into master which might create a couple of extra threads. Is this causing the failures? Please try disabling it with --DRT-gcopt=parallel:0
Turns out, this problem is quite elusive. Running it with --DRT-gcopt=parallel:0 *seems* to make the problem go away, but it's hard to tell because sometimes it takes 10-20 trials before a lockup happens, so I'm not 100% confident --DRT-gcopt=parallel:0 fixes the problem -- I might have just gotten lucky so far. But at least, I've yet to see a lockup with it, whereas I've seen a few lockups when running without it, so perhaps this is the problem? I wish I could narrow it down, but it's going to be hard because it's so unpredictable -- I couldn't use dustmite to reduce the code since the problem can't be reliably reproduced. T
It's hard to follow your posts, they are creating new threads instead of being in the thread you are replying to.
May 14
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, May 15, 2019 at 01:09:39AM +0000, Exil via Digitalmars-d wrote:
[...]
 It's hard to follow your posts, they are creating new threads instead
 of being in the thread you are replying to.
It's not a problem on my end, the problem is the Mailman gateway that interfaces with the NNTP server. It's not translating the message IDs correctly. Please file a bug against Mailman. T -- Never ascribe to malice that which is adequately explained by incompetence. -- Napoleon Bonaparte
May 14
parent reply Seb <seb wilzba.ch> writes:
On Wednesday, 15 May 2019 at 05:39:53 UTC, H. S. Teoh wrote:
 On Wed, May 15, 2019 at 01:09:39AM +0000, Exil via 
 Digitalmars-d wrote: [...]
 It's hard to follow your posts, they are creating new threads 
 instead of being in the thread you are replying to.
It's not a problem on my end, the problem is the Mailman gateway that interfaces with the NNTP server. It's not translating the message IDs correctly. Please file a bug against Mailman. T
For references: https://github.com/CyberShadow/DFeed/issues/99 Though of course you could just switch from the mailing list to the forum or NNTP.
May 14
parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, May 15, 2019 at 05:48:06AM +0000, Seb via Digitalmars-d wrote:
 On Wednesday, 15 May 2019 at 05:39:53 UTC, H. S. Teoh wrote:
 On Wed, May 15, 2019 at 01:09:39AM +0000, Exil via Digitalmars-d wrote:
 [...]
 It's hard to follow your posts, they are creating new threads
 instead of being in the thread you are replying to.
It's not a problem on my end, the problem is the Mailman gateway that interfaces with the NNTP server. It's not translating the message IDs correctly. Please file a bug against Mailman.
[...]
 For references:
 
 https://github.com/CyberShadow/DFeed/issues/99
 
 Though of course you could just switch from the mailing list to the
 forum or NNTP.
It's an added burden to use a different MUA just for NNTP, or to use the inefficient resource hog of a browser just for this. Since the mailing list is an "officially" supported interface, it's technically not really *my* responsibility to fix a problem in software that isn't under my control. T -- Error: Keyboard not attached. Press F1 to continue. -- Yoon Ha Lee, CONLANG
May 15