microsoft/WSL

`shutdown` socket system call is unimplemented

kurisubrooks opened this issue ยท 25 comments

A brief description

The shutdown system call seems to be unimplemented, causing a crash when running Electron (Chromium) GUI under VcXsrv

Actual results (with terminal output if applicable)

Program crashes with

[15826:0804/155819:FATAL:render_sandbox_host_linux.cc(40)]
    Check failed: 0 == shutdown(renderer_socket_, SHUT_RD). shutdown: Invalid argument

#0 0x000001e038ee <unknown>
#1 0x000001e194fb <unknown>
#2 0x000001e19abd <unknown>
#3 0x00000288cfc2 <unknown>
#4 0x000002658599 <unknown>
#5 0x00000265eb5f <unknown>
#6 0x000002657c36 <unknown>
#7 0x0000011fe197 <unknown>
#8 0x0000011fcc70 <unknown>
#9 0x0000033a3350 main
#10 0x7ff453701f45 __libc_start_main
#11 0x00000056f089 <unknown>

Your Windows build number

1607

Steps / commands required to reproduce the error

Refer to #637, then run Chrome, Chromium or Electron

Required packages and commands to install

unity, ubuntu-desktop, ccsm
node and npm if running Electron

Parent issue

electron/electron#6722

@kurisubrooks - Thanks for letting us know. As you have noted, shutdown syscall is not implemented for AF_UNIX\SOCK_SEQPACKET sockets. We have taken a note of this issue and will work on it.

Same thing with Opera Browser

Just an update that the shutdown method for the AF_UNIX\SOCK_SEQPACKET has been checked in the dev branch and should reach the insider build soon. Please stay tuned.

@sunilmut Please check also dbus, thanks.

Might want to mark #546 as duplicate since the fixinbound is here.

14915 should have the fix for this. Closing this out, please re-open if the issue still exists.

I have the same problem if I try to run atom ide.
See the error log :

atom
roelof@DESKTOP-6BJPELK:/mnt/c/Users/rwobb$ /usr/bin/atom: regel 111: 4298 Afgebroken (geheugendump gemaakt) nohup "$ATOM_PATH" --executed-from="$(pwd)" --pid=$$ "$@" > "$ATOM_HOME/nohup.out" 2>&1
[4298:0915/210344:FATAL:render_sandbox_host_linux.cc(40)] Check failed: 0 == shutdown(renderer_socket_, SHUT_RD). shutdown: Ongeldig argument
#0 0x000001bfb0ae
#1 0x000001c10f3b
#2 0x000001c114fd
#3 0x0000025e2ae2
#4 0x0000023cf2f2
#5 0x0000023d5fd4
#6 0x0000023ce946
#7 0x0000011375e1
#8 0x0000011362d0
#9 0x000003088b7c main
#10 0x7fafa9781ec5 __libc_start_main
#11 0x000000544249

@rwobben Which build are you seeing the error on? As indicated earlier, this should be fixed in 14915+.

maybe a stupid question. How can I check it. I downloaded and installed bash yesterday.

@rwobben You can hit windows + r and enter winver in the dialog box.
image

image

But if you're on a Windows Insider build, you should get a watermark in your desktop that also says the build you're in.
image

If you're not on a Windows Insider build, then that means you have the anniversary update, and in that case that explains why you still have that error, as it was only recently fixed.

@sunilmut Opera Browser seems to start on 14926, so Shutdown now works, but it hangs again on Clone and if i launh it using --no-sandbox (workaround) it hangs on Dbus. Of course I use the fix for Dbus but Opera ignores it.
Any news for Socket Clone and Dbus?

federico@Bestia:/Scaricati$ opera --no-sandbox
[0916/133113:ERROR:browser_main_loop.cc(227)] Running without the SUID sandbox.
[0916/133113:ERROR:stack_trace_posix.cc(584)] Failed to parse the contents of /proc/self/maps
[0916/133114:ERROR:address_tracker_linux.cc(172)] Could not bind NETLINK socket: Argomento non valido
[0916/133114:ERROR:bus.cc(432)] Failed to connect to the bus: Failed to connect to socket /var/run/dbus/system_bus_socket: File o directory non esistente
[0916/133114:ERROR:bus.cc(432)] Failed to connect to the bus: Failed to connect to socket /var/run/dbus/system_bus_socket: File o directory non esistente
[0916/133114:ERROR:bus.cc(432)] Failed to connect to the bus: Failed to connect to socket /var/run/dbus/system_bus_socket: File o directory non esistente
[0916/133114:ERROR:bus.cc(432)] Failed to connect to the bus: Failed to connect to socket /var/run/dbus/system_bus_socket: File o directory non esistente
Assertion 'pthread_mutex_unlock(&m->mutex) == 0' failed at pulsecore/mutex-posix.c:108, function pa_mutex_unlock(). Aborting.
Annullato (core dump creato)
federico@Bestia:
/Scaricati$ [0916/133114:ERROR:stack_trace_posix.cc(584)] Failed to parse the contents of /proc/self/maps
libGL error: No matching fbConfigs or visuals found
libGL error: failed to load driver: swrast
[0916/133114:FATAL:thread_helpers.cc(44)] Check failed: 3UL <= task_stat.st_nlink (3 vs. 1)
#0 0x000003962cee
#1 0x00000397747b
#2 0x000001156c25
#3 0x00000065bb4f
#4 0x00000065b4e6
#5 0x00000121cd38
#6 0x00000121c1b2
#7 0x000002e0b737
#8 0x000002e0a250
#9 0x000003d9cfda OperaMain
#10 0x7f5b760f0830 __libc_start_main
#11 0x00000045bf85

Received signal 6
#0 0x000003962877
#1 0x7f5b777d13d0
#2 0x7f5b76105418 gsignal
#3 0x7f5b7610701a abort
#4 0x000003961d62
#5 0x00000397773a
#6 0x000001156c25
#7 0x00000065bb4f
#8 0x00000065b4e6
#9 0x00000121cd38
#10 0x00000121c1b2
#11 0x000002e0b737
#12 0x000002e0a250
#13 0x000003d9cfda OperaMain
#14 0x7f5b760f0830 __libc_start_main
#15 0x00000045bf85
r8: 00007fffc0792d80 r9: 00007f5b6ddc0a80 r10: 0000000000000008 r11: 0000000000000008
r12: 0000078ce83e0680 r13: 0000078ce8323dc0 r14: 00007fffc0793268 r15: 00007fffc0793258
di: 0000000000000a28 si: 0000000000000a28 bp: 0000000000000029 bx: 0000000000000000
dx: 0000000000000006 ax: 0000000000000000 cx: 0000000000000008 sp: 00007fffc0792c18
ip: 00007f5b76105418 efl: 0000000000000206 cgf: 00000053002b0033 erf: 0000000000000000
trp: 0000000000000000 msk: 0000000000000000 cr2: 0000000000000000
[end of stack trace]

I have version 1607.
Can I better wait till MS has made a patch or can I better switch to the developer ring

@iz0eyj - Those are mostly the issues I worked around here. Much of the code shares the same pedigree. AF_NETLINK sockets for address queries is the neverending +1 thread at #468. stack_trace_posix.cc(584) I mentioned in #758. You can work around pulsecore/mutex-posix.c:108 with the steps in #486. Dbus (#376) is much better as of 14926; you need to start the system bus service like Sunil describes here. You're dying at thread_helpers.cc(44) because it can't find three entries in /proc/self/task/. This can be worked around but I haven't opened a bug for it.

I might get back to it this weekend if it rains.

@therealkenc yes, I already read all this work and I can fix and workaround... but I'm a betatester so I must report the problems because end-users expects a WSL thar runs "out of the box" :)
The WSL crew is great, but also Socket and Dbus problems are great. :)

@rwobben I am not sure which version is 1607. If you would like to stay latest on WSL release from MS, Insider fast developer ring is the best option right now. But, please do take some time to review what that means to your setup (because it is not a release build), as we would not want it to be disruptive to your workflow.

1607 is the anniversary update. I had given the version number.
The build number is 14393.187

I like to have as stable as It can. That why I installed Windows 10 from a dvd and quit the developer builds

Is this problem solved in the fast or also in the slow ring ?

@rwobben to get any WSL beta test update you must switch on Fast Ring.

This is fixed as of build 14915. Still can't open chromium based apps such as atom-editor due to another issue.

@iz0eyj

Any news for Socket Clone and Dbus?
Can you please share out the strace and detailed repro steps for your scenario? From the output you shared, it appears that it is failing in NETLINK bind, for which we have very currently very limited support, but something we are looking into.

@rwobben

Is this problem solved in the fast or also in the slow ring ?
Developer builds are first released to the fast ring and after some stabilization, move to the slow ring. So, you can expect a delay. A good way to track what build is available in fast vs slow ring can be found in the Windows Insider blog

@marfillaster
This issue is specific to the socket shutdown call. If you can open a new issue with detailed repro steps and strace, it will make it easy to track it there.

Hey, getting the same thing, and I am just trying to run the electron quick start app.
Any leads?

[16431:1111/232057:FATAL:render_sandbox_host_linux.cc(40)] Check failed: 0 == shutdown(renderer_socket_, SHUT_RD). shutdown: Invalid argument
#0 0x000001e52dce
#1 0x000001e68acb
#2 0x000001e6908d
#3 0x00000292b5e2
#4 0x0000026f44b5
#5 0x0000026fa81f
#6 0x0000026f3c46
#7 0x00000121ccf7
#8 0x00000121b7d0
#9 0x000003473ea3 main
#10 0x7fdaed2a1f45 __libc_start_main
#11 0x000000574509

@iamabel - Which Windows build are you on? The fixes for WSL are being pushed out in the Windows Insider builds, until the next major Windows release.

I'm on version 1607, build 14393.447.

Also getting this error with the Electron quick start app:

/electron-quick-start$ npm start

> electron-quick-start@1.0.0 start .../electron-quick-start
> electron .

[1117:1121/213915:FATAL:render_sandbox_host_linux.cc(40)] Check failed: 0 == shutdown(renderer_socket_, SHUT_RD). shutdown: Invalid argument
#0 0x000001e5468e <unknown>
#1 0x000001e6a38b <unknown>
#2 0x000001e6a94d <unknown>
#3 0x00000292cea2 <unknown>
#4 0x0000026f5d75 <unknown>
#5 0x0000026fc0df <unknown>
#6 0x0000026f5506 <unknown>
#7 0x00000121e5b7 <unknown>
#8 0x00000121d090 <unknown>
#9 0x000003475763 main
#10 0x7f43248a1ec5 __libc_start_main
#11 0x000000575dc9 <unknown>

Asked about it here:
https://stackoverflow.com/questions/40733521/electron-not-working-out-of-the-box-on-windows-bash#40733521

How can I get the fixes?

You need the insider builds (it's easy to opt in), but there are still other blockers on Electron if that's what you're after. You'll hit #1267 next. There's a patch here but that won't get you as far as you'd probably like right now either.