Potential regression?

Exil Exil at gmall.com
Wed May 15 01:09:39 UTC 2019


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.


More information about the Digitalmars-d mailing list