Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

GetCustomAttributes on a type from an assembly in the LoadFile context fails #8575

Closed
rjvdboon opened this issue May 4, 2018 · 3 comments · Fixed by #9858

Comments

@rjvdboon
Copy link
Contributor

@rjvdboon rjvdboon commented May 4, 2018

Steps to Reproduce

  1. Extract the attached repro
  2. make run

Repro.zip

Current Behavior

It throws an Exception.

Expected Behavior

Console shows Found 1 MyCustomAttribute attributes

On which platforms did you notice this

[ ] macOS
[X ] Linux
[ ] Windows

The repro case gives the expected output on .Net framework and Mono up to 5.12.0.128.
It gives the exception on mono/master.

Version Used:

$ mono --version
Mono JIT compiler version 5.15.0 (master/dbfbffb559a Fri May  4 13:57:34 CEST 2018)
Copyright (C) 2002-2014 Novell, Inc, Xamarin Inc and Contributors. www.mono-project.com
        TLS:           __thread
        SIGSEGV:       altstack
        Notifications: epoll
        Architecture:  amd64
        Disabled:      none
        Misc:          softdebug
        Interpreter:   yes
        LLVM:          supported, not enabled.
        GC:            sgen (concurrent by default)
$ gcc --version | head -1
gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-17)
$ uname -srvm
Linux 2.6.32-696.3.2.el6.x86_64 #1 SMP Wed Jun 7 11:51:39 EDT 2017 x86_64

Stacktrace

Can't find custom attr constructor image: /scratch/repro/A.dll mtoken: 0x0a000001 due to: Could not load file or assembly 'Attr, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies.
Got an exception: System.IO.FileNotFoundException: Could not load file or assembly 'Attr, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies.
File name: 'Attr, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'
  at (wrapper managed-to-native) System.MonoCustomAttrs.GetCustomAttributesDataInternal(System.Reflection.ICustomAttributeProvider)
  at System.MonoCustomAttrs.GetCustomAttributesData (System.Reflection.ICustomAttributeProvider obj) [0x0000e] in /scratch/mono/mono-git/mcs/class/corlib/System/MonoCustomAttrs.cs:303
  at System.Reflection.CustomAttributeData.GetCustomAttributesInternal (System.RuntimeType target) [0x00000] in /scratch/mono/mono-git/mcs/class/corlib/System.Reflection/CustomAttributeData.cs:123
  at System.RuntimeType.GetCustomAttributesData () [0x00000] in /scratch/mono/mono-git/mcs/class/referencesource/mscorlib/system/rttype.cs:5119
  at System.Reflection.MemberInfo.get_CustomAttributes () [0x00000] in /scratch/mono/mono-git/mcs/class/referencesource/mscorlib/system/reflection/memberinfo.cs:51
  at P.Prog.Main () [0x0006e] in <f898189524a448b8a9de610606c5ddab>:0
@lambdageek

This comment has been minimized.

Copy link
Member

@lambdageek lambdageek commented May 4, 2018

Somehow Attr.dll gets loaded in the default context in .NET Framework.

