Bug 1734794 - Segmentation fault and exceptions using ManagementClass
Summary: Segmentation fault and exceptions using ManagementClass
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: wine-mono
Version: 30
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Andreas Bierfert
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-07-31 13:22 UTC by Dridi Boukelmoune
Modified: 2019-10-01 03:53 UTC (History)
2 users (show)

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:
Clone Of:
Environment:
Last Closed: 2019-10-01 00:01:14 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Wine HQ 47782 0 None None None 2019-09-19 09:38:27 UTC

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.


Note You need to log in before you can comment on or make changes to this bug.