Re: [Mono-dev] NullReferenceException in Mono.Security.X509.X509Certificate.Hash and IsSelfSigned
The problem is confirmed Xamarin.Mac specific. And steps to reproduce are here: http://forums.xamarin.com/discussion/42318/sslstream-on-mac ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] NullReferenceException in Mono.Security.X509.X509Certificate.Hash and IsSelfSigned
The NullReference problem seems to be Xam.Mac specific. The problem doesn't happen in a console application, or even if I create a new Xam.Mac project. But my old Xam.Mac project has the problem - and I can't make any sense of it. I've trimmed down everything I can, to this example project. Simply make sure you have no mozroots rm -rf ~/.config/.mono/certs and launch the application in debug mode. https://github.com/rahvee/monobug_nullreference ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] SIGSEGV from bad generic type (bug 30085)
I don’t think the actual bug has been reported twice, just Alexander already
picked it up (maybe it’s affecting him, too). My colleague opened the bug
report because we updated the mono framework we are certifying against to
3.12.1 and this issue appeared. He said we didn’t have issues with mono
3.4.0-5, although I haven’t independently verified that.
We have several cases where we have runtime crashes with SIGSEGV, and I’m
trying to eliminate as many as I can. This seems like low hanging fruit since
it’s so easily reproducible.
On May 28, 2015, at 5:04 PM, Miguel de Icaza wrote:
> Updated the bug report.
>
> Not sure why this has all of a sudden become an issue that was reported
> twice. Do you happen to know?
>
> On Thu, May 28, 2015 at 4:29 PM, Miguel de Icaza wrote:
> Hello,
>
> There is already a similar pull request.
>
> The issue is that returning NULL there has a slightly different meaning. So
> the complete fix is to restructure some of the code.
>
> https://github.com/mono/mono/pull/1817
>
> Miguel
>
> On Thu, May 28, 2015 at 4:25 PM, David Curylo wrote:
> Found the issue and created PR 1839: https://github.com/mono/mono/pull/1839
>
> Please take a look and let me know if you have any concerns with the fix.
>
> Thanks,
> Dave
>
> On May 28, 2015, at 3:51 PM, David Curylo wrote:
>
>> I’m researching an issue reported by a colleague of mine. The error is
>> rather serious as the use of a bad type name causes a native SIGSEGV and
>> kills the runtime, when it really should just return a null because it can’t
>> find the type. This code reproduces the issue:
>>
>> System.Type.GetType("System.Nullable`1[[System.Int32, mscorlibBAD]]")
>>
>> Since I see there is some work going on with System.Type, I was hopeful that
>> mono master would no longer have this issue, but it still exists. This is
>> what I’m getting in the thread dump when this occurs and the root cause
>> appears to be somewhere in _mono_reflection_get_type_from_info. Any ideas
>> what may be the root cause here?
>>
>>
>> Thread 1 (Thread 0x7f28ae81f7c0 (LWP 76562)):
>> #0 0x7f28adcf7ee9 in __libc_waitpid (pid=pid@entry=76565,
>> stat_loc=stat_loc@entry=0x7f28ae82919c, options=options@entry=0) at
>> ../sysdeps/unix/sysv/linux/waitpid.c:40
>> #1 0x004a2015 in mono_handle_native_sigsegv
>> (signal=signal@entry=11, ctx=ctx@entry=0x7f28ae829ac0,
>> info=info@entry=0x7f28ae829bf0) at mini-exceptions.c:2226
>> #2 0x004f782e in mono_arch_handle_altstack_exception
>> (sigctx=sigctx@entry=0x7f28ae829ac0, siginfo=siginfo@entry=0x7f28ae829bf0,
>> fault_addr=, stack_ovf=stack_ovf@entry=0) at
>> exceptions-amd64.c:858
>> #3 0x00422f28 in mono_sigsegv_signal_handler (_dummy=11,
>> _info=0x7f28ae829bf0, context=0x7f28ae829ac0) at mini-runtime.c:2526
>> #4
>> #5 0x005bcb91 in _mono_reflection_get_type_from_info
>> (info=0x1efb270, image=image@entry=0x0, ignorecase=ignorecase@entry=0) at
>> reflection.c:7450
>> #6 0x005bc750 in mono_reflection_get_type_internal
>> (rootimage=rootimage@entry=0x0, image=,
>> info=info@entry=0x7fff8b7388e0, ignorecase=ignorecase@entry=0) at
>> reflection.c:7565
>> #7 0x005bc9b3 in mono_reflection_get_type_with_rootimage
>> (rootimage=rootimage@entry=0x0, image=image@entry=0x0,
>> info=info@entry=0x7fff8b7388e0, ignorecase=ignorecase@entry=0,
>> type_resolve=type_resolve@entry=0x7fff8b7388d4) at reflection.c:7661
>> #8 0x005bcb00 in mono_reflection_get_type (image=image@entry=0x0,
>> info=info@entry=0x7fff8b7388e0, ignorecase=ignorecase@entry=0,
>> type_resolve=type_resolve@entry=0x7fff8b7388d4) at reflection.c:7613
>> #9 0x0053456d in type_from_name (ignoreCase=,
>> str=0x1ef44f0 "System.Nullable`1[[System.Int32, mscorlibBAD]]") at
>> icall.c:1286
>> #10 ves_icall_type_from_name (name=0x7f28ae7981b0, throwOnError=> out>, ignoreCase=) at icall.c:1322
>>
>
>
> ___
> Mono-devel-list mailing list
> Mono-devel-list@lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
>
>
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] SIGSEGV from bad generic type (bug 30085)
Updated the bug report.
Not sure why this has all of a sudden become an issue that was reported
twice. Do you happen to know?
On Thu, May 28, 2015 at 4:29 PM, Miguel de Icaza wrote:
> Hello,
>
> There is already a similar pull request.
>
> The issue is that returning NULL there has a slightly different meaning.
> So the complete fix is to restructure some of the code.
>
> https://github.com/mono/mono/pull/1817
>
> Miguel
>
> On Thu, May 28, 2015 at 4:25 PM, David Curylo wrote:
>
>> Found the issue and created PR 1839:
>> https://github.com/mono/mono/pull/1839
>>
>> Please take a look and let me know if you have any concerns with the fix.
>>
>> Thanks,
>> Dave
>>
>> On May 28, 2015, at 3:51 PM, David Curylo wrote:
>>
>> I’m researching an issue reported by a colleague of mine. The error is
>> rather serious as the use of a bad type name causes a native SIGSEGV and
>> kills the runtime, when it really should just return a null because it
>> can’t find the type. This code reproduces the issue:
>>
>> System.Type.GetType("System.Nullable`1[[System.Int32, mscorlibBAD]]")
>>
>> Since I see there is some work going on with System.Type, I was hopeful
>> that mono master would no longer have this issue, but it still exists.
>> This is what I’m getting in the thread dump when this occurs and the root
>> cause appears to be somewhere in _mono_reflection_get_type_from_info. Any
>> ideas what may be the root cause here?
>>
>>
>> Thread 1 (Thread 0x7f28ae81f7c0 (LWP 76562)):
>> #0 0x7f28adcf7ee9 in __libc_waitpid (pid=pid@entry=76565,
>> stat_loc=stat_loc@entry=0x7f28ae82919c, options=options@entry=0) at
>> ../sysdeps/unix/sysv/linux/waitpid.c:40
>> #1 0x004a2015 in mono_handle_native_sigsegv (signal=signal@entry=11,
>> ctx=ctx@entry=0x7f28ae829ac0, info=info@entry=0x7f28ae829bf0) at
>> mini-exceptions.c:2226
>> #2 0x004f782e in mono_arch_handle_altstack_exception
>> (sigctx=sigctx@entry=0x7f28ae829ac0, siginfo=siginfo@entry=0x7f28ae829bf0,
>> fault_addr=, stack_ovf=stack_ovf@entry=0) at
>> exceptions-amd64.c:858
>> #3 0x00422f28 in mono_sigsegv_signal_handler (_dummy=11,
>> _info=0x7f28ae829bf0, context=0x7f28ae829ac0) at mini-runtime.c:2526
>> #4
>> *#5 0x005bcb91 in _mono_reflection_get_type_from_info
>> (info=0x1efb270, image=image@entry=0x0, ignorecase=ignorecase@entry=0) at
>> reflection.c:7450*
>> #6 0x005bc750 in mono_reflection_get_type_internal
>> (rootimage=rootimage@entry=0x0, image=,
>> info=info@entry=0x7fff8b7388e0,
>> ignorecase=ignorecase@entry=0) at reflection.c:7565
>> #7 0x005bc9b3 in mono_reflection_get_type_with_rootimage
>> (rootimage=rootimage@entry=0x0, image=image@entry=0x0,
>> info=info@entry=0x7fff8b7388e0,
>> ignorecase=ignorecase@entry=0,
>> type_resolve=type_resolve@entry=0x7fff8b7388d4)
>> at reflection.c:7661
>> #8 0x005bcb00 in mono_reflection_get_type (image=image@entry=0x0,
>> info=info@entry=0x7fff8b7388e0, ignorecase=ignorecase@entry=0,
>> type_resolve=type_resolve@entry=0x7fff8b7388d4) at reflection.c:7613
>> #9 0x0053456d in type_from_name (ignoreCase=,
>> str=0x1ef44f0 "System.Nullable`1[[System.Int32, mscorlibBAD]]") at
>> icall.c:1286
>> #10 ves_icall_type_from_name (name=0x7f28ae7981b0,
>> throwOnError=, ignoreCase=) at icall.c:1322
>>
>>
>>
>> ___
>> Mono-devel-list mailing list
>> Mono-devel-list@lists.ximian.com
>> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>>
>>
>
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] SIGSEGV from bad generic type (bug 30085)
Cool. I didn’t see any traffic on the bug report so didn’t know you were
already addressing this. Anything I can do to help move the other PR forward?
On May 28, 2015, at 4:29 PM, Miguel de Icaza wrote:
> Hello,
>
> There is already a similar pull request.
>
> The issue is that returning NULL there has a slightly different meaning. So
> the complete fix is to restructure some of the code.
>
> https://github.com/mono/mono/pull/1817
>
> Miguel
>
> On Thu, May 28, 2015 at 4:25 PM, David Curylo wrote:
> Found the issue and created PR 1839: https://github.com/mono/mono/pull/1839
>
> Please take a look and let me know if you have any concerns with the fix.
>
> Thanks,
> Dave
>
> On May 28, 2015, at 3:51 PM, David Curylo wrote:
>
>> I’m researching an issue reported by a colleague of mine. The error is
>> rather serious as the use of a bad type name causes a native SIGSEGV and
>> kills the runtime, when it really should just return a null because it can’t
>> find the type. This code reproduces the issue:
>>
>> System.Type.GetType("System.Nullable`1[[System.Int32, mscorlibBAD]]")
>>
>> Since I see there is some work going on with System.Type, I was hopeful that
>> mono master would no longer have this issue, but it still exists. This is
>> what I’m getting in the thread dump when this occurs and the root cause
>> appears to be somewhere in _mono_reflection_get_type_from_info. Any ideas
>> what may be the root cause here?
>>
>>
>> Thread 1 (Thread 0x7f28ae81f7c0 (LWP 76562)):
>> #0 0x7f28adcf7ee9 in __libc_waitpid (pid=pid@entry=76565,
>> stat_loc=stat_loc@entry=0x7f28ae82919c, options=options@entry=0) at
>> ../sysdeps/unix/sysv/linux/waitpid.c:40
>> #1 0x004a2015 in mono_handle_native_sigsegv
>> (signal=signal@entry=11, ctx=ctx@entry=0x7f28ae829ac0,
>> info=info@entry=0x7f28ae829bf0) at mini-exceptions.c:2226
>> #2 0x004f782e in mono_arch_handle_altstack_exception
>> (sigctx=sigctx@entry=0x7f28ae829ac0, siginfo=siginfo@entry=0x7f28ae829bf0,
>> fault_addr=, stack_ovf=stack_ovf@entry=0) at
>> exceptions-amd64.c:858
>> #3 0x00422f28 in mono_sigsegv_signal_handler (_dummy=11,
>> _info=0x7f28ae829bf0, context=0x7f28ae829ac0) at mini-runtime.c:2526
>> #4
>> #5 0x005bcb91 in _mono_reflection_get_type_from_info
>> (info=0x1efb270, image=image@entry=0x0, ignorecase=ignorecase@entry=0) at
>> reflection.c:7450
>> #6 0x005bc750 in mono_reflection_get_type_internal
>> (rootimage=rootimage@entry=0x0, image=,
>> info=info@entry=0x7fff8b7388e0, ignorecase=ignorecase@entry=0) at
>> reflection.c:7565
>> #7 0x005bc9b3 in mono_reflection_get_type_with_rootimage
>> (rootimage=rootimage@entry=0x0, image=image@entry=0x0,
>> info=info@entry=0x7fff8b7388e0, ignorecase=ignorecase@entry=0,
>> type_resolve=type_resolve@entry=0x7fff8b7388d4) at reflection.c:7661
>> #8 0x005bcb00 in mono_reflection_get_type (image=image@entry=0x0,
>> info=info@entry=0x7fff8b7388e0, ignorecase=ignorecase@entry=0,
>> type_resolve=type_resolve@entry=0x7fff8b7388d4) at reflection.c:7613
>> #9 0x0053456d in type_from_name (ignoreCase=,
>> str=0x1ef44f0 "System.Nullable`1[[System.Int32, mscorlibBAD]]") at
>> icall.c:1286
>> #10 ves_icall_type_from_name (name=0x7f28ae7981b0, throwOnError=> out>, ignoreCase=) at icall.c:1322
>>
>
>
> ___
> Mono-devel-list mailing list
> Mono-devel-list@lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
>
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] SIGSEGV from bad generic type (bug 30085)
Hello,
There is already a similar pull request.
The issue is that returning NULL there has a slightly different meaning.
So the complete fix is to restructure some of the code.
https://github.com/mono/mono/pull/1817
Miguel
On Thu, May 28, 2015 at 4:25 PM, David Curylo wrote:
> Found the issue and created PR 1839:
> https://github.com/mono/mono/pull/1839
>
> Please take a look and let me know if you have any concerns with the fix.
>
> Thanks,
> Dave
>
> On May 28, 2015, at 3:51 PM, David Curylo wrote:
>
> I’m researching an issue reported by a colleague of mine. The error is
> rather serious as the use of a bad type name causes a native SIGSEGV and
> kills the runtime, when it really should just return a null because it
> can’t find the type. This code reproduces the issue:
>
> System.Type.GetType("System.Nullable`1[[System.Int32, mscorlibBAD]]")
>
> Since I see there is some work going on with System.Type, I was hopeful
> that mono master would no longer have this issue, but it still exists.
> This is what I’m getting in the thread dump when this occurs and the root
> cause appears to be somewhere in _mono_reflection_get_type_from_info. Any
> ideas what may be the root cause here?
>
>
> Thread 1 (Thread 0x7f28ae81f7c0 (LWP 76562)):
> #0 0x7f28adcf7ee9 in __libc_waitpid (pid=pid@entry=76565,
> stat_loc=stat_loc@entry=0x7f28ae82919c, options=options@entry=0) at
> ../sysdeps/unix/sysv/linux/waitpid.c:40
> #1 0x004a2015 in mono_handle_native_sigsegv (signal=signal@entry=11,
> ctx=ctx@entry=0x7f28ae829ac0, info=info@entry=0x7f28ae829bf0) at
> mini-exceptions.c:2226
> #2 0x004f782e in mono_arch_handle_altstack_exception
> (sigctx=sigctx@entry=0x7f28ae829ac0, siginfo=siginfo@entry=0x7f28ae829bf0,
> fault_addr=, stack_ovf=stack_ovf@entry=0) at
> exceptions-amd64.c:858
> #3 0x00422f28 in mono_sigsegv_signal_handler (_dummy=11,
> _info=0x7f28ae829bf0, context=0x7f28ae829ac0) at mini-runtime.c:2526
> #4
> *#5 0x005bcb91 in _mono_reflection_get_type_from_info
> (info=0x1efb270, image=image@entry=0x0, ignorecase=ignorecase@entry=0) at
> reflection.c:7450*
> #6 0x005bc750 in mono_reflection_get_type_internal
> (rootimage=rootimage@entry=0x0, image=,
> info=info@entry=0x7fff8b7388e0,
> ignorecase=ignorecase@entry=0) at reflection.c:7565
> #7 0x005bc9b3 in mono_reflection_get_type_with_rootimage
> (rootimage=rootimage@entry=0x0, image=image@entry=0x0,
> info=info@entry=0x7fff8b7388e0,
> ignorecase=ignorecase@entry=0, type_resolve=type_resolve@entry=0x7fff8b7388d4)
> at reflection.c:7661
> #8 0x005bcb00 in mono_reflection_get_type (image=image@entry=0x0,
> info=info@entry=0x7fff8b7388e0, ignorecase=ignorecase@entry=0,
> type_resolve=type_resolve@entry=0x7fff8b7388d4) at reflection.c:7613
> #9 0x0053456d in type_from_name (ignoreCase=,
> str=0x1ef44f0 "System.Nullable`1[[System.Int32, mscorlibBAD]]") at
> icall.c:1286
> #10 ves_icall_type_from_name (name=0x7f28ae7981b0, throwOnError= out>, ignoreCase=) at icall.c:1322
>
>
>
> ___
> Mono-devel-list mailing list
> Mono-devel-list@lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
>
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] SIGSEGV from bad generic type (bug 30085)
Found the issue and created PR 1839: https://github.com/mono/mono/pull/1839
Please take a look and let me know if you have any concerns with the fix.
Thanks,
Dave
On May 28, 2015, at 3:51 PM, David Curylo wrote:
> I’m researching an issue reported by a colleague of mine. The error is
> rather serious as the use of a bad type name causes a native SIGSEGV and
> kills the runtime, when it really should just return a null because it can’t
> find the type. This code reproduces the issue:
>
> System.Type.GetType("System.Nullable`1[[System.Int32, mscorlibBAD]]")
>
> Since I see there is some work going on with System.Type, I was hopeful that
> mono master would no longer have this issue, but it still exists. This is
> what I’m getting in the thread dump when this occurs and the root cause
> appears to be somewhere in _mono_reflection_get_type_from_info. Any ideas
> what may be the root cause here?
>
>
> Thread 1 (Thread 0x7f28ae81f7c0 (LWP 76562)):
> #0 0x7f28adcf7ee9 in __libc_waitpid (pid=pid@entry=76565,
> stat_loc=stat_loc@entry=0x7f28ae82919c, options=options@entry=0) at
> ../sysdeps/unix/sysv/linux/waitpid.c:40
> #1 0x004a2015 in mono_handle_native_sigsegv (signal=signal@entry=11,
> ctx=ctx@entry=0x7f28ae829ac0, info=info@entry=0x7f28ae829bf0) at
> mini-exceptions.c:2226
> #2 0x004f782e in mono_arch_handle_altstack_exception
> (sigctx=sigctx@entry=0x7f28ae829ac0, siginfo=siginfo@entry=0x7f28ae829bf0,
> fault_addr=, stack_ovf=stack_ovf@entry=0) at
> exceptions-amd64.c:858
> #3 0x00422f28 in mono_sigsegv_signal_handler (_dummy=11,
> _info=0x7f28ae829bf0, context=0x7f28ae829ac0) at mini-runtime.c:2526
> #4
> #5 0x005bcb91 in _mono_reflection_get_type_from_info
> (info=0x1efb270, image=image@entry=0x0, ignorecase=ignorecase@entry=0) at
> reflection.c:7450
> #6 0x005bc750 in mono_reflection_get_type_internal
> (rootimage=rootimage@entry=0x0, image=,
> info=info@entry=0x7fff8b7388e0, ignorecase=ignorecase@entry=0) at
> reflection.c:7565
> #7 0x005bc9b3 in mono_reflection_get_type_with_rootimage
> (rootimage=rootimage@entry=0x0, image=image@entry=0x0,
> info=info@entry=0x7fff8b7388e0, ignorecase=ignorecase@entry=0,
> type_resolve=type_resolve@entry=0x7fff8b7388d4) at reflection.c:7661
> #8 0x005bcb00 in mono_reflection_get_type (image=image@entry=0x0,
> info=info@entry=0x7fff8b7388e0, ignorecase=ignorecase@entry=0,
> type_resolve=type_resolve@entry=0x7fff8b7388d4) at reflection.c:7613
> #9 0x0053456d in type_from_name (ignoreCase=,
> str=0x1ef44f0 "System.Nullable`1[[System.Int32, mscorlibBAD]]") at
> icall.c:1286
> #10 ves_icall_type_from_name (name=0x7f28ae7981b0, throwOnError= out>, ignoreCase=) at icall.c:1322
>
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] SIGSEGV from bad generic type (bug 30085)
I’m researching an issue reported by a colleague of mine. The error is rather
serious as the use of a bad type name causes a native SIGSEGV and kills the
runtime, when it really should just return a null because it can’t find the
type. This code reproduces the issue:
System.Type.GetType("System.Nullable`1[[System.Int32, mscorlibBAD]]")
Since I see there is some work going on with System.Type, I was hopeful that
mono master would no longer have this issue, but it still exists. This is what
I’m getting in the thread dump when this occurs and the root cause appears to
be somewhere in _mono_reflection_get_type_from_info. Any ideas what may be the
root cause here?
Thread 1 (Thread 0x7f28ae81f7c0 (LWP 76562)):
#0 0x7f28adcf7ee9 in __libc_waitpid (pid=pid@entry=76565,
stat_loc=stat_loc@entry=0x7f28ae82919c, options=options@entry=0) at
../sysdeps/unix/sysv/linux/waitpid.c:40
#1 0x004a2015 in mono_handle_native_sigsegv (signal=signal@entry=11,
ctx=ctx@entry=0x7f28ae829ac0, info=info@entry=0x7f28ae829bf0) at
mini-exceptions.c:2226
#2 0x004f782e in mono_arch_handle_altstack_exception
(sigctx=sigctx@entry=0x7f28ae829ac0, siginfo=siginfo@entry=0x7f28ae829bf0,
fault_addr=, stack_ovf=stack_ovf@entry=0) at
exceptions-amd64.c:858
#3 0x00422f28 in mono_sigsegv_signal_handler (_dummy=11,
_info=0x7f28ae829bf0, context=0x7f28ae829ac0) at mini-runtime.c:2526
#4
#5 0x005bcb91 in _mono_reflection_get_type_from_info (info=0x1efb270,
image=image@entry=0x0, ignorecase=ignorecase@entry=0) at reflection.c:7450
#6 0x005bc750 in mono_reflection_get_type_internal
(rootimage=rootimage@entry=0x0, image=,
info=info@entry=0x7fff8b7388e0, ignorecase=ignorecase@entry=0) at
reflection.c:7565
#7 0x005bc9b3 in mono_reflection_get_type_with_rootimage
(rootimage=rootimage@entry=0x0, image=image@entry=0x0,
info=info@entry=0x7fff8b7388e0, ignorecase=ignorecase@entry=0,
type_resolve=type_resolve@entry=0x7fff8b7388d4) at reflection.c:7661
#8 0x005bcb00 in mono_reflection_get_type (image=image@entry=0x0,
info=info@entry=0x7fff8b7388e0, ignorecase=ignorecase@entry=0,
type_resolve=type_resolve@entry=0x7fff8b7388d4) at reflection.c:7613
#9 0x0053456d in type_from_name (ignoreCase=,
str=0x1ef44f0 "System.Nullable`1[[System.Int32, mscorlibBAD]]") at icall.c:1286
#10 ves_icall_type_from_name (name=0x7f28ae7981b0, throwOnError=, ignoreCase=) at icall.c:1322
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Timing/race conditions
I'm not keen on introducing yield calls all over the place in the runtime
to work around bad test-environment combinations.
Adding them to the test suite it fine though.
Maybe the 200ms timeout is too low to deal with overloaded systems and must
be increased. The goal is to
detect bugs in the suspend code.
It would be much easier if unix had a way to transfer the quantum in a
yield call instead of just giving up on it.
We can definitely increase the timeout if that would help or make it
optional guarded behind an env var.
Does changing the timeout to infinite fix those crashes?
On Thu, May 21, 2015 at 4:20 PM, Neale Ferguson
wrote:
> Hi,
> I have been experiencing some failures with the tests in mono/tests,
> particularly in a single core configuration.
>
> Firstly, the sleep test: when the delegated thread is started, the main
> thread goes to call the StopWatch start method which requires JITting.
> This involves gc interaction as objects are allocated. However, the
> delegated thread gets up and starts issuing GC.Collection() calls which
> end up occurring every 50 microseconds. This means the main thread never
> gets a chance to get out of the allocation phase so never gets to execute
> the stopwatch start, thread sleep etc. so the thread never ends. In a
> multi-core configuration this is not a problem and the test passes. I
> found by inserting a Thread.Yield() as the first method called in the
> delegated thread eliminates the problem [1].
>
> Secondly, the x-exit (e.g. thread-exit) tests will occasionally fail
> with an abort due to "suspend_thread suspend took xxx ms, which is more
> than the allowed 200 ms” where xxx exceeds 200. This seems to be due to
> the exiting thread sometimes not getting to the stage of setting the
> thread->state to ThreadState_Stopped in the
> ves_icall_System_Environment_Exit() processing within the 200ms time
> period. Again, with multiple cores this is not a problem (or the problem
> is much rarer). I found by inserting a mono_thread_info_yield() prior to
> the suspend_internal_thread() in mono_thread_suspend_all_other_threads()
> fixes the problem [2]. I am not sure this is the best option and it’s
> still theoretically possible for the problem to still occur depending on
> how heavily the system is loaded. I was wondering if the setting of the
> state to ThreadState_stopped could be moved earlier in the process rather
> than in thread_cleanup() or if there’s another alternative.
>
> While the occasional failure has been experienced with some of the more
> pathological tests, the trouble is they happen nearly 100% of the time on
> a single core virtual machine, less often on a 2 core but in a virtual
> machine environment where there may be 100s of virtual machines competing
> for the real cores the probability of failure increases. In addition tests
> in the main test suite also have failed for the same reason as described
> in the second case.
>
> Neale
>
> [1] Circumvention for case 1 -
>
> --- a/mono/tests/sleep.cs
> +++ b/mono/tests/sleep.cs
> @@ -13,6 +13,7 @@ public class Tests
> public static int test_0_time_drift () {
> // Test the Thread.Sleep () is able to deal with time
> drifting due to interrupts
> Thread t = new Thread (delegate () {
> + Thread.Yield();
> while (!finished)
> GC.Collect ();
> });
>
> [2] Circumvention for case 2 -
>
> --- a/mono/metadata/threads.c
> +++ b/mono/metadata/threads.c
>
> @@ -3132,6 +3147,8 @@ void mono_thread_suspend_all_other_threads (void)
>
> UNLOCK_THREAD (thread);
>
> + mono_thread_info_yield ();
> +
> /* Signal the thread to suspend */
> suspend_thread_internal (thre
>
> ___
> Mono-devel-list mailing list
> Mono-devel-list@lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] do_rehash race
Good catch!
That's indeed a bug.
On Thu, May 28, 2015 at 2:35 PM, Neale Ferguson
wrote:
> Hi,
> When a hash table exceeds a threshold a rehash operation is triggered. At
> the moment the new table is allocated and its address placed in the table
> field of the structure. The do_rehash also then copies the entries from
> the old table to the new. However, if there is another thread active that
> is doing lookups then there is a window where the new table is still being
> filled such that a lookup can fail. This is because the new table is made
> active before it has been copied. This proposed patch will fill the new
> table before swapping the old for the new table in the hash structure.
>
> Neale
>
> @@ -194,24 +196,24 @@ do_rehash (void *_data)
> Slot **table;
>
> /* printf ("Resizing diff=%d slots=%d\n", hash->in_use -
> hash->last_rehash, hash->table_size); */
> - hash->last_rehash = hash->table_size;
> current_size = hash->table_size;
> - hash->table_size = data->new_size;
> /* printf ("New size: %d\n", hash->table_size); */
> table = hash->table;
> - hash->table = data->table;
>
> for (i = 0; i < current_size; i++){
> Slot *s, *next;
>
> for (s = table [i]; s != NULL; s = next){
> - guint hashcode = ((*hash->hash_func) (s->key)) %
> hash->table_size;
> + guint hashcode = ((*hash->hash_func) (s->key)) %
> data->new_size;
> next = s->next;
>
> - s->next = hash->table [hashcode];
> - hash->table [hashcode] = s;
> + s->next = data->table [hashcode];
> + data->table [hashcode] = s;
> }
> }
> + hash->table_size = data->new_size;
> + hash->last_rehash = hash->table_size;
> + hash->table = data->table;
> return table;
> }
>
>
> Neale
>
> ___
> Mono-devel-list mailing list
> Mono-devel-list@lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] do_rehash race
Hi,
When a hash table exceeds a threshold a rehash operation is triggered. At
the moment the new table is allocated and its address placed in the table
field of the structure. The do_rehash also then copies the entries from
the old table to the new. However, if there is another thread active that
is doing lookups then there is a window where the new table is still being
filled such that a lookup can fail. This is because the new table is made
active before it has been copied. This proposed patch will fill the new
table before swapping the old for the new table in the hash structure.
Neale
@@ -194,24 +196,24 @@ do_rehash (void *_data)
Slot **table;
/* printf ("Resizing diff=%d slots=%d\n", hash->in_use -
hash->last_rehash, hash->table_size); */
- hash->last_rehash = hash->table_size;
current_size = hash->table_size;
- hash->table_size = data->new_size;
/* printf ("New size: %d\n", hash->table_size); */
table = hash->table;
- hash->table = data->table;
for (i = 0; i < current_size; i++){
Slot *s, *next;
for (s = table [i]; s != NULL; s = next){
- guint hashcode = ((*hash->hash_func) (s->key)) %
hash->table_size;
+ guint hashcode = ((*hash->hash_func) (s->key)) %
data->new_size;
next = s->next;
- s->next = hash->table [hashcode];
- hash->table [hashcode] = s;
+ s->next = data->table [hashcode];
+ data->table [hashcode] = s;
}
}
+ hash->table_size = data->new_size;
+ hash->last_rehash = hash->table_size;
+ hash->table = data->table;
return table;
}
Neale
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] threads.o : fatal error: error in backend: unsupported symbol modifier in relocation
I tried to compile from the tarball (mono-3.2.0.tar.bz2) and got the same results on OS-X. Is this a tool dependency related error? Is there at list of tool versions that are required to build 3.2.x on OS-X? The OS-X Compile page lists autoconf/automake/libtool/m4 with versions. Are there different tool dep list for each mono version? What about clang/llvm version issues? Thanks for any help on this. > From: sushihango...@outlook.com > To: mono-devel-list@lists.ximian.com > Date: Wed, 27 May 2015 13:22:31 -0700 > Subject: [Mono-dev] threads.o : fatal error: error in backend: unsupported > symbol modifier in relocation > > I am trying to compile version 3.2.0 of mono for a compliance review on OS-X > (git checkout mono-3.2.0) and I'm receiving a fatal error on threads.o and > domain.o during the 'make' run. Diving into libmonoruntime_la-threads.lo > and/or libmonoruntime_la-domain.lo, I am getting a clang/llvm fatal error of > "error in backend: unsupported symbol modifier in relocation". I've also > tried checking out git tags 3.2.1, 3.2.3, etc.. and the same error occurs, > Also tried x32 vs x64 builds, same error. FYI: building the latest 4.x > branches/tags work fine. > > Anyone help point me in the right direction on this as I need to reproduce > 3.2 builds before migrating this project code base to the 4.x line. > > Thanks in advance. > > > git checkout mono-3.2.0 > ./autogen.sh --prefix=/Users/administrator/mono32-install --disable-nls > make (make -k) > ... > CC libmonoruntime_la-threads.lo > make: *** [libmonoruntime_la-threads.lo] Error 1 > ... > CC libmonoruntime_la-domain.lo > make: *** [libmonoruntime_la-domain.lo] Error 1 > ... > > > make threads.o > CC threads.o > fatal error: error in backend: unsupported symbol modifier in relocation > make: *** [threads.o] Error 1 > > make domain.o > CC domain.o > fatal error: error in backend: unsupported symbol modifier in relocation > make: *** [domain.o] Error 1 > > > cd mono/metadata/ > make -n threads.o > echo " CC " threads.o;gcc -DHAVE_CONFIG_H -I. -I../.. -I../.. -I../../mono > -I../../libgc/include -I../../eglib/src -I../../eglib/src > -DMONO_BINDIR=\"/Users/administrator/mono32-install/bin/\" > -DMONO_ASSEMBLIES=\"/Users/administrator/mono32-install/lib\" > -DMONO_CFG_DIR=\"/Users/administrator/mono32-install/etc\" -no-cpp-precomp > -D_THREAD_SAFE -DGC_MACOSX_THREADS -DPLATFORM_MACOSX -DUSE_MMAP -DUSE_MUNMAP > -DGetCurrentProcess=MonoGetCurrentProcess > -DGetCurrentThread=MonoGetCurrentThread -DCreateEvent=MonoCreateEvent > -DUSE_COMPILER_TLS -g -O2 -fno-strict-aliasing -Wdeclaration-after-statement > -g -Wall -Wunused -Wmissing-prototypes -Wmissing-declarations > -Wstrict-prototypes -Wmissing-prototypes -Wnested-externs -Wpointer-arith > -Wno-cast-qual -Wwrite-strings -Wno-switch -Wno-switch-enum -Wno-unused-value > -Qunused-arguments -Wno-unused-function -Wno-tautological-compare > -Werror-implicit-function-declaration -MT threads.o -MD -MP -MF > .deps/threads.Tpo -c -o threads.o threads.c > mv -f .deps/threads.Tpo .deps/threads.Po > > > gcc --version > Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr > --with-gxx-include-dir=/usr/include/c++/4.2.1 > Apple LLVM version 6.1.0 (clang-602.0.53) (based on LLVM 3.6.0svn) > Target: x86_64-apple-darwin14.3.0 > Thread model: posix > > > > ___ > Mono-devel-list mailing list > Mono-devel-list@lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] NullReferenceException in Mono.Security.X509.X509Certificate.Hash and IsSelfSigned
Recently, I'm encountering a problem where Mozroots is throwing
NullReferenceException. I am working on a reproducible example, but until then,
I'd like to revisit this issue:
First, here is reproduction code that shows the mac client requires mozroots to
be run. This code throws exception on a pristine mac, but succeeds after
mozroots has been run:
const string hostname = "google.com";
const int PortNumber = 443;
TcpClient client = new TcpClient();
client.Connect(hostname, PortNumber);
using (var mySslStream = new SslStream (client.GetStream (),
leaveInnerStreamOpen: false)) {
mySslStream.AuthenticateAsClient (targetHost: hostname, clientCertificates:
null, enabledSslProtocols: SslProtocols.Tls, checkCertificateRevocation: false);
}
Given that the above throws exception, I'd like to ask, are there plans to make
the SslStream client on mac utilize the system keychain, and if so, how soon
might we expect it? The way things are now, we have to bundle a copy of
Mozroots in our app, and programmatically call it. I would love to eliminate
the need for this.
Right now, MozRoots is throwing the NullReferenceException on this line:
https://github.com/mosa/Mono-Class-Libraries/blob/master/mcs/tools/security/mozroots.cs#L158
if (!trusted.Contains (root)) {
When I debug and step through, I can see "root" is a
Mono.Security.X509.X509Certificate, where Hash and IsSelfSigned both throw
NullReferenceException if they're accessed.
System.NullReferenceException: Object reference not set to an instance of an
object
at Mono.Security.X509.X509Certificate.get_Hash () [0x00057] in
/private/tmp/source-mono-mac-4.0.0-branch/bockbuild-mono-4.0.0-branch/profiles/mono-mac-xamarin/build-root/mono-4.0.0/mcs/class/Mono.Security/Mono.Security.X509/X509Certificate.cs:301
at Mono.Security.X509.X509CertificateCollection.IndexOf
(Mono.Security.X509.X509Certificate value) [0x00011] in
/private/tmp/source-mono-mac-4.0.0-branch/bockbuild-mono-4.0.0-branch/profiles/mono-mac-xamarin/build-root/mono-4.0.0/mcs/class/Mono.Security/Mono.Security.X509/X509CertificateCollection.cs:123
at Mono.Security.X509.X509CertificateCollection.Contains
(Mono.Security.X509.X509Certificate value) [0x0] in
/private/tmp/source-mono-mac-4.0.0-branch/bockbuild-mono-4.0.0-branch/profiles/mono-mac-xamarin/build-root/mono-4.0.0/mcs/class/Mono.Security/Mono.Security.X509/X509CertificateCollection.cs:95
For reasons that I don't yet understand, this exception occurs when we call the
MozRoots class in our app, but does not occur when I run "mozroots" command on
the Terminal. So I'm still figuring this out and have not yet got example code
to reproduce the issue.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Mono build issue: mono-sgen illegal instruction
I;m building mono on android, and while I've finally managed to get make to finish without errors, 'make check' always fails at the same point...no matter what ./configure I use: make[3]: Entering directory `/bld/mono/mono-4.0.0/mono/mini' make check-local make[4]: Entering directory `/bld/mono/mono-4.0.0/mono/mini' MONO_PATH=/bld/mono/mono-4.0.0/mcs/class/lib/net_4_5 ../../runtime/mono-wrapper /bld/mono/mono-4.0.0/mcs/class/lib/build/mcs.exe -unsafe -nowarn:0162 -out:TestDriver.dll -target:library TestDriver.cs make[4]: *** [TestDriver.dll] Illegal instruction make[4]: Leaving directory `/bld/mono/mono-4.0.0/mono/mini' make[3]: *** [check-am] Error 2 addr2line output on the debug output from logcat /bld/mono/mono-4.0.0 $ addr2line -C -i -e mono/mini/mono-sgen 00159464 /bld/mono/mono-4.0.0/mono/mini/dwarfwriter.c:967 Is there a way to disable whatever component uses dwarfwriter? I've disabled both debug and soft_debug...no dice. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