(It's not that A.dll is loaded into the default context - other referenced assemblies (for example adding a class with a base type in a referenced assembly) are not loaded even when needed)

@luhenry luhenry added this to Bugs Pool in Bugs Week via automation May 14, 2018
@MaximLipnin MaximLipnin moved this from Bugs Pool to In Progress in Bugs Week Jun 13, 2018
@MaximLipnin MaximLipnin self-assigned this Jun 13, 2018
@MaximLipnin

This comment has been minimized.

Copy link
Collaborator

@MaximLipnin MaximLipnin commented Jun 14, 2018

The similar behavior can be be reproduced on the .Net framework if there is no Attr.dll in bin folder.
On Mono master the repro gives expected result after replacing Assembly.LoadFile with Assembly.LoadFrom.

@marek-safar marek-safar moved this from In Progress to Bugs Pool in Bugs Week Jun 18, 2018
@lambdageek

This comment has been minimized.

Copy link
Member

@lambdageek lambdageek commented Aug 2, 2018

This will be fixed by #9858. assemblies loaded by LoadFile are not as isolated as I thought - they still can reference assemblies from the GAC, and the application base and private bin path of the appdomain.

lambdageek added a commit to lambdageek/mono that referenced this issue Aug 2, 2018
…application base

If an assembly was loaded with LoadFile, it can reference assemblies from the
application base, the GAC or MONO_PATH.

Fixes mono#8575
lambdageek added a commit to lambdageek/mono that referenced this issue Aug 3, 2018
…application base

If an assembly was loaded with LoadFile, it can reference assemblies from the
application base, the GAC or MONO_PATH.

Fixes mono#8575
lambdageek added a commit to lambdageek/mono that referenced this issue Aug 3, 2018
…application base

If an assembly was loaded with LoadFile, it can reference assemblies from the
application base, the GAC or MONO_PATH.

Fixes mono#8575
monojenkins added a commit to monojenkins/mono that referenced this issue Aug 6, 2018
…application base

If an assembly was loaded with LoadFile, it can reference assemblies from the
application base, the GAC or MONO_PATH.

Fixes mono#8575
Bugs Week automation moved this from Bugs Pool to Done Aug 6, 2018
lambdageek added a commit that referenced this issue Aug 6, 2018
* [runtime] Add mono_runtime_get_caller_no_system_or_reflection

   Exposes an already existing stackwalk that we use to find out who called a corlib API.

* [loader] Consult asmctx of executing assembly for Assembly.Load

   if an assembly in LoadFrom context calls Assembly.Load, the given assembly name
   should be tried in the basedir of the executing assembly, and the resulting
   loaded assembly should be in LoadFrom context.

* [loader] Assemblies in individual asmctx can reference assemblies in application base

   If an assembly was loaded with LoadFile, it can reference assemblies from the
   application base, the GAC or MONO_PATH.

   Fixes #8575

* [loader] Pass requesting assembly to mono_assembly_open_predicate

   In LoadFrom and LoadFile icalls, pass the currently executing assembly as the
   requesting assembly.

* [utils] Add mono_path_filename_in_basedir

* [loader] Add mono_install_asmctx_from_path_hook

   Add a hook that can be used to check whether a given path belongs to some
   assembly load context.

   For example if a given path is in the application base of the current
   appdomain, an appdomain hook would set out_asmctx to MONO_ASMCTX_DEFAULT and
   return TRUE.

* [loader] Use appdomain base dir and loadfrom asmctx hooks

   1. If an assembly filename is in the GAC, always open the assembly in default
     context.
   2. If an assembly filename is in the appdomain search path (base directory or
     private bin path) always open the assembly in default context.
   3. If an assembly filename is in the base dir of the requesting assembly and
     the requesting assembly was in LoadFrom context, always open the assembly in
     LoadFrom context.

   Fixes #9753
   and Fixes #9542

* [tests] Test loading references from LoadFrom and LoadFile contexts

   The LoadFrom assembly loading context and the individual assembly loading
   context (aka LoadFile aka "no context") behave differently when requesting a
   referenced assembly - for LoadFile we expect the runtime to probe the appdomain
   base, the GAC + MONO_PATH but not the basedir of the requesting assembly.  For
   LoadFrom the basedir of the requesting assembly _is_ included.  So the tests
   here try all the possible variations.

* [tests] AOT assembly-load-reference tests
marek-safar added a commit that referenced this issue Aug 7, 2018
…application base

If an assembly was loaded with LoadFile, it can reference assemblies from the
application base, the GAC or MONO_PATH.

Fixes #8575
alexanderkyte added a commit to alexanderkyte/mono that referenced this issue Aug 16, 2018
* [runtime] Add mono_runtime_get_caller_no_system_or_reflection

   Exposes an already existing stackwalk that we use to find out who called a corlib API.

* [loader] Consult asmctx of executing assembly for Assembly.Load

   if an assembly in LoadFrom context calls Assembly.Load, the given assembly name
   should be tried in the basedir of the executing assembly, and the resulting
   loaded assembly should be in LoadFrom context.

* [loader] Assemblies in individual asmctx can reference assemblies in application base

   If an assembly was loaded with LoadFile, it can reference assemblies from the
   application base, the GAC or MONO_PATH.

   Fixes mono#8575

* [loader] Pass requesting assembly to mono_assembly_open_predicate

   In LoadFrom and LoadFile icalls, pass the currently executing assembly as the
   requesting assembly.

* [utils] Add mono_path_filename_in_basedir

* [loader] Add mono_install_asmctx_from_path_hook

   Add a hook that can be used to check whether a given path belongs to some
   assembly load context.

   For example if a given path is in the application base of the current
   appdomain, an appdomain hook would set out_asmctx to MONO_ASMCTX_DEFAULT and
   return TRUE.

* [loader] Use appdomain base dir and loadfrom asmctx hooks

   1. If an assembly filename is in the GAC, always open the assembly in default
     context.
   2. If an assembly filename is in the appdomain search path (base directory or
     private bin path) always open the assembly in default context.
   3. If an assembly filename is in the base dir of the requesting assembly and
     the requesting assembly was in LoadFrom context, always open the assembly in
     LoadFrom context.

   Fixes mono#9753
   and Fixes mono#9542

* [tests] Test loading references from LoadFrom and LoadFile contexts

   The LoadFrom assembly loading context and the individual assembly loading
   context (aka LoadFile aka "no context") behave differently when requesting a
   referenced assembly - for LoadFile we expect the runtime to probe the appdomain
   base, the GAC + MONO_PATH but not the basedir of the requesting assembly.  For
   LoadFrom the basedir of the requesting assembly _is_ included.  So the tests
   here try all the possible variations.

* [tests] AOT assembly-load-reference tests
@marek-safar marek-safar moved this from Done to Archived in Bugs Week Sep 24, 2018
jonpryor added a commit to xamarin/xamarin-android that referenced this issue Oct 9, 2018
Bumps to mono/llvm:release_60@117a508c
Bumps to xamarin/xamarin-android-api-compatibility:master@7ccb4802

	$ git diff --shortstat e1af6ea..ab3c897d       # mono
        1443 files changed, 66049 insertions(+), 45745 deletions(-)
	$ git diff --shortstat bdb3a116..117a508c      # llvm
	 26794 files changed, 4110589 insertions(+), 754376 deletions(-)
	$ git diff --shortstat c550d1bd..7ccb4802      # xamarin-android-api-compatibility
	 2 files changed, 16260 insertions(+), 12347 deletions(-)

Incomplete summary of easily `grep`able fixes:

Fixes: https://bugzilla.xamarin.com/show_bug.cgi?id=11199
Fixes: https://bugzilla.xamarin.com/show_bug.cgi?id=19436
Fixes: https://bugzilla.xamarin.com/show_bug.cgi?id=23668
Fixes: https://bugzilla.xamarin.com/show_bug.cgi?id=26983
Fixes: https://bugzilla.xamarin.com/show_bug.cgi?id=33728
Fixes: https://bugzilla.xamarin.com/show_bug.cgi?id=46917
fixes: https://bugzilla.xamarin.com/show_bug.cgi?id=60065
Fixes: mono/mono#6173
Fixes: mono/mono#6466
Fixes: mono/mono#6647
Fixes: mono/mono#6834
Fixes: mono/mono#7058
Fixes: mono/mono#7137
Fixes: mono/mono#7260
Fixes: mono/mono#7305
Fixes: mono/mono#7402
Fixes: mono/mono#7525
Fixes: mono/mono#7610
Fixes: mono/mono#7649
Fixes: mono/mono#7655
Fixes: mono/mono#7683
Fixes: mono/mono#7685
Fixes: mono/mono#7716
Fixes: mono/mono#7731
Fixes: mono/mono#7785
Fixes: mono/mono#7828
Fixes: mono/mono#7944
Fixes: mono/mono#7947
Fixes: mono/mono#8036
Fixes: mono/mono#8074
Fixes: mono/mono#8089
Fixes: mono/mono#8112
Fixes: mono/mono#8122
Fixes: mono/mono#8143
Fixes: mono/mono#8149
Fixes: mono/mono#8152
Fixes: mono/mono#8175
Fixes: mono/mono#8177
Fixes: mono/mono#8250
Fixes: mono/mono#8267
Fixes: mono/mono#8273
Fixes: mono/mono#8282
Fixes: mono/mono#8310
Fixes: mono/mono#8311
Fixes: mono/mono#8329
Fixes: mono/mono#8340
Fixes: mono/mono#8372
Fixes: mono/mono#8407
Fixes: mono/mono#8409
Fixes: mono/mono#8422
Fixes: mono/mono#8430
Fixes: mono/mono#8439
fixes: mono/mono#8447
Fixes: mono/mono#8469
Fixes: mono/mono#8504
Fixes: mono/mono#8575
Fixes: mono/mono#8597
Fixes: mono/mono#8623
Fixes: mono/mono#8627
Fixes: mono/mono#8698
Fixes: mono/mono#8701
Fixes: mono/mono#8712
Fixes: mono/mono#8721
Fixes: mono/mono#8726
Fixes: mono/mono#8759
Fixes: mono/mono#8787
Fixes: mono/mono#8820
Fixes: mono/mono#8848
Fixes: mono/mono#8866
Fixes: mono/mono#8897
Fixes: mono/mono#8915
Fixes: mono/mono#8970
Fixes: mono/mono#8979
Fixes: mono/mono#9023
Fixes: mono/mono#9031
Fixes: mono/mono#9033
Fixes: mono/mono#9179
Fixes: mono/mono#9234
Fixes: mono/mono#9262
Fixes: mono/mono#9277
Fixes: mono/mono#9318
Fixes: mono/mono#9542
Fixes: mono/mono#9753
Fixes: mono/mono#9839
Fixes: mono/mono#9869
Fixes: mono/mono#9870
Fixes: mono/mono#9943
Fixes: mono/mono#9996
Fixes: mono/mono#10000
Fixes: mono/mono#10303
Fixes: mono/mono#10447
Fixes: mono/mono#10483
Fixes: mono/mono#10488
Fixes: xamarin/maccore#628
Fixes: xamarin/maccore#673
Fixes: #1561 (comment)
Fixes: #1845
Fixes: xamarin/xamarin-macios#4347
Fixes: xamarin/xamarin-macios#4617
Fixes: xamarin/xamarin-macios#4618
jonpryor added a commit to xamarin/xamarin-android that referenced this issue Dec 6, 2018
Bumps to mono/api-snapshot@b99fc87.
Bumps to mono/bockbuild@5af573e.
Bumps to mono/boringssl@41221b4.
Bumps to mono/corefx@23d0b58.
Bumps to mono/corert@af496fc.
Bumps to mono/linker@7af03ce.
Bumps to mono/NUnitLite@00e259a.
Bumps to mono/reference-assemblies@9325826.
Bumps to mono/roslyn-binaries@249709f.
Bumps to mono/xunit-binaries@bb58347.

	$ git diff --shortstat b63e5378..23f2024a      # mono 
	 1630 files changed, 50926 insertions(+), 92212 deletions(-)

Fixes: mono/mono#6352
Fixes: mono/mono#6947
Fixes: mono/mono#6992
Fixes: mono/mono#7615
Fixes: mono/mono#8340
Fixes: mono/mono#8407
Fixes: mono/mono#8575
Fixes: mono/mono#8627
Fixes: mono/mono#8707
Fixes: mono/mono#8766
Fixes: mono/mono#8848
Fixes: mono/mono#8866
Fixes: mono/mono#8935
Fixes: mono/mono#9010
Fixes: mono/mono#9023
Fixes: mono/mono#9031
Fixes: mono/mono#9033
Fixes: mono/mono#9106
Fixes: mono/mono#9109
Fixes: mono/mono#9155
Fixes: mono/mono#9179
Fixes: mono/mono#9232
Fixes: mono/mono#9234
Fixes: mono/mono#9262
Fixes: mono/mono#9277
Fixes: mono/mono#9292
Fixes: mono/mono#9318
Fixes: mono/mono#9318
Fixes: mono/mono#9332
Fixes: mono/mono#9407
Fixes: mono/mono#9421
Fixes: mono/mono#9505
Fixes: mono/mono#9542
Fixes: mono/mono#9581
Fixes: mono/mono#9623
Fixes: mono/mono#9684
Fixes: mono/mono#9750
Fixes: mono/mono#9753
Fixes: mono/mono#9772
Fixes: mono/mono#9839
Fixes: mono/mono#9869
Fixes: mono/mono#9921
Fixes: mono/mono#9943
Fixes: mono/mono#9947
Fixes: mono/mono#9973
Fixes: mono/mono#9996
Fixes: mono/mono#10000
Fixes: mono/mono#10031
Fixes: mono/mono#10035
Fixes: mono/mono#10227
Fixes: mono/mono#10243
Fixes: mono/mono#10303
Fixes: mono/mono#10448
Fixes: mono/mono#10483
Fixes: mono/mono#10488
Fixes: mono/mono#10863
Fixes: mono/mono#11123
Fixes: mono/mono#11138
Fixes? mono/mono#11146
Fixes: mono/mono#11202
Fixes: mono/mono#11378
Fixes: mono/mono#11479
Fixes: mono/mono#11613
Fixes: #1951
Fixes: xamarin/xamarin-macios#4347
Fixes: xamarin/xamarin-macios#4617
Fixes: xamarin/xamarin-macios#4984
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Bugs Week
Archived
3 participants
You can’t perform that action at this time.