Please do not reply to this email- if you want to comment on the bug, go to the URL shown below and enter your comments there.
Changed by [EMAIL PROTECTED] http://bugzilla.ximian.com/show_bug.cgi?id=77596 --- shadow/77596 2007-07-20 10:55:39.000000000 -0400 +++ shadow/77596.tmp.6345 2007-07-20 13:31:16.000000000 -0400 @@ -283,6 +283,20 @@ Sorry if I'm misunderstanding, but isn't the problem that a GenericInst from B references a generic type from C (that gets allocated from C's mempool), and C was already unloaded (freeing it's mempool)? Thus when B tries to check if the type is in B (and access type), it's accessing freed memory? + +------- Additional Comments From [EMAIL PROTECTED] 2007-07-20 13:31 ------- +The problem is that the generic inst cache has a GenericInst created +by parse_generic_inst, which contains a MonoType that was created in +the mempool of the image the particular instance was parsed in +(System.dll in your case). This includes 'MonoType's for things like +int and object, which are not even defined in the image being parsed. + +That's why the additional check in my quick fix to handle a source of +mempool allocations that wasn't handled before. + +The correct fix is to avoid mempool-allocated stuff in the cache -- we +don't want unrelated cached items disappearing when a image is +removed. This can also make GenericInst ownership issues simpler. _______________________________________________ mono-bugs maillist - [email protected] http://lists.ximian.com/mailman/listinfo/mono-bugs
