Bug 1734794
| Summary: | Segmentation fault and exceptions using ManagementClass | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Dridi Boukelmoune <dridi.boukelmoune> |
| Component: | wine-mono | Assignee: | Andreas Bierfert <andreas.bierfert> |
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 30 | CC: | andreas.bierfert, mike |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | wine-mono-4.9.3-1.fc31 wine-mono-4.9.3-1.fc30 | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2019-10-01 00:01:14 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
I would suggest contacting upstream about your issue. Upstream doesn't have a bugzilla. You must send a message to the wine-devel mailing list. The mono maintainers should reply there. I started following your advice and got my first trivial patch upstream: https://source.winehq.org/git/wine.git/commit/0fca739770492ad94f687a9c5d51879b3aa5ef6c For this bug report I managed to get a much better backtrace for the segfault by compiling the master branch without optimizations, similar to how the wine RPM is ./configure'd: =>0 0x0000000067750c24 build_classname+0x14() [dlls\wbemprox\query.c:520] in wbemprox (0x000000000024ea80) 1 0x0000000067750fb0 build_relpath+0x40() [dlls\wbemprox\query.c:590] in wbemprox (0x000000000024eb10) 2 0x000000006775112d build_path+0x92() [dlls\wbemprox\query.c:614] in wbemprox (0x000000000024eb90) 3 0x0000000067751423 get_system_propval+0x15c() [wine\dlls\wbemprox\query.c:703] in wbemprox (0x000000000024ebd0) 4 0x000000006775197f get_propval+0x5c() [dlls\wbemprox\query.c:849] in wbemprox (0x000000000024ec50) 5 0x000000006774ae10 class_object_Get+0x1a9() [dlls\wbemprox\class.c:422] in wbemprox (0x000000000024ece0) 0x0000000067750c24 build_classname+0x14 [dlls\wbemprox\query.c:520] in wbemprox: movq (%rax),%rax 520 return SysAllocString( view->table->name ); Where view->table is null, so dereferencing view->table->name triggers the segmentation fault. Trying the master branch today, I still get a crash, but somewhere else: =>0 0x0000000067750bc4 build_servername+0x3d() [dlls\wbemprox\query.c:513] in wbemprox (0x000000000024ea80) 1 0x0000000067750f50 count_key_columns+0x3f() [dlls\wbemprox\query.c:577] in wbemprox (0x000000000024eb10) 0x0000000067750bc4 build_servername+0x3d [dlls\wbemprox\query.c:513] in wbemprox: movq (%rax),%rax 513 if (!(GetComputerNameW( server, &len ))) return NULL; I still haven't found how to print a local variable with winedbg or how to debug wine programs with gdb, so debugging is still quite tedious. Interestingly with the update to wine-4.13-3.fc30 I get a much more promising backtrace: Backtrace: =>0 0x6794e52e in wbemprox (+0xe52e) (0x0014fa90) 1 0x679504ea in wbemprox (+0x104e9) (0x0014fa90) 2 0x67949d20 EntryPoint+0x890f() in wbemprox (0x0014fab8) 3 0x0ac72c4a (0x0034f588) 4 0x0ac72b80 (0x0034f5b8) 5 0x0ac71d7c (0x0034f5f8) 6 0x0ac71814 (0x0034f628) 7 0x0ac71714 (0x0034f668) 8 0x0aa00c7c (0x0034f748) 9 0x0ac45d76 (0x0034f778) 10 0x0ac45c64 (0x0034f7c8) 11 0x0aa0032c (0x0034f838) 12 0x0aa0018c (0x0034f858) 13 0x0aa00134 (0x0034f888) 14 0x01da0db8 (0x0034f908) 15 0x01da11ad (0x0034f950) 16 0x6c54c5ee mono_jit_runtime_invoke+0x46d(exc=<is not available>) [Z:\vagrant\mono\mono\mini\mini-runtime.c:3184] in libmono-2.0-x86 (0x00417f80) 17 0x6c71d252 object_new_handle_common_tail+0x1d1(o=<is not available>, klass=<is not available>, error=<is not available>) [Z:\vagrant\mono\mono\metadata\object.c:3029] in libmono-2.0-x86 (0x00000000) 18 0x6c7218c3 mono_runtime_object_init+0xb2() [Z:\vagrant\mono\mono\metadata\object.c:5158] in libmono-2.0-x86 (0x00000000) 19 0x6c5a33b2 mono_jit_exec+0x191() [Z:\vagrant\mono\mono\mini\driver.c:1325] in libmono-2.0-x86 (0x00000000) 20 0x643c965d EntryPoint+0x824c() in mscoree (0x6c6e58f0) 21 0x7b4815b9 call_process_entry+0x18() in kernel32 (0x0034ff48) 22 0x7b484533 TerminateProcess+0x1c2() in kernel32 (0x0034ffd8) 23 0x7b4815ca call_process_entry+0x29() in kernel32 (0x0034ffec) 0x6794e52e: movl 0x0(%eax),%eax And yet when I compiled the master branch without optimizations I got the usual limited backtrace. The plot thickens... Meanwhile feel free to close this ticket, I will keep digging and report anything relevant upstream (quite the moving target). Since we are currently tracking staging releases, I will open a ticket in this tracker if I find a patch worthy of shipping. A fix landed in the development branch, I assume this will be fixed by Wine 4.16! 4.16 has already been released so you'll need to wait until 4.17. F30 4.16 update: https://bodhi.fedoraproject.org/updates/FEDORA-2019-1768be04d6 Do you have the commit hash of the fix? You're right, I didn't even notice 4.16... There is a patch for the segfault (58572fc916ecbd6ae77f2b181f51daf4169dcef1) and one for the .NET exceptions (34bd6a9cf3b3b40ebb81dab423d2d740e2ad9ac4). Since I'm the only one apparently running into this bug, don't worry about back-porting them if they don't apply out of the box. FEDORA-2019-b386e091c6 has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2019-b386e091c6 FEDORA-2019-f5d6a80f08 has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-f5d6a80f08 wine-4.17-2.fc30, wine-mono-4.9.3-1.fc30 has been pushed to the Fedora 30 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-f5d6a80f08 wine-4.17-2.fc31, wine-mono-4.9.3-1.fc31 has been pushed to the Fedora 31 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-b386e091c6 wine-4.17-2.fc31, wine-mono-4.9.3-1.fc31 has been pushed to the Fedora 31 stable repository. If problems still persist, please make note of it in this bug report. wine-4.17-2.fc30, wine-mono-4.9.3-1.fc30 has been pushed to the Fedora 30 stable repository. If problems still persist, please make note of it in this bug report. |
Description of problem: Running pure C# code compiled with mono I get exceptions and a SIGSEGV, and according to the stack traces my code is likely not responsible. This only happens in Wine since mono itself raises NotImplementedException everywhere in ManagementClass. Version-Release number of selected component (if applicable): wine-4.12.1-1.fc30.x86_64 wine-mono-4.9.0-1.fc30.noarch mono-core-5.18.1-7.fc30.x86_64 mono-devel-5.18.1-7.fc30.x86_64 mono-extras-5.18.1-7.fc30.x86_64 Let me know if other packages are relevant. Steps to Reproduce: I wrote this small program: $ cat test.cs using System; using System.Management; class Test { static void Main(string[] args) { ManagementClass mc = new ManagementClass(args[0]); ManagementObjectCollection moc = mc.GetInstances(); foreach (ManagementObject mo in moc) { Console.Write("{0}\n", mo); foreach (PropertyData pd in mo.Properties) Console.Write("\t{0} => {1}\n", pd.Name, pd.Value); } moc.Dispose(); mc.Dispose(); } } Compiled this way: $ mcs /reference:System.Management.dll test.cs And then run it with wine: $ ./test.exe $MANAGEMENT_PATH Actual results: I tested a few paths, most of them fail one way or another. OK: Win32_OperatingSystem Win32_PhysicalMemory Win32_SoundDevice Not OK: Win32_Processor (System.InvalidCastException) Win32_DisplayControllerConfiguration (SIGSEGV) Win32_VideoController (System.InvalidCastException) Win32_DesktopMonitor (System.InvalidCastException) Additional info: Below is an output example, sanitized from wine and mono additional output: === $ ./test.exe Win32_Processor \\3UFJGV4MFR2MP6B\ROOT\CIMV2:Win32_Processor.DeviceId="CPU0" AddressWidth => 64 Architecture => 9 Caption => Intel64 [redacted] Unhandled Exception: System.InvalidCastException: Specified cast is not valid. at System.Management.PropertyData.MapWmiValueToValue (System.Object wmiValue, System.Management.CimType type, System.Boolean isArray) [0x00255] in <7e819c44adfd4186960231b9690f5598>:0 at System.Management.PropertyData.get_Value () [0x00006] in <7e819c44adfd4186960231b9690f5598>:0 at Test.Main (System.String[] args) [0x0005a] in <5b3601029751436788c6cb2e6822444b>:0 === The exception is raised deeper than the Main() function, so I assume this is not a bug in the code snippet. The segmentation fault is definitely standing out here. There may be other management paths to cover, but since I'm neither a C# developer nor a Windows user, I don't know. I wrote the reproducer because a larger program ran into this and I was able to narrow it down. I don't know how to run an interactive debugger with Mono, inside or outside Wine, so I find it hard to research further. Please note that working paths lead to multiple lines in the output: /builddir/build/BUILD/wine-mono-4.9.0/mono/mono/eglib/ghashtable.c:326: assertion 'hash != NULL' failed