[Bug 39627] New: BreezeBrowser Pro 1.x crashes on start
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(a)winehq.org Reporter: gyebro69(a)gmail.com CC: erich.e.hoover(a)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(a)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 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=39627 Béla Gyebrószki <gyebro69(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |36932 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=39627 Sebastian Lackner <sebastian(a)fds-team.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |sebastian(a)fds-team.de --- Comment #1 from Sebastian Lackner <sebastian(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=39627 --- Comment #2 from Sebastian Lackner <sebastian(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=39627 --- Comment #3 from Sebastian Lackner <sebastian(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=39627 Sebastian Lackner <sebastian(a)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(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=39627 --- Comment #5 from Sebastian Lackner <sebastian(a)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? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=39627 --- Comment #6 from Erich E. Hoover <erich.e.hoover(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=39627 super_man(a)post.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |super_man(a)post.com --- Comment #7 from super_man(a)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? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=39627 --- Comment #8 from Sebastian Lackner <sebastian(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=39627 --- Comment #9 from Erich E. Hoover <erich.e.hoover(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=39627 joaopa <jeremielapuree(a)yahoo.fr> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jeremielapuree(a)yahoo.fr --- Comment #10 from joaopa <jeremielapuree(a)yahoo.fr> --- Is still a bug in current wine(3.20)? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=39627 Damjan Jovanovic <damjan.jov(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |source CC| |damjan.jov(a)gmail.com --- Comment #11 from Damjan Jovanovic <damjan.jov(a)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? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=39627 --- Comment #12 from Erich E. Hoover <erich.e.hoover(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=39627 Joel Holdsworth <joel(a)airwebreathe.org.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |joel(a)airwebreathe.org.uk -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=39627 --- Comment #13 from Joel Holdsworth <joel(a)airwebreathe.org.uk> --- *** Bug 53439 has been marked as a duplicate of this bug. *** -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=39627 --- Comment #14 from Gijs Vermeulen <gijsvrm(a)gmail.com> --- This seems to be implemented as of https://gitlab.winehq.org/wine/wine/-/commit/ee4d2f2b4ac9bf15008fe36b5a67591... Béla, is this fixed now? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=39627 --- Comment #15 from Béla Gyebrószki <gyebro69(a)gmail.com> --- Created attachment 79887 --> http://bugs.winehq.org/attachment.cgi?id=79887 crash log Wine-11.0-rc1 (In reply to Gijs Vermeulen from comment #14)
This seems to be implemented as of https://gitlab.winehq.org/wine/wine/-/commit/ ee4d2f2b4ac9bf15008fe36b5a67591ed5be527a
Béla, is this fixed now?
The download link in the URL no longer works, this old version of the application (BBrowser v1.9.8.7) can't be downloaded directly from the developer website anymore and the current version seems to be not affected by this bug. I obtained the same, old version of the app from some Czech software library, and the problem is still there using Wine-11.0-rc1. The workaround from my original comment #0 still works: creating a directory named 'dbglogs' in my Documents directory makes the application happy. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=39627 LingM <lingm+winebz(a)posteo.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |lingm+winebz(a)posteo.org --- Comment #16 from LingM <lingm+winebz(a)posteo.org> --- The Wayback Machine also still has a copy: https://web.archive.org/web/20171119110643/http://www.breezesys.com/download...
$ sha256sum bbpro1987.exe 668e86db8be8792903ba5dee8878118f76e0a7a4e0fffec57438be86d6bf7d30 bbpro1987.exe $ du -h bbpro1987.exe 56M bbpro1987.exe
-- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=39627 Béla Gyebrószki <gyebro69(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- URL|http://www.breezesys.com/do |https://web.archive.org/web |wnloads/bbpro1987.exe |/20171119110643/http://www. | |breezesys.com/downloads/bbp | |ro1987.exe -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=39627 Zeb Figura <z.figura12@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |z.figura12@gmail.com Summary|BreezeBrowser Pro 1.x |BreezeBrowser Pro 1.x |crashes on start |crashes on start (uses |(FSCTL_GET_REPARSE_POINT is |FSCTL_GET_REPARSE_POINT |not implemented) | Keywords|source | --- Comment #17 from Zeb Figura <z.figura12@gmail.com> --- FSCTL_GET_REPARSE_POINT is implemented on NT reparse points. However, we also expose two other things as reparse points: Unix directory (but not file) symlinks, and mount points. The application here sees C:\users\whatsit\Documents as a reparse point, tries to query its reparse buffer, and fails, because that emulation is incomplete. Compare bug 54903, which is a similar failure, but affecting mount points instead. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=39627 Zeb Figura <z.figura12@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|BreezeBrowser Pro 1.x |BreezeBrowser Pro 1.x |crashes on start (uses |crashes on start (uses |FSCTL_GET_REPARSE_POINT |FSCTL_GET_REPARSE_POINT on | |a Unix directory symlink) -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (3)
-
wine-bugs＠winehq.org -
WineHQ Bugzilla -
WineHQ Bugzilla