OSLog constructor yields System.TypeInitializationException: handle is null #7959
Assignees
Milestone
Comments
spouliot
added
bug
|
sadly approved without #7141 (comment) |
|
Got an idea for a new introspection tests to run all |
spouliot
added a commit
to spouliot/xamarin-macios
that referenced
this issue
Feb 24, 2020
`Default` property was using a nil-handle which is incorrect since * we don't allow that (this is generally a bad sign) * it does not map to `OS_LOG_DEFAULT` Since `Default` was assigned in the type (static) constructor then the whole type became unusable :( Header `log.h` shows that the right definition requires us to load a field and use it. ``` define OS_LOG_DEFAULT OS_OBJECT_GLOBAL_OBJECT(os_log_t, _os_log_default) ``` While `NULL` can actually be used for disabled (not exposed) by this contradicting (nullability-wise) macro ``` define OS_LOG_DISABLED ((os_log_t _Nonnull)NULL) ``` Also adds unit tests. A more general tests for `.cctor` will be added to introspection tests in a separate PR. Fixes dotnet#7959
spouliot
added a commit
that referenced
this issue
Feb 25, 2020
`Default` property was using a nil-handle which is incorrect since * we don't allow that (this is generally a bad sign) * it does not map to `OS_LOG_DEFAULT` Since `Default` was assigned in the type (static) constructor then the whole type became unusable :( Header `log.h` shows that the right definition requires us to load a field and use it. ``` define OS_LOG_DEFAULT OS_OBJECT_GLOBAL_OBJECT(os_log_t, _os_log_default) ``` While `NULL` can actually be used for disabled (not exposed) by this contradicting (nullability-wise) macro ``` define OS_LOG_DISABLED ((os_log_t _Nonnull)NULL) ``` Also adds unit tests. A more general tests for `.cctor` will be added to introspection tests in a separate PR. Fixes #7959
spouliot
added a commit
to spouliot/xamarin-macios
that referenced
this issue
Feb 25, 2020
This will spot cases like dotnet#7959 where a type (static) constructor can fail at runtime, leading to `TypeLoadException` Ideally it's covered by it's own tests but it's better covered twice than never :)
|
Thank you @spouliot. Is there a nightly build or other installer available to try this out? |
spouliot
added a commit
to spouliot/xamarin-macios
that referenced
this issue
Feb 25, 2020
…net#7962) `Default` property was using a nil-handle which is incorrect since * we don't allow that (this is generally a bad sign) * it does not map to `OS_LOG_DEFAULT` Since `Default` was assigned in the type (static) constructor then the whole type became unusable :( Header `log.h` shows that the right definition requires us to load a field and use it. ``` define OS_LOG_DEFAULT OS_OBJECT_GLOBAL_OBJECT(os_log_t, _os_log_default) ``` While `NULL` can actually be used for disabled (not exposed) by this contradicting (nullability-wise) macro ``` define OS_LOG_DISABLED ((os_log_t _Nonnull)NULL) ``` Also adds unit tests. A more general tests for `.cctor` will be added to introspection tests in a separate PR. Fixes dotnet#7959
|
@t9mike soon but not yet. Packages are built after the PR is merged (which happened 2 hours ago). Look at the commit itself, e.g. 9a88551 for master, and (in a few hours) you'll see packages that correspond to the commit. A bit later (once the back port to d16-6 is merged) you'll have packages for d16-6 (our next public release). |
spouliot
added a commit
that referenced
this issue
Feb 25, 2020
…) (#7977) `Default` property was using a nil-handle which is incorrect since * we don't allow that (this is generally a bad sign) * it does not map to `OS_LOG_DEFAULT` Since `Default` was assigned in the type (static) constructor then the whole type became unusable :( Header `log.h` shows that the right definition requires us to load a field and use it. ``` define OS_LOG_DEFAULT OS_OBJECT_GLOBAL_OBJECT(os_log_t, _os_log_default) ``` While `NULL` can actually be used for disabled (not exposed) by this contradicting (nullability-wise) macro ``` define OS_LOG_DISABLED ((os_log_t _Nonnull)NULL) ``` Also adds unit tests. A more general tests for `.cctor` will be added to introspection tests in a separate PR. Fixes #7959
|
@spouliot I was able to use OSLog against iPhone real device OK and saw expected output in Console. With watchOS real device, I get crash. But this is unrelated to OSLog as once I disabled OSLog I still get crash. OK on simulator. I used stock Release channel everything else and installed Xamarin.iOS 13.19.0.76 package. Do I need to install other packages to try this out on watchOS? Watch extension:
|
|
@t9mike the stack trace looks related to the GC initialization (on XI side). Can you file a operate issue for this and attach the symbolicated crash report from the device (so we can see what other threads were doing). The same fix, backported to d16-6, is now available from packages inside 514991e#commitcomment-37486792 |
monojenkins
pushed a commit
to monojenkins/xamarin-macios
that referenced
this issue
Feb 26, 2020
This will spot cases like dotnet#7959 where a type (static) constructor can fail at runtime, leading to `TypeLoadException` Ideally it's covered by it's own tests but it's better covered twice than never :)
spouliot
added a commit
that referenced
this issue
Feb 26, 2020
This will spot cases like #7959 where a type (static) constructor can fail at runtime, leading to `TypeLoadException` Ideally it's covered by it's own tests but it's better covered twice than never :) On iOS 64bits [1] simulator we hit some failures [2], later, if the `.cctor` is executed. It's not a big deal to avoid those types since we it will be executed on devices later. [1] API not present on 32bits [2] Fixing the following triggers similar failures for `DCDevice` ``` ApiClassPtrTest.VerifyClassPtr: class_ptr and RegisterAttribute are different: NFCIso15693CustomCommandConfiguration Expected: 0 But was: 140735471513712 ApiSelectorTest.StaticMethods: 7 errors found in 2788 static selector validated: CoreNFC.NFCIso15693ReaderSession : readingAvailable CoreNFC.NFCNdefMessage : ndefMessageWithData: CoreNFC.NFCNdefPayload : wellKnownTypeURIPayloadWithString: CoreNFC.NFCNdefPayload : wellKnownTypeURIPayloadWithURL: CoreNFC.NFCNdefPayload : wellKnownTypeTextPayloadWithString:locale: CoreNFC.NFCNdefReaderSession : readingAvailable CoreNFC.NFCReaderSession : readingAvailable Expected: 0 But was: 7 ```
spouliot
added a commit
that referenced
this issue
Feb 26, 2020
This will spot cases like #7959 where a type (static) constructor can fail at runtime, leading to `TypeLoadException` Ideally it's covered by it's own tests but it's better covered twice than never :) On iOS 64bits [1] simulator we hit some failures [2], later, if the `.cctor` is executed. It's not a big deal to avoid those types since we it will be executed on devices later. [1] API not present on 32bits [2] Fixing the following triggers similar failures for `DCDevice` ``` ApiClassPtrTest.VerifyClassPtr: class_ptr and RegisterAttribute are different: NFCIso15693CustomCommandConfiguration Expected: 0 But was: 140735471513712 ApiSelectorTest.StaticMethods: 7 errors found in 2788 static selector validated: CoreNFC.NFCIso15693ReaderSession : readingAvailable CoreNFC.NFCNdefMessage : ndefMessageWithData: CoreNFC.NFCNdefPayload : wellKnownTypeURIPayloadWithString: CoreNFC.NFCNdefPayload : wellKnownTypeURIPayloadWithURL: CoreNFC.NFCNdefPayload : wellKnownTypeTextPayloadWithString:locale: CoreNFC.NFCNdefReaderSession : readingAvailable CoreNFC.NFCReaderSession : readingAvailable Expected: 0 But was: 7 ``` Co-authored-by: Sebastien Pouliot <[email protected]>
dalexsoto
pushed a commit
to dalexsoto/xamarin-macios
that referenced
this issue
Mar 3, 2020
`Default` property was using a nil-handle which is incorrect since * we don't allow that (this is generally a bad sign) * it does not map to `OS_LOG_DEFAULT` Since `Default` was assigned in the type (static) constructor then the whole type became unusable :( Header `log.h` shows that the right definition requires us to load a field and use it. ``` define OS_LOG_DEFAULT OS_OBJECT_GLOBAL_OBJECT(os_log_t, _os_log_default) ``` While `NULL` can actually be used for disabled (not exposed) by this contradicting (nullability-wise) macro ``` define OS_LOG_DISABLED ((os_log_t _Nonnull)NULL) ``` Also adds unit tests. A more general tests for `.cctor` will be added to introspection tests in a separate PR. Fixes dotnet#7959
ghost
locked as resolved and limited conversation to collaborators
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Steps to Reproduce
to controller's ViewDidLoad
Expected Behavior
Construct an OSLog
Actual Behavior
System.TypeInitializationException: The type initializer for 'CoreFoundation.OSLog' threw an exception. ---> System.Exception: Could not initialize an instance of the type 'CoreFoundation.OSLog': handle is null.
It is possible to ignore this condition by setting ObjCRuntime.Class.ThrowOnInitFailure to false.
at CoreFoundation.NativeObject.InitializeHandle (System.IntPtr handle) [0x00014] in /Library/Frameworks/Xamarin.iOS.framework/Versions/13.14.1.30/src/Xamarin.iOS/CoreFoundation/NativeObject.cs:74
at CoreFoundation.NativeObject.set_Handle (System.IntPtr value) [0x00000] in /Library/Frameworks/Xamarin.iOS.framework/Versions/13.14.1.30/src/Xamarin.iOS/CoreFoundation/NativeObject.cs:34
at CoreFoundation.NativeObject..ctor (System.IntPtr handle, System.Boolean owns) [0x00006] in /Library/Frameworks/Xamarin.iOS.framework/Versions/13.14.1.30/src/Xamarin.iOS/CoreFoundation/NativeObject.cs:43
at CoreFoundation.OSLog..ctor (System.IntPtr handle, System.Boolean owns) [0x00000] in /Library/Frameworks/Xamarin.iOS.framework/Versions/13.14.1.30/src/Xamarin.iOS/CoreFoundation/OSLog.cs:59
at CoreFoundation.OSLog..cctor () [0x00000] in /Library/Frameworks/Xamarin.iOS.framework/Versions/13.14.1.30/src/Xamarin.iOS/CoreFoundation/OSLog.cs:32
--- End of inner exception stack trace ---
at OSLogTest.ViewController.ViewDidLoad () [0x00008] in /Users/mmuegel/Projects/OSLogTest/ViewController.cs:19
at at (wrapper managed-to-native) UIKit.UIApplication.UIApplicationMain(int,string[],intptr,intptr)
at UIKit.UIApplication.Main (System.String[] args, System.IntPtr principal, System.IntPtr delegate) [0x00005] in /Library/Frameworks/Xamarin.iOS.framework/Versions/13.14.1.30/src/Xamarin.iOS/UIKit/UIApplication.cs:86
at UIKit.UIApplication.Main (System.String[] args, System.String principalClassName, System.String delegateClassName) [0x0000e] in /Library/Frameworks/Xamarin.iOS.framework/Versions/13.14.1.30/src/Xamarin.iOS/UIKit/UIApplication.cs:65
at OSLogTest.Application.Main (System.String[] args) [0x00001] in /Users/mmuegel/Projects/OSLogTest/Main.cs:12
Environment
Build Logs
Example Project (If Possible)
OSLogTest.zip #
The text was updated successfully, but these errors were encountered: