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