[Bug 50227] New: Logos 8 indexer crashes
https://bugs.winehq.org/show_bug.cgi?id=50227 Bug ID: 50227 Summary: Logos 8 indexer crashes Product: Wine Version: 5.20 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: galanlama(a)gmail.com Distribution: --- Created attachment 68735 --> https://bugs.winehq.org/attachment.cgi?id=68735 Backtrace produced by the wine debugger. After opening Logos, indexer crashes after a few seconds. Same result by running indexer.exe directly. -- 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=50227 Frank <franksauer(a)cox.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |franksauer(a)cox.net --- Comment #1 from Frank <franksauer(a)cox.net> --- This issue is also present in Logos 9. Former work around, which allowed indexer to run and complete it's process was to set winecfg to Win7. The workaround no longer works. -- 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=50227 Anastasius Focht <focht(a)gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- URL| |https://web.archive.org/web | |/20210209172851/https://dow | |nloads.logoscdn.com/LBS8/In | |staller/8.7.0.0039/Logos-x8 | |6.msi Summary|Logos 8 indexer crashes |Logos 8 Bible Software | |(.Net 4.7.2 app) indexer | |crashes CC| |focht(a)gmx.net Keywords| |dotnet, download --- Comment #2 from Anastasius Focht <focht(a)gmx.net> --- Hello folks, adding stable download link via Internet Archive https://web.archive.org/web/20210209172851/https://downloads.logoscdn.com/LB... I can't reproduce the problem with the indexer of Logos 8. Registered an account at www.logos.com and logged in when 'Logos.exe' was asking for credentials on startup. It downloaded additional media sets upon first run. Logos app and the indexer works. --- snip --- $ pwd /home/focht/.wine/drive_c/users/focht/Local Settings/Application Data/Logos $ wine ./Logos.exe ... --- snip --- Manually (although not recommended): --- snip --- $ pwd /home/focht/.wine/drive_c/users/focht/Local Settings/Application Data/Logos/System $ wine ./LogosIndexer.exe /user:<hashedusername> /lang:en-US ... --- snip --- Prerequisites: * 'winetricks -q dotnet472' * 'winetricks -q arial' (work around crash in 'LogosCEF.exe' browser process) --- quote --- Former work around, which allowed indexer to run and complete it's process was to set winecfg to Win7. --- quote --- WinVer 'Windows 7' is the default since many years. Why would you change it to something different? Also MS .NET Framework 4.7 requires Windows 7 (https://docs.microsoft.com/en-us/dotnet/framework/get-started/system-require...). If you use a different WinVer setting you are basically shooting yourself in the foot. Don't change defaults unless you know what it technically means. $ sha1sum Logos-x86.msi 659900692c79c0df046f413eb33e1d729487fe19 Logos-x86.msi $ du -sh Logos-x86.msi 187M Logos-x86.msi $ wine --version wine-6.2 Regards -- 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=50227 --- Comment #3 from Frank <franksauer(a)cox.net> --- (In reply to Anastasius Focht from comment #2)
Hello folks,
adding stable download link via Internet Archive
https://web.archive.org/web/20210209172851/https://downloads.logoscdn.com/ LBS8/Installer/8.7.0.0039/Logos-x86.msi
I can't reproduce the problem with the indexer of Logos 8. Registered an account at www.logos.com and logged in when 'Logos.exe' was asking for credentials on startup. It downloaded additional media sets upon first run. Logos app and the indexer works.
I never really had a problem on Logos 8 myself, others had reported it - this issue is with the update to Logos 9. Logos 9 has significant features that are not available with the earlier engines (Logos 8).
Prerequisites:
* 'winetricks -q dotnet472' * 'winetricks -q arial' (work around crash in 'LogosCEF.exe' browser process)
Arial is installed. dotnet472 will not install - it throws an error stating that dotnet45 has been broken since Wine 5.18 and cancels the install. Tried the --force with no success.
--- quote --- Former work around, which allowed indexer to run and complete it's process was to set winecfg to Win7. --- quote ---
WinVer 'Windows 7' is the default since many years. Why would you change it to something different? Also MS .NET Framework 4.7 requires Windows 7 (https://docs.microsoft.com/en-us/dotnet/framework/get-started/system- requirements). If you use a different WinVer setting you are basically shooting yourself in the foot. Don't change defaults unless you know what it technically means.
The Logos installer will not install on anything other than Win10. So we have to be set to Win10 for the install and then move to win7 for the indexing. (I also had no problem installing, downloading, indexing and running Logos 8 under Win10) Our goal would be to have Logos 9 with all its new features and resources that were obtained through paid upgrades to index as Logos 8 did/does.
$ sha1sum Logos-x86.msi 659900692c79c0df046f413eb33e1d729487fe19 Logos-x86.msi
$ du -sh Logos-x86.msi 187M Logos-x86.msi
$ wine --version wine-6.2
Regards
-- 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=50227 --- Comment #4 from Anastasius Focht <focht(a)gmx.net> --- Hello Frank, --- quote --- I never really had a problem on Logos 8 myself, others had reported it - this issue is with the update to Logos 9. Logos 9 has significant features that are not available with the earlier engines (Logos 8). --- quote --- then the whole premise of the bug would be wrong. Benjamin created the bug because Logos 8 indexer crashes.
From your description it seems Logos 9 is likely a different animal. If Logos 9 requires Windows 10 then one can assume the software / third-party frameworks used are substantially different.
I propose to resolve this bug as 'FIXED' or 'WORKSFORME' since you couldn't reproduce the problem with Logos 8 indexer either. I can create a new bug for Logos 9 indexer crash and try to reproduce it. Alternatively you need to provide all the information I ask you for there. Regards -- 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=50227 --- Comment #5 from Frank <franksauer(a)cox.net> --- (In reply to Anastasius Focht from comment #4)
Hello Frank,
--- quote --- I never really had a problem on Logos 8 myself, others had reported it - this issue is with the update to Logos 9. Logos 9 has significant features that are not available with the earlier engines (Logos 8). --- quote ---
then the whole premise of the bug would be wrong. Benjamin created the bug because Logos 8 indexer crashes.
From your description it seems Logos 9 is likely a different animal. If Logos 9 requires Windows 10 then one can assume the software / third-party frameworks used are substantially different.
I propose to resolve this bug as 'FIXED' or 'WORKSFORME' since you couldn't reproduce the problem with Logos 8 indexer either.
I can create a new bug for Logos 9 indexer crash and try to reproduce it. Alternatively you need to provide all the information I ask you for there.
Regards
Thank you. All bugs listed for Logos 8 are still an issue in Logos 9. I am not familiar with how much the engine changed from 8 to 9, as the biggest selling point from version to version is related to new features and resources - so I'm not sure how much changed with the indexer on the move to Logos 9. -- 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=50227 Anastasius Focht <focht(a)gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEEDINFO Ever confirmed|0 |1 URL|https://web.archive.org/web |https://web.archive.org/web |/20210209172851/https://dow |/20210214194341/https://dow |nloads.logoscdn.com/LBS8/In |nloads.logoscdn.com/LBS9/In |staller/8.7.0.0039/Logos-x8 |staller/9.2.0.0014/Logos-x6 |6.msi |4.msi Summary|Logos 8 Bible Software |Logos 8.x - 9.x Bible |(.Net 4.7.2 app) indexer |Software (.Net 4.7.2 app) |crashes |indexer crashes --- Comment #6 from Anastasius Focht <focht(a)gmx.net> --- Hello Frank, --- quote --- so I'm not sure how much changed with the indexer on the move to Logos 9. --- quote --- ok, using the bug report for Logos 9 indexer as well. I've installed Logos 9 into clean 64-bit WINEPREFIX. The indexer process 'LogosIndexer.exe' heavily churns CPU and definitely progressing over time until the end. Hover over the systray icon and check "...indexing xx % complete". Stats at 54% completion: --- snip --- $ prtstat 1194775 Process: LogosIndexer.ex State: S (sleeping) CPU#: 3 TTY: 136:0 Threads: 18 Process, Group and Session IDs Process ID: 1194775 Parent ID: 1 Group ID: 1194636 Session ID: 1155558 T Group ID: 1155558 Page Faults This Process (minor major): 2889379 1592 Child Processes (minor major): 0 0 CPU Times This Process (user system guest blkio): 1738.61 249.52 0.00 0.00 Child processes (user system guest): 0.00 0.00 0.00 Memory Vsize: 1267367 MB RSS: 2062 MB RSS Limit: 18446744073709 MB Code Start: 0x7d400000 Code Stop: 0x7d40180a Stack Start: 0x7ffd24143490 Stack Pointer (ESP): 0 Inst Pointer (EIP): 0 Scheduling Policy: normal Nice: 0 RT Priority: 0 (non RT) $ cat /proc/1194775/io rchar: 1277253167 wchar: 505014410 syscr: 1379907 syscw: 274538 read_bytes: 424292352 write_bytes: 485101568 --- snip --- The process took about 55 minutes to finish indexing in my case. I can't really help here unless there is a reproducible case. You need to provide more data. Console output, backtraces from Logos 9 indexer crashes. Prerequisites: * 'winetricks -q dotnet472' * 'winetricks -q arial' (work around crash in 'LogosCEF.exe' browser process) * 'winetricks win10' (version requirement for installer) Stable download via Internet Archive: Logos 9 web-installer: https://web.archive.org/web/20210214193848/https://downloads.logoscdn.com/LB... $ sha1sum LogosSetup.exe 9b8a8b4b3769b701a44c8357955aac8814a0027d LogosSetup.exe $ du -sh LogosSetup.exe 544K LogosSetup.exe I've sneaked the direct link to full MSI installer package from the web-installer script and created a snapshot via Internet Archive as well: https://web.archive.org/web/20210214194341/https://downloads.logoscdn.com/LB... $ sha1sum Logos-x64.msi 1e109967fbdf4dcd9a424490bc39395ce1fda4ef Logos-x64.msi $ du -sh Logos-x64.msi 207M Logos-x64.msi Regards -- 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=50227 --- Comment #7 from Frank <franksauer(a)cox.net> --- Created attachment 69385 --> https://bugs.winehq.org/attachment.cgi?id=69385 Tested with LC_All=C due to parse_url spamming I am currently running a full terminal of LogosIndexer.exe, it will be posted later. The parse_url that is spamming is: 0130:fixme:path:parse_url failed to parse L"Libronix.DigitalLibrary.Utility.resources" -- 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=50227 --- Comment #8 from Frank <franksauer(a)cox.net> --- Comment on attachment 69385 --> https://bugs.winehq.org/attachment.cgi?id=69385 Tested with LC_All=C due to parse_url spamming Tested with LC_ALL=C based on Bug 47277 workaround in this application's bug past. -- 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=50227 --- Comment #9 from Anastasius Focht <focht(a)gmx.net> --- Hello Frank, thanks for the console logs. Unfortunately the logs look fine. There is nothing suspicious. Do you get a crash reporter dialog? If there is a fatal crash in the indexer process there should be a crash reporter dialog shown. You need to click 'Close' in that case so the .NET CLR outputs a managed backtrace to console. Regards -- 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=50227 --- Comment #10 from Frank <franksauer(a)cox.net> --- Created attachment 69387 --> https://bugs.winehq.org/attachment.cgi?id=69387 Spammed then killed OOM I know this log is useless, but this is what is happening. that error spamming so long that the front end of the console is truncated and the process just winds up being killed when OOM -- 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=50227 --- Comment #11 from Frank <franksauer(a)cox.net> --- Comment on attachment 69387 --> https://bugs.winehq.org/attachment.cgi?id=69387 Spammed then killed OOM Also this ran for over 4 hours before I went to sleep -- 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=50227 --- Comment #12 from Frank <franksauer(a)cox.net> --- What would the best way to get a helpful Backtrace? It seems that the commands I tried from the WineHQ Wiki just continue with the same spamming of the parse_url error -- 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=50227 --- Comment #13 from Anastasius Focht <focht(a)gmx.net> --- Hello Frank, --- quote --- What would the best way to get a helpful Backtrace? It seems that the commands I tried from the WineHQ Wiki just continue with the same spamming of the parse_url error --- quote --- well, the message from your console logs indicate the process got killed by Linux out of memory manager. In that case there is nothing the app or Wine's crash reporter can do about it. The process is killed externally. One could use: --- snip --- $ sudo sh -c "echo -1000 > /proc/$PID/oom_score_adj" --- snip --- to prevent the process from being picked first by OOM killer in low memory situation. But if there is a real (fast) leak it will go to 100% and cause the system to freeze or panic, depending on the system setting. Another more advanced approach is to put the process with another one in a v2 cgroup with memory constraints and use one as sacrificial process with a low OOM score. The kill signal of the sacrificial process (due to OOM) could be trapped and then used to suspend all threads of the memory eating process. At that point the process state could be checked with regards to resource usage/mappings/handle leakage etc. Still, it would be hard to diagnose application specific resources, such as object/handled from .NET world. How does the 64-bit .NET indexer process behave on Windows in the same situation (assuming same Logos 9.x installation/dataset)? Some bugs aren't necessarily Wine bugs but application ones. Regards -- 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=50227 --- Comment #14 from Frank <franksauer(a)cox.net> --- (In reply to Anastasius Focht from comment #13)
How does the 64-bit .NET indexer process behave on Windows in the same situation (assuming same Logos 9.x installation/dataset)? Some bugs aren't necessarily Wine bugs but application ones.
Thanks for all the info Anastasius! The exact same install on Windows 10 has no issue indexing at all. Works perfectly and substantially faster. The thing that stands out to me, is there is absolutely no file activity going on with Logos 9 on wine, during the indexer process. Typically, I can keep a file manager open to the applicable folders for the 3 primary indices that Logos creates and watch the indexer working. By working, I mean that the index folders would start with two file and there would be activity on these files as the indexer is indexing the resources. So, there would be growth from MBs up to GBs depending on this size of a library. Eventually, when the process is complete, there are 9 files in each of the Index Folders. At this time, the indexer is doing nothing beyond running - there is no file activity at all. -- 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=50227 --- Comment #15 from Frank <franksauer(a)cox.net> --- Created attachment 69388 --> https://bugs.winehq.org/attachment.cgi?id=69388 Indexer run with WINEDEBUG=+relay -- 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=50227 --- Comment #16 from Frank <franksauer(a)cox.net> --- In working with Bradley from Logos, we were able to come up with a work around to get the indexer to complete. The issue appears to be with the AutoComplete database building. The indexer does not seem to actually ever begin indexing and hangs on the AutoComplete database structure which proceeds the actual indexing when the indexer starts. The issue is not on Windows and is limited to Wine. For comparison my database file in the Logs wine install was nowhere near the fully completed database file from my Windows installation, which was over 150 MB. So something in the wine install is not allowing the AutoComplete Database to build, thus allowing the indexer to begin indexing the resources upon completion of said database. The workaround that I used was to copy the two files located in the AutoComplete directory from my Windows install to the Wine install - this allowed the indexer to move on and fully index the system without crashing. I had my wine set to Win10 and it indexed without issue. It also allowed greater use of the CPU which was limited to the low teens % and after copying the files over allowed the CPU to uses as much as needed, which allowed the RAM use to reach nowhere near the rate without copying the files over. -- 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=50227 --- Comment #17 from Frank <franksauer(a)cox.net> --- It looks as though this is a continuing issue, even after the workaround allows initial full indexing. I had about 10 resources update today and the AutoComplete files were hanging the system and not allowing the typically few minutes of indexing the updates into the index files. So to keep Logos 9 running efficiently, either updates will have to be blocked - which means purchasing new resources and or getting the updated resources with corrections and improvements will be blocked. Or - You will have to have a working and fully updated Windows install readily available to copy the two files over to the Wine install after every resource update. -- 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=50227 m0rvj <johnpgoodman(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |johnpgoodman(a)gmail.com --- Comment #18 from m0rvj <johnpgoodman(a)gmail.com> --- Just confirming Frank's finding. I have copied an AutoComplete.db file from my windows install and then run the Logos again. This time indexing completed in the expected time. -- 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=50227 --- Comment #19 from m0rvj <johnpgoodman(a)gmail.com> --- I've had a careful look through AutoComplete.db with sqlitebrowser. It appears to be, as the name suggests, a database of or for autocompletion of abbreviations and linked concepts. It is also multilingual and includes text in zh-Hans and zh-Hant. I suspect the issue is to do with the handling of one of these unicode sets. I'm no expert in such things though I note we ran into problems with this before https://bugs.winehq.org/show_bug.cgi?id=47277 Are these issues connected? -- 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=50227 --- Comment #20 from m0rvj <johnpgoodman(a)gmail.com> --- Ok based on an assumption of a connection, I deleted all my indexes and used winecfg to select just LogosIndexer.exe and set a windows version of winxp. It successfully created the AutoComplete.db file and has moved on to indexing. The full index will take this machine a while since my library is huge. I think that is a solid work around! -- 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=50227 --- Comment #21 from m0rvj <johnpgoodman(a)gmail.com> --- The indexer succeeds in creating AutoComplete.db with windows version set to winxp but then later crashes while building the index. This means once the AutoComplete.db file is created we have to kill the process and set the Windows version to 10. Then run it a second time. I think this probably shows the issue is to do with unicode? And probably the bugs are related. -- 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=50227 --- Comment #22 from m0rvj <johnpgoodman(a)gmail.com> --- For clarity I think that something changes in how .net handles zh languages if you set the win version from winxp to win7 or higher. Our App, Logos Bible Software, is otherwise much more stable with the win version set to win10 so far as I have experienced and have confirmed with others. This appears to be the same issue described in https://bugs.winehq.org/show_bug.cgi?id=47277 -- 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=50227 --- Comment #23 from m0rvj <johnpgoodman(a)gmail.com> --- Created attachment 69454 --> https://bugs.winehq.org/attachment.cgi?id=69454 Crash log showing the db error exception If I'm reading correctly I think this just means the database is unreadable. So I need to find some other detail as to why it breaks. -- 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=50227 --- Comment #24 from m0rvj <johnpgoodman(a)gmail.com> --- Is it in fact a duplicate of https://bugs.winehq.org/show_bug.cgi?id=47277#c9 -- 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=50227 --- Comment #25 from m0rvj <johnpgoodman(a)gmail.com> --- As with comment 21 I have now tried the process 3 times with success each time. The indexer runs smoothly save for one caveat. The tray applet does not accurately show progress but the Indexer.log does. The process is to set windows version to winxp. Run the indexing until the AutoCorrect.db is created and populated. For me it comes to 117mb but it is dependent on library size. Following that I killed the process and deleted all other indexing files using the Daniel's ferion script. Then taking care to ensure all wine processes have stopped (otherwise it thinks the indexer is still running) I restarted the indexer but with the AutoCorrect.db file already in place and windows version set to win10. The indexing proceeded rapidly using only a few GB of ram and near full cpu in just 30mins. This is an incredible improvement over all previous versions. -- 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=50227 --- Comment #26 from m0rvj <johnpgoodman(a)gmail.com> --- Setting the LogosIndexer.exe to run with windows version 'vista' seems to fix everything with the indexer. This was discovered by Frank and I have verified. I've contacted Daniel about his installer script to see if we can automate configuration with: ${WINE_EXE} reg add "HKCU\\\\Software\\\\Wine\\\\AppDefaults\\\\LogosIndexer.exe" /v Version /t REG_SZ /d vista /f -- 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=50227 --- Comment #27 from m0rvj <johnpgoodman(a)gmail.com> --- This has now been repeated by many folks on the telegram channel. The indexer is definitely stable with the 'vista' setting. The ferion11 script has been updated to automatically set this during installation so most users will not find this bug but I suspect it betrays a problem that still needs addressing somewhere? https://github.com/ferion11/LogosLinuxInstaller/blob/master/CHANGELOG.md -- 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=50227 Louis Lenders <xerox.xerox2000x(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |xerox.xerox2000x(a)gmail.com Status|NEEDINFO |NEW --- Comment #28 from Louis Lenders <xerox.xerox2000x(a)gmail.com> --- (In reply to m0rvj from comment #27) but I suspect it betrays a problem that still needs addressing somewhere? Yes, probably a function that only gets called when version is > winvista. I change status to new as multiple users seem to hit 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=50227 Jactry Zeng <jactry92(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jactry92(a)gmail.com -- 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=50227 --- Comment #29 from Ken Sharp <imwellcushtymelike(a)gmail.com> --- Please retry in Wine 7.9 (or later). -- 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=50227 T. H. Wright <thwright(a)thwright.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |thwright(a)thwright.com --- Comment #30 from T. H. Wright <thwright(a)thwright.com> --- Created attachment 72640 --> https://bugs.winehq.org/attachment.cgi?id=72640 Indexer error when booting up Logos 9 with Wine 7.10. Wine 7.10, Logos 9. My indexer crashed during the initial boot up with the attached error. -- 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 (1)
-
WineHQ Bugzilla