[Gc] Linux emulation on Windows 10

[Paul Bone]

Hi.

We use Boehm GC in the Mercury programming language, which is used by the
PrinceXML software.

One of our clients is reporting segfaults using a verion of Prince compiled
for Linux under the new Windows 10 Linux emulation. The problem can be
worked-around by saying GC_MARKERS=1.

I have no Windows systems, so I'm wondering if anyone is aware of problems
related to parallel marking or stopping and tracing of threads under the new
Linux compatibility layer on Windows 10? I realize this is probably a long
shot.

Probably the best we can do is somehow detect this environment at runtime
and disable parallel marking then.

[Lennart Sorensen]

Post by Paul Bone
Hi.
We use Boehm GC in the Mercury programming language, which is used by the
PrinceXML software.
One of our clients is reporting segfaults using a verion of Prince compiled
for Linux under the new Windows 10 Linux emulation. The problem can be
worked-around by saying GC_MARKERS=1.
I have no Windows systems, so I'm wondering if anyone is aware of problems
related to parallel marking or stopping and tracing of threads under the new
Linux compatibility layer on Windows 10? I realize this is probably a long
shot.
Probably the best we can do is somehow detect this environment at runtime
and disable parallel marking then.

There were problems with threads.

https://github.com/Microsoft/BashOnWindows/issues/204
and
https://github.com/Microsoft/BashOnWindows/issues/875

Some people seem to say that builds from the last month or two are better
now, but that would mean you have to be running the insider builds rather
than the current release version.

So it might be related to this problem.

[Paul Bone]

Post by Lennart Sorensen

Post by Paul Bone
Hi.
We use Boehm GC in the Mercury programming language, which is used by the
PrinceXML software.
One of our clients is reporting segfaults using a verion of Prince compiled
for Linux under the new Windows 10 Linux emulation. The problem can be
worked-around by saying GC_MARKERS=1.
I have no Windows systems, so I'm wondering if anyone is aware of problems
related to parallel marking or stopping and tracing of threads under the new
Linux compatibility layer on Windows 10? I realize this is probably a long
shot.
Probably the best we can do is somehow detect this environment at runtime
and disable parallel marking then.

There were problems with threads.
https://github.com/Microsoft/BashOnWindows/issues/204
and
https://github.com/Microsoft/BashOnWindows/issues/875
Some people seem to say that builds from the last month or two are better
now, but that would mean you have to be running the insider builds rather
than the current release version.
So it might be related to this problem.

Maybe.

At this stage, and particularly without access to such a system, this could
really be anything. I've recommended that we say that we do not support
this particular environment. Our windows users should just be using the
windows builds.

Thanks.

[Ivan Maidanski]

Hi,
Pthread_cond_wait is used only by parallel marker inside GC. So it seems the right guess. I don't have a workaround suggestion though (except for the mentioned one).
Regards,
Ivan

Post by Paul Bone

Post by Lennart Sorensen

Post by Paul Bone
Hi.
We use Boehm GC in the Mercury programming language, which is used by the
PrinceXML software.
One of our clients is reporting segfaults using a verion of Prince compiled
for Linux under the new Windows 10 Linux emulation. The problem can be
worked-around by saying GC_MARKERS=1.
I have no Windows systems, so I'm wondering if anyone is aware of problems
related to parallel marking or stopping and tracing of threads under the new
Linux compatibility layer on Windows 10? I realize this is probably a long
shot.
Probably the best we can do is somehow detect this environment at runtime
and disable parallel marking then.

There were problems with threads.
https://github.com/Microsoft/BashOnWindows/issues/204
and
https://github.com/Microsoft/BashOnWindows/issues/875
Some people seem to say that builds from the last month or two are better
now, but that would mean you have to be running the insider builds rather
than the current release version.
So it might be related to this problem.

Maybe.
At this stage, and particularly without access to such a system, this could
really be anything. I've recommended that we say that we do not support
this particular environment. Our windows users should just be using the
windows builds.
Thanks.
--
Paul Bone
http://paul.bone.id.au
_______________________________________________
bdwgc mailing list
https://lists.opendylan.org/mailman/listinfo/bdwgc

[Florian Weimer]

Post by Ivan Maidanski
Pthread_cond_wait is used only by parallel marker inside GC. So it
seems the right guess. I don't have a workaround suggestion though
(except for the mentioned one).

If the futex usage by the condvar is problematic, maybe the new
condvar algorithm in glibc 2.25 will fix it by accident?

I test glibc sporadically with the subsystem, but with the current
(non-insider) build at least, there is so much breakage in the glibc
test suite that the results are pretty much meaningless.

In addition, I suspect that some antivirus software breaks the
subsystem when it is used to build new binaries.

[David Eklund]

My understanding is that updates to the Windows Subsystem for Linux are
essentially not being merged to the mainline release branch updates Windows
users normally receive, and there have been many bugs that have been
resolved over the last several months that are only available via Insider
builds. If your user really wants to use that environment seriously (while
understanding it's still a beta), I'd suggest to them they need to update
to the Fast ring of Insider builds (and accept the risks involved).

Post by Florian Weimer

Post by Ivan Maidanski
Pthread_cond_wait is used only by parallel marker inside GC. So it
seems the right guess. I don't have a workaround suggestion though
(except for the mentioned one).

If the futex usage by the condvar is problematic, maybe the new
condvar algorithm in glibc 2.25 will fix it by accident?
I test glibc sporadically with the subsystem, but with the current
(non-insider) build at least, there is so much breakage in the glibc
test suite that the results are pretty much meaningless.
In addition, I suspect that some antivirus software breaks the
subsystem when it is used to build new binaries.
_______________________________________________
bdwgc mailing list
https://lists.opendylan.org/mailman/listinfo/bdwgc