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@winehq.org Reporter: galanlama@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.
https://bugs.winehq.org/show_bug.cgi?id=50227
Frank franksauer@cox.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |franksauer@cox.net
--- Comment #1 from Frank franksauer@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.
https://bugs.winehq.org/show_bug.cgi?id=50227
Anastasius Focht focht@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@gmx.net Keywords| |dotnet, download
--- Comment #2 from Anastasius Focht focht@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
https://bugs.winehq.org/show_bug.cgi?id=50227
--- Comment #3 from Frank franksauer@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
https://bugs.winehq.org/show_bug.cgi?id=50227
--- Comment #4 from Anastasius Focht focht@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
https://bugs.winehq.org/show_bug.cgi?id=50227
--- Comment #5 from Frank franksauer@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.
https://bugs.winehq.org/show_bug.cgi?id=50227
Anastasius Focht focht@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@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
https://bugs.winehq.org/show_bug.cgi?id=50227
--- Comment #7 from Frank franksauer@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"
https://bugs.winehq.org/show_bug.cgi?id=50227
--- Comment #8 from Frank franksauer@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.
https://bugs.winehq.org/show_bug.cgi?id=50227
--- Comment #9 from Anastasius Focht focht@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
https://bugs.winehq.org/show_bug.cgi?id=50227
--- Comment #10 from Frank franksauer@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
https://bugs.winehq.org/show_bug.cgi?id=50227
--- Comment #11 from Frank franksauer@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
https://bugs.winehq.org/show_bug.cgi?id=50227
--- Comment #12 from Frank franksauer@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
https://bugs.winehq.org/show_bug.cgi?id=50227
--- Comment #13 from Anastasius Focht focht@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
https://bugs.winehq.org/show_bug.cgi?id=50227
--- Comment #14 from Frank franksauer@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.
https://bugs.winehq.org/show_bug.cgi?id=50227
--- Comment #15 from Frank franksauer@cox.net --- Created attachment 69388 --> https://bugs.winehq.org/attachment.cgi?id=69388 Indexer run with WINEDEBUG=+relay
https://bugs.winehq.org/show_bug.cgi?id=50227
--- Comment #16 from Frank franksauer@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.
https://bugs.winehq.org/show_bug.cgi?id=50227
--- Comment #17 from Frank franksauer@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.
https://bugs.winehq.org/show_bug.cgi?id=50227
m0rvj johnpgoodman@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |johnpgoodman@gmail.com
--- Comment #18 from m0rvj johnpgoodman@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.
https://bugs.winehq.org/show_bug.cgi?id=50227
--- Comment #19 from m0rvj johnpgoodman@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?
https://bugs.winehq.org/show_bug.cgi?id=50227
--- Comment #20 from m0rvj johnpgoodman@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!
https://bugs.winehq.org/show_bug.cgi?id=50227
--- Comment #21 from m0rvj johnpgoodman@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.
https://bugs.winehq.org/show_bug.cgi?id=50227
--- Comment #22 from m0rvj johnpgoodman@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
https://bugs.winehq.org/show_bug.cgi?id=50227
--- Comment #23 from m0rvj johnpgoodman@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.
https://bugs.winehq.org/show_bug.cgi?id=50227
--- Comment #24 from m0rvj johnpgoodman@gmail.com --- Is it in fact a duplicate of https://bugs.winehq.org/show_bug.cgi?id=47277#c9
https://bugs.winehq.org/show_bug.cgi?id=50227
--- Comment #25 from m0rvj johnpgoodman@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.
https://bugs.winehq.org/show_bug.cgi?id=50227
--- Comment #26 from m0rvj johnpgoodman@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
https://bugs.winehq.org/show_bug.cgi?id=50227
--- Comment #27 from m0rvj johnpgoodman@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
https://bugs.winehq.org/show_bug.cgi?id=50227
Louis Lenders xerox.xerox2000x@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |xerox.xerox2000x@gmail.com Status|NEEDINFO |NEW
--- Comment #28 from Louis Lenders xerox.xerox2000x@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
https://bugs.winehq.org/show_bug.cgi?id=50227
Jactry Zeng jactry92@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jactry92@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=50227
--- Comment #29 from Ken Sharp imwellcushtymelike@gmail.com --- Please retry in Wine 7.9 (or later).
https://bugs.winehq.org/show_bug.cgi?id=50227
T. H. Wright thwright@thwright.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |thwright@thwright.com
--- Comment #30 from T. H. Wright thwright@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.
-
WineHQ Bugzilla