[Bug 52635] New: WarpEM fails to process data with: internal error in the .NET Runtime at IP 00000000014B7F8A (00000000013F0000) with exit code 80131506
https://bugs.winehq.org/show_bug.cgi?id=52635 Bug ID: 52635 Summary: WarpEM fails to process data with: internal error in the .NET Runtime at IP 00000000014B7F8A (00000000013F0000) with exit code 80131506 Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: alois.schloegl(a)gmail.com Distribution: --- Created attachment 71960 --> https://bugs.winehq.org/attachment.cgi?id=71960 Screenshot with settings in WarpEM GUI Trying to do some data processing with WarpEM fails with this error: 0280:err:eventlog:ReportEventW L"Application: WarpWorker.exe\nFramework Version: v4.0.30319\nDescription: The process was terminated due to an internal error in the .NET Runtime at IP 00000000014B7F8A (00000000013F0000) with exit code 80131506.\n" In order to reproduce the issue, I did the following: * install WarpEM 1.0.9 on wine-staging 7.3/Debian10 according to https://appdb.winehq.org/objectManager.php?sClass=version&iId=40620 * Download about 50 data sets or more from http://ftp.ebi.ac.uk/empiar/world_availability/10721/data/ (the total set is 1.5TB with 2834 files, 50 are sufficient) * Start WarpEM and set "Input: directory" to local copy of th data, and set "Input: Extension" to "*.tiff". * Adapt settings in WarpEM gui according to attached screenshot (Pixel X/Y: 0.4190/0.4190, Bin:1, Exposure 1, Range 20.0-2.8, Motion 33.5-6.7, Motion Grid 6x4x70, etc.) * Click on "START PROCESSING" Then for each selected gpu, a WarpWorker (cmd) window is openend, which eventually dies, and Wine reports for each work this error: 093c:err:eventlog:ReportEventW L"Application: WarpWorker.exe\nFramework Version: v4.0.30319\nDescription: The process was terminated due to an internal error in the .NET Runtime at IP 00000000014B7F8A (00000000013F0000) with exit code 80131506.\n" Once these WarpWorker Windows closed, pressing "STOP PROCESSING" has no effect, and Warp can only be closed by closing the window, and stopping wine with <Ctrl-C> . I understand that the error code indicates a problem with memory management and garbage collection, so it might be also a bug in WarpEM. However, according to a colleague, the same procedure seem to work fine on windows. I plan to attach a log file with default WINEDEBUG. Let me know if you need further information. -- 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=52635 --- Comment #1 from Alois Schlögl <alois.schloegl(a)gmail.com> --- Created attachment 71961 --> https://bugs.winehq.org/attachment.cgi?id=71961 log file with default WINEDEBUG settings -- 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=52635 Gijs Vermeulen <gijsvrm(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Version|unspecified |7.3 Summary|WarpEM fails to process |WarpEM fails to process |data with: internal error |data |in the .NET Runtime at IP | |00000000014B7F8A | |(00000000013F0000) with | |exit code 80131506 | -- 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=52635 Gijs Vermeulen <gijsvrm(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download URL| |http://deployment.warpem.co | |m/Warp_1.0.9.msi --- Comment #2 from Gijs Vermeulen <gijsvrm(a)gmail.com> --- This might be a wine-staging only issue. From the log it seems that nvcuda is used and upstream wine doesn't have this library. I'm guessing the application doesn't function without nvcuda? In the AppDB winetricks renderer=vulkan is mentioned, but judging from your log Vulkan library fails to load, it would probably be a good idea to test without it. Does the application work with wine-mono instead of dotnet472? -- 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=52635 Alois Schlögl <alois.schloegl(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |leslie_alistair(a)hotmail.com | |, z.figura12(a)gmail.com Component|-unknown |-unknown Product|Wine |Wine-staging -- 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=52635 --- Comment #3 from Alois Schlögl <alois.schloegl(a)gmail.com> --- Created attachment 71991 --> https://bugs.winehq.org/attachment.cgi?id=71991 backtrace when using wine-mono instead of dotnet472 -- 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=52635 --- Comment #4 from Alois Schlögl <alois.schloegl(a)gmail.com> --- Yes, this is a wine-staging issue ( I changed the product flag from "wine" to "wine-staging"). It is using the GPUs for computionational purposes, using tensorflow-gpu 1.10 for windows. I tried your suggestions of using wine-mono and without vulkan. When trying to run warpem, it crashes with the attached backtrace. This was somehow expected, because warpem is using WPF (see also [1]), which does not run on mono. [1] https://github.com/cramerlab/warp -- 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=52635 --- Comment #5 from Alois Schlögl <alois.schloegl(a)gmail.com> --- Created attachment 72955 --> https://bugs.winehq.org/attachment.cgi?id=72955 output log when trying to run warp one wine-staging 7.15 with vulkan 22.1.5 -- 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=52635 --- Comment #6 from Alois Schlögl <alois.schloegl(a)gmail.com> --- Comment on attachment 72955 --> https://bugs.winehq.org/attachment.cgi?id=72955 output log when trying to run warp one wine-staging 7.15 with vulkan 22.1.5 - Debian11, cuda11.2.2, with ssh connection to the host machine - In order to address the vulkan issue, mesa 22.1.6 was compiled from source, with vulkan option, and the environment variables set - wine staging 7.15 was compiled from source - winetricks/20220411 is used to install winetricks -q wine-mono corefonts winetricks win10 winetricks-next renderer=vulkan winetricks wined3d - stack size was limited with "ulimit -s 655360" - warpem 1.0.9 was installed and than replaced with nightly build as suggested in http://www.warpem.com/warp/?page_id=65 The attached log was the output of that command: wine $WINEPREFIX/drive_c/Warp/Warp.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.
https://bugs.winehq.org/show_bug.cgi?id=52635 --- Comment #7 from Alois Schlögl <alois.schloegl(a)gmail.com> --- Created attachment 73047 --> https://bugs.winehq.org/attachment.cgi?id=73047 lastcrash.txt file generated by warpem on wine-staging/7.16 Attaches the f:\lastcrash.txt file produced warpem when trying to run it on Debian11, with gtx1080 card, wine-staging/7.16 (compiled from source) cuda/11.2.2 mesa/22.1.7 was compiled from source (as a workaround to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1007832) However, the error occurs also when running this on a local machine, when no ssh-X-tunneling is used. Interestingly, this error message is also shown in a window. This indicates that there is some progress, and it crashes now at a later stage. -- 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=52635 Alois Schlögl <alois.schloegl(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Distribution|--- |Debian --- Comment #8 from Alois Schlögl <alois.schloegl(a)gmail.com> --- Seems to be solved in wine-staging 7.17. -- 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=52635 Alois Schlögl <alois.schloegl(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Version|7.3 |7.17 Keywords|download | Resolution|--- |WORKSFORME --- Comment #9 from Alois Schlögl <alois.schloegl(a)gmail.com> --- WarpEM 1.0.9 and nightly are running just fine on Wine-staging 7.17 and 7.18. Wine-staging is needed because WarpEM is using cuda for its computations. I just watched the presentation of Zeb Figura about "Wine-Staging Update" at Wineconf 2022 (good job Zeb), and the discussion about how to get more patches from staging into mainstream wine. I'd hate if warpem would break in future, and if only for the fact that wine-staging is not maintained. Therefore, I would encourage include the nvcuda patches from staging into mainstream wine. I believe Warpem is a good example why the cuda patches from wine-staging should migrate into mainstream Wine. When the GUI starts, the upper panel shows how many gpu's have been identified. If you have multiple cuda cards in your machine, you can even select which gpu's should be used for data processing. -- 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=52635 Austin English <austinenglish(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #10 from Austin English <austinenglish(a)gmail.com> --- Closing. -- 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=52635 --- Comment #11 from Alois Schlögl <alois.schloegl(a)gmail.com> --- (In reply to Gijs Vermeulen from comment #2)
This might be a wine-staging only issue. From the log it seems that nvcuda is used and upstream wine doesn't have this library.
I'm guessing the application doesn't function without nvcuda?
In the AppDB winetricks renderer=vulkan is mentioned, but judging from your log Vulkan library fails to load, it would probably be a good idea to test without it.
Does the application work with wine-mono instead of dotnet472?
I just wanted to come back to your question about wine-mono and dotnet. When installing wine-mono 7.4.2 or 7.4.1, the installer complains that dotnet 4.7.0 or later is required, but is not available on that platform. I'm using now wine 8.7 with Wow64 wine. When installing wine-mono-7.4.1-x86.msi, the installer does not complain, and installs Warp, but Warp is crashing at startup. After installing dotnet472, Warp did start. So at the momennt wine-mono is not working for me when testing Warp. -- 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