-
Notifications
You must be signed in to change notification settings - Fork 498
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Background FUSE issue with Cygwin 32 bits #161
Comments
|
Thanks for the report. Let me make sure I understand. Is the following matrix correct?
|
Yes Bill, your matrix is right. |
I think some people used to prefer it because it has more packages. I do not know if this is still true today. (I use Cygwin64 myself.) In any case we should make sure that it works in all cases. A few questions:
There is nothing obvious in the |
This seems to work for me (Cygwin32 on Windows 10 64-bit): $ make cygfuse
gcc passthrough-fuse.c -o passthrough-cygfuse -g -Wall `pkg-config fuse --cflags --libs`
$ ./passthrough-cygfuse.exe . y:
$ ps
PID PPID PGID WINPID TTY UID STIME COMMAND
1048 1 1048 1048 ? 197609 09:41:23 /cygdrive/c/Users/billziss/Projects/winfsp/tst/passthrough-fuse/passthrough-cygfuse
3344 868 3344 4408 cons0 197609 09:41:33 /usr/bin/ps
868 1 868 868 cons0 197609 09:40:55 /usr/bin/bash
$ ls -l /cygdrive/y
total 236
-rw-r--r-- 1 billziss None 620 Jan 12 14:36 Makefile
-rw-r--r-- 1 billziss None 341 Jan 12 14:36 README.md
drwxr-xr-x 1 billziss None 0 Apr 23 15:30 build
-rwxr-xr-x 1 billziss None 175113 Apr 26 09:41 passthrough-cygfuse.exe
-rw-r--r-- 1 billziss None 9640 Apr 2 23:13 passthrough-fuse.c
-rw-r--r-- 1 billziss None 1313 Jan 12 14:36 passthrough-fuse.sln
-rw-r--r-- 1 billziss None 10382 Jan 12 14:36 passthrough-fuse.vcxproj
-rw-r--r-- 1 billziss None 708 Jan 12 14:36 passthrough-fuse.vcxproj.filters
-rw-r--r-- 1 billziss None 16420 Apr 2 23:13 winposix.c
-rw-r--r-- 1 billziss None 2415 Apr 2 23:13 winposix.h
$ uname -a
CYGWIN_NT-10.0-WOW windows 2.9.0(0.318/5/3) 2017-09-12 10:41 i686 Cygwin
$ cmd /c ver
Microsoft Windows [Version 10.0.14393]
$ systeminfo | grep x64
System Type: x64-based PC |
I see that it also allows to build a (32 bits) binary which would work on both 32 and 64 bits OS.
No stacktrace, no error message in Windows event log, and no Cygwin log.
I have confirmed on a newly built Windows 7 & 2012 R2 64 bits VMs, with last version of Cygwin32 installed from scratch.
I just tried but can't manage to |
Mine : |
Argh, yes. When linking against WinFsp directly the |
It works on the same system using Cygwin 2.9 (same version as yours). |
Wow, so something important changed in Cygwin 32 2.9 -> 2.10 ?! |
Or perhaps a different compiler, etc. |
BTW, this may also be a problem with Cygwin Check out these Cygwin FAQ entries: 4.44. What applications have been found to interfere with Cygwin? |
It helps at build time, but then at runtime :
I think so too, something has certainly been broken after 2.9 release. |
When linking with WinFsp-FUSE directly, you do not have cygfuse to help find the DLL's via the registry. So you have to help the Windows loader by copying the DLL to the same directory, adding it to the PATH, etc. |
So ! No ! |
Very interesting. So we only have a failure with Cygwin 2.10 32-bit through Cygfuse on Win64. Same version of Cygwin works when linked against WinFsp-FUSE directly. Correct? |
Yes correct, good summary 👍 |
One final question: have you tried any of the troubleshooting steps in https://cygwin.com/faq/faq.html#faq.using.fixing-fork-failures. (In particular the rebase trick. I am wondering if the cygfuse DLL has an address conflict with some other component.) It may take me a couple of days to install 2.10 and try it as I am currently busy with some other work. |
I'm on this, for sure it's not BLODA related, as I used at least 2 different fresh-installed Windows versions for the tests. One related question to this, when U'll have time, what's the difference between linking to CYGFUSE and linking directly with the WinFsp DLL ? Is there generally a preferred method ? |
CYGFUSE is a very simple wrapper around WinFsp-FUSE, that forwards FUSE calls. Its reasons of existence in order of importance:
|
Thank you Bill, clearly understood 👍
So none of the given solutions worked :-/ I gave several different Cygwin versions a try :
So I would say something was broken between 2017-11-14 and 2017-12-01. |
Thanks for the great troubleshooting. I am getting quite curious about this one and may look at it sooner rather than later :) |
CYGFUSE has this ugly hack which may actually be related to the problem: https://github.com/billziss-gh/winfsp/blob/master/opt/cygfuse/cygfuse.c#L55-L73 |
I am able to reproduce on Win10 with Cygwin32 2.10.0. |
I created a modified version of CYGFUSE and added some tracing calls and a Soon after attaching the debugger and after the The status code The problem happens within the My theory is that This is as much debugging as I have had the time to do so far. |
The problem appears to be caused by the This Cygwin commit may be related: ssp: add APIs for Stack Smashing Protection I am inclined to think that this is a Cygwin problem in the WOW64 (Windows 32-bit on Windows 64-bit) environment and not related to WinFsp. It might be possible to create a minimal repro that forks/daemonizes and calls |
Wow, very interesting, really nice investigation Bill ! Though I'm not sure to understand why it fails linking to CYGFUSE, but not linking directly with the WinFsp DLL, as in both cases I assume
This is a nice workaround, but as you stated, I'm not sure this is the way to go. Do you want me to open an issue / ask for support through the Cygwin dev list ? |
Good idea. This is likely related to their recent stack smashing and SSP commits, although we do not have a simple repro for them. |
Here's the request to Cygwin list : https://cygwin.com/ml/cygwin-developers/2018-04/msg00025.html |
Ben, thanks. I just subscribed to cygwin-developers to follow that conversation. |
@benrubson just wondering if you have seen Corinna's response in cygwin-developers and whether you have any plans to follow up on this. |
Ping @benrubson. Just wondering whether you will have any time to investigate this further? |
Sorry for my late answer Bill, I was fully stuck last days... So, Jony on the ML seems to say there was a change regarding compilation options around |
@benrubson thanks. Did not mean to offload this work to you, just wondered if it was something that you were planning to do :) Re: bisecting. I would probably start at the suspicious commit and see if a Cygwin that includes it has the problem, while a Cygwin that does not include it does not have the problem. Another thing to consider is whether the gcc defaults changed between Cygwin 2.9 and 2.10. For example, it might be that gcc in Cygwin 2.9 compiles without |
OK Bill :)
You certainly mean between the culprit commit I'll find out bisecting, and the the one just before ? |
Yes. The process is usually:
In our case we already have an initial suspect commit (the SSP commit). So I suggested trying to short-circuit this long process by trying that commit and its predecessor. |
The
I have also tested with an executable built under Cygwin 2.9. It works correctly on Cygwin 2.9, but not on Cygwin 2.10. So this may not be related to the compiler after all. |
An update on this. Although I have never found the reason that this problem happens on latest Cygwin, I have successfully worked around it. The workaround was included in the latest WinFsp beta (2018.2 B2), but unfortunately I managed to screw things up at a different place and broke daemonization on ALL Cygwin platforms in that release. A further commit (bef5ba7) further fixes daemonization, which should now work on ALL Cygwin platforms (at least in my testing). It will be included in the next beta release. |
Hi Bill,
Were you able to figure out what changed between your previous tests and this failing one ?
Well you answer here :)
Really good news ! Many thanks for your work ! So finally, issue was not on Cygwin side ? I'll be glad to test the next beta and report 👍 Thank you again ! |
I have not found the cause of the problem. I still find it likely that it is a Cygwin problem in the WOW environment. Feel free to close the issue on the Cygwin side if you want. However the understanding should be that the problem was not resolved, only worked around.
I was not, although this was on a different computer than the original one.
At some point I decided that it would be more productive for me to look into a workaround rather than trying to resolve this. This is especially because the problem appears to happen under a very specific set of circumstances that I could easily change. At the same time I was planning to do a reimplementation of FUSE loops to resolve #135. Recall that the problem was happening while executing It should be noted here that because we did not really resolve the issue, the problem may reappear later; perhaps when calling another Windows API that throws an exception and during unwinding finds the stack not right. |
Hi,
When using Cygwin 32 bits on a 64 bits OS, FUSE FS (EncFS) does not start, sounds like it fails to be sent to background.
If started in foreground (with
-f
, or with-v
which must implies-f
), then it works.Tested on Windows 7 64 bits and 2012 R2 64 bits, with WinFsp 2017.2 and 2018.1 B2.
No issue there using Cygwin 64 bits.
I just made a test using Cygwin 32 bits on Windows 7 32 bits, and it works correctly.
Pretty strange.
Thank you 👍
Ben
The text was updated successfully, but these errors were encountered: