Bug 1734794

Summary: Segmentation fault and exceptions using ManagementClass
Product: [Fedora] Fedora Reporter: Dridi Boukelmoune <dridi.boukelmoune>
Component: wine-monoAssignee: Andreas Bierfert <andreas.bierfert>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 30CC: 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:

Description Dridi Boukelmoune 2019-07-31 13:22:51 UTC
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

Comment 1 Michael Cronenworth 2019-08-01 03:51:50 UTC
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.

Comment 2 Dridi Boukelmoune 2019-08-09 22:51:18 UTC
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.

Comment 3 Dridi Boukelmoune 2019-09-19 22:11:05 UTC
A fix landed in the development branch, I assume this will be fixed by Wine 4.16!

Comment 4 Michael Cronenworth 2019-09-19 22:43:36 UTC
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

Comment 5 Michael Cronenworth 2019-09-19 22:44:11 UTC
Do you have the commit hash of the fix?

Comment 6 Dridi Boukelmoune 2019-09-19 22:49:07 UTC
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.

Comment 7 Fedora Update System 2019-09-29 19:21:00 UTC
FEDORA-2019-b386e091c6 has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2019-b386e091c6

Comment 8 Fedora Update System 2019-09-29 19:21:40 UTC
FEDORA-2019-f5d6a80f08 has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-f5d6a80f08

Comment 9 Fedora Update System 2019-09-30 03:38:10 UTC
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

Comment 10 Fedora Update System 2019-09-30 03:45:50 UTC
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

Comment 11 Fedora Update System 2019-10-01 00:01:14 UTC
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.

Comment 12 Fedora Update System 2019-10-01 03:53:21 UTC
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.