headers
FirstName LastName | 10 Oct 21:24
Favicon

Mono 2.0 (arm): Reverse PInvoke can cause memory corruption?

Hi,
 
Recently, I asked about doing reverse pinvoke from a native thread that caused an assert in mini-arm.c.
 
A fix was done and I'm able to do it.  But know, I have a feeling that I have memory corruption.  My application is crashing at different times
 
and display different stack traces.
 
I have a general question regarding GC.  When the GC runs, does it stop all threads in the process, even those created in unmanaged.
 
I asking the following because I'm wondering what would happen if the GC collects and at the same time, a reverse pinvoke is done from a native thread (back to managed code)?
 
Can this be an issue?
 
 

_______________________________________________
Mono-devel-list mailing list
Mono-devel-list <at> lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Permalink | Reply |
headers
Zoltan Varga | 10 Oct 21:41

Re: Mono 2.0 (arm): Reverse PInvoke can cause memory corruption?

Hi,

  The GC only stops threads registered with it. This can be done multiple ways:
- all threads started by the runtime are automatically registered.
- an embedding app can register its threads by calling the
mono_thread_attach () API
  function.
- a non-registered thread is automatically registered the first time
it calls into managed
  code.

The third way is the easiest for applications, but it might have race
condition: if a GC
happens inside the call, I'm not sure what happens.

                 Zoltan

2008/10/10 FirstName LastName <mousse_man <at> hotmail.com>:
> Hi,
>
> Recently, I asked about doing reverse pinvoke from a native thread that
> caused an assert in mini-arm.c.
>
> A fix was done and I'm able to do it.  But know, I have a feeling that I
> have memory corruption.  My application is crashing at different times
>
> and display different stack traces.
>
> I have a general question regarding GC.  When the GC runs, does it stop all
> threads in the process, even those created in unmanaged.
>
> I asking the following because I'm wondering what would happen if the GC
> collects and at the same time, a reverse pinvoke is done from a native
> thread (back to managed code)?
>
> Can this be an issue?
>
>
>
> ________________________________
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list <at> lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
>
Permalink | Reply |
headers
Paolo Molaro | 10 Oct 22:49

Re: Mono 2.0 (arm): Reverse PInvoke can cause memory corruption?

On 10/10/08 FirstName LastName wrote:
> I have a general question regarding GC.  When the GC runs, does it
> stop all threads in the process, even those created in unmanaged.

Only the ones it knows about, but see below.

> I asking the following because I'm wondering what would happen if the
> GC collects and at the same time, a reverse pinvoke is done from a native
> thread (back to managed code)?

The fix I committed will register the thread with the GC before
the delegate is executed on that thread.
Note that you must not manipulate managed objects in threads that were
not known to the runtime (they are known when they where created by
mono, the main thread, the ones where reverse p/invoke delegates are
called and the ones registered explicitly).
Try setting GC_DONT_GC=1 and running the app to see the crashes are due
to the GC.

lupus

--

-- 
-----------------------------------------------------------------
lupus <at> debian.org                                     debian/rules
lupus <at> ximian.com                             Monkeys do it better
Permalink | Reply |

Gmane