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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019