https://bugs.winehq.org/show_bug.cgi?id=39627
Bug ID: 39627 Summary: BreezeBrowser Pro 1.x crashes on start Product: Wine Version: 1.7.34 Hardware: x86 URL: http://www.breezesys.com/downloads/bbpro1987.exe OS: Linux Status: NEW Keywords: download, regression Severity: normal Priority: P2 Component: ntdll Assignee: wine-bugs@winehq.org Reporter: gyebro69@gmail.com CC: erich.e.hoover@wine-staging.com Regression SHA1: ca51e113e4820f8b11016c13732b1a971d2b0054 Distribution: ---
The application crashes immediately after starting (no backtrace is generated for me): fixme:heap:RtlSetHeapInformation (nil) 1 (nil) 0 stub fixme:ntdll:server_ioctl_file Unsupported ioctl 900a8 (device=9 access=0 func=2a method=0) fixme:ntdll:server_ioctl_file Unsupported ioctl 900a8 (device=9 access=0 func=2a method=0) wine: Unhandled exception 0x40000015 in thread 9 at address 0x80d930 (thread 0009), starting debugger...
If you manually create an empty 'dbglogs' directory under ~/Documents, then the application starts properly.It seems the application fails to create that directory for some reason.
Regression introduced by
commit ca51e113e4820f8b11016c13732b1a971d2b0054 Author: Erich E. Hoover erich.e.hoover@gmail.com Date: Tue Aug 19 20:31:00 2014 -0600
ntdll: Unify retrieving the attributes of a file.
The commit can't be reverted on git (Wine build failure), however the application starts properly with the previous commit (and dbglogs directory is created).
Still present in wine-1.7.55-73-g39f2ed3.
bbpro1987.exe sha1: ead99cf82bc8eeac4413ed4939891bbe57251058
https://bugs.winehq.org/show_bug.cgi?id=39627
Béla Gyebrószki gyebro69@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Blocks| |36932
https://bugs.winehq.org/show_bug.cgi?id=39627
Sebastian Lackner sebastian@fds-team.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |sebastian@fds-team.de
--- Comment #1 from Sebastian Lackner sebastian@fds-team.de --- Created attachment 52808 --> https://bugs.winehq.org/attachment.cgi?id=52808 Revert patch
Confirming, the app also works again when reverting the patch on top of current Wine git.
https://bugs.winehq.org/show_bug.cgi?id=39627
--- Comment #2 from Sebastian Lackner sebastian@fds-team.de --- The patch looks like a noop at first sight, but there is indeed a minor difference:
--- snip --- - if (stat( unix_name.Buffer, &st ) == -1) + if (get_file_info( unix_name.Buffer, &st, &attributes ) == -1) --- snip ---
This has the effect that the Documents folder (which is a symlink) is now reported as reparse point, before that it wasn't. The remaining question is if this triggers a bug somewhere in Wine code, or if the application just cannot deal with reparse points.
https://bugs.winehq.org/show_bug.cgi?id=39627
--- Comment #3 from Sebastian Lackner sebastian@fds-team.de --- Created attachment 52809 --> https://bugs.winehq.org/attachment.cgi?id=52809 Minimal revert
This patch only reverts the differences introduced by the patch, which also fixes the issue. Still needs more time to investigate which solution is right.
https://bugs.winehq.org/show_bug.cgi?id=39627
Sebastian Lackner sebastian@fds-team.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|BreezeBrowser Pro 1.x |BreezeBrowser Pro 1.x |crashes on start |crashes on start | |(FSCTL_GET_REPARSE_POINT is | |not implemented)
--- Comment #4 from Sebastian Lackner sebastian@fds-team.de --- After analyzing the issue a bit more, the change introduced by Erichs patch was most likely correct. However, the application now wants FSCTL_GET_REPARSE_POINT. We have a staged patchset for this, and with some small modifications it allowed the app to start again. However, merging the huge patchset now during the code freeze is not really possible, so we have to defer fixing this bug till after 1.8.
https://bugs.winehq.org/show_bug.cgi?id=39627
--- Comment #5 from Sebastian Lackner sebastian@fds-team.de --- @Erich: I'd like to know your opinion. Your current patchset for junction points adds support for IO_REPARSE_TAG_MOUNT_POINT - however, on Windows there are many more reparse tags. If we would return IO_REPARSE_TAG_SYMLINK the application would be happy, but we have no way to store this additional information in the unix symlink. Should we drop support for mount points, and instead always return it would be a symlink? Or do you have any idea how to implement it properly?
https://bugs.winehq.org/show_bug.cgi?id=39627
--- Comment #6 from Erich E. Hoover erich.e.hoover@wine-staging.com --- (In reply to Sebastian Lackner from comment #5)
@Erich: I'd like to know your opinion. Your current patchset for junction points adds support for IO_REPARSE_TAG_MOUNT_POINT - however, on Windows there are many more reparse tags. If we would return IO_REPARSE_TAG_SYMLINK the application would be happy, but we have no way to store this additional information in the unix symlink. Should we drop support for mount points, and instead always return it would be a symlink? Or do you have any idea how to implement it properly?
My short term plan is to report everything as symlinks. My long term plan is to check the parent folder and see if it is on a different disk, if it is then we report it as a mount point instead of a symlinks. I'm hoping to get to this during the week, but my family is here helping with some projects - so I may be delayed.
https://bugs.winehq.org/show_bug.cgi?id=39627
super_man@post.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |super_man@post.com
--- Comment #7 from super_man@post.com --- (In reply to Sebastian Lackner from comment #4)
After analyzing the issue a bit more, the change introduced by Erichs patch was most likely correct. However, the application now wants FSCTL_GET_REPARSE_POINT. We have a staged patchset for this, and with some small modifications it allowed the app to start again. However, merging the huge patchset now during the code freeze is not really possible, so we have to defer fixing this bug till after 1.8.
Based on this can be considered as "staged" bug which has a patch available?
https://bugs.winehq.org/show_bug.cgi?id=39627
--- Comment #8 from Sebastian Lackner sebastian@fds-team.de --- (In reply to super_man from comment #7)
Based on this can be considered as "staged" bug which has a patch available?
No, the patchset currently included in Wine Staging does not resolve the issue. Erich was planning to rework the patch in order to fix this issue.
https://bugs.winehq.org/show_bug.cgi?id=39627
--- Comment #9 from Erich E. Hoover erich.e.hoover@wine-staging.com --- (In reply to Sebastian Lackner from comment #8)
(In reply to super_man from comment #7)
Based on this can be considered as "staged" bug which has a patch available?
No, the patchset currently included in Wine Staging does not resolve the issue. Erich was planning to rework the patch in order to fix this issue.
Sorry it's taken me a while to get to this. It appears to be far more complicated than whether a file is local or not, and I have not yet thought of a good way to handle this. It's possible that we could come up with a workaround for this specific applications, but I believe that the appropriate way to solve this is to store the type of the link in an extended filesystem attribute.
https://bugs.winehq.org/show_bug.cgi?id=39627
joaopa jeremielapuree@yahoo.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jeremielapuree@yahoo.fr
--- Comment #10 from joaopa jeremielapuree@yahoo.fr --- Is still a bug in current wine(3.20)?
https://bugs.winehq.org/show_bug.cgi?id=39627
Damjan Jovanovic damjan.jov@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |source CC| |damjan.jov@gmail.com
--- Comment #11 from Damjan Jovanovic damjan.jov@gmail.com --- Cygwin also suffers from this, and cannot change directory to Z: drive as a result:
---snip--- bash-4.4$ cd /cygdrive/z bash: cd: /cygdrive/z: Input/output error ---snip---
---snip--- 0128:trace:file:NtFsControlFile (0x158,0x0,0x0,0x0,0x6d9fb0,0x000900a8,0x0,0x00000000,0x80048ff0,0x00004000) 0128:warn:file:server_ioctl_file Unsupported ioctl 900a8 (device=9 access=0 func=2a method=0) ---snip---
Adding "source" keyword as well, since we do have source code for Cygwin.
Any update on committing the wine-staging patches upstream?
https://bugs.winehq.org/show_bug.cgi?id=39627
--- Comment #12 from Erich E. Hoover erich.e.hoover@gmail.com --- (In reply to Damjan Jovanovic from comment #11)
... Any update on committing the wine-staging patches upstream?
Implementing FILE_OPEN_REPARSE_POINT a while back here opened a fresh can of worms. I believe that I've now addressed everything that resulted from that change, but I want to get an unrelated fix in and then give it some time to see if any new bugs crop up. Fingers crossed, but I think that we'll finally be able to upstream the patches soon.
https://bugs.winehq.org/show_bug.cgi?id=39627
Joel Holdsworth joel@airwebreathe.org.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |joel@airwebreathe.org.uk
https://bugs.winehq.org/show_bug.cgi?id=39627
--- Comment #13 from Joel Holdsworth joel@airwebreathe.org.uk --- *** Bug 53439 has been marked as a duplicate of this bug. ***
-
wine-bugs＠winehq.org -
WineHQ Bugzilla