Re: [Mono-dev] Conflict between Mono.Debugger.Soft and .NET

2010-12-04 Thread Virgile Bello
As code inside both .NET VM is totally separate and won't reference each
other, is it really a problem?
So far, I could run code inside the embedded VM without any problem (main
app is using MS VM for WPF, embedded inside PInvoke code is mono VM for user
scripts, so code is totally separate, there should be no common DLL), only
the breakpoint hook was problematic.

Virgile

On 2010/12/04, at 15:57, Zoltan Varga var...@gmail.com wrote:

Hi,

   You are basically embedding the mono runtime inside the .net runtime,
this will not work, not just debugging, but other stuff as well.

 Zoltan

On Sat, Dec 4, 2010 at 4:53 AM, Virgile Bello virgile.be...@gmail.comwrote:

 Hello,

 I am embedding Mono VM from C++ using mono runtime API, and using
 Mono.Debugger.Soft to debug the code running inside the VM (for scripting
 purpose).
 I managed to make it work well (I receive TypeLoad  MethodEntry events
 from debugger).

 However, I tried to embed this C++ code inside a .NET application through
 P/Invoke to make some tools with UI (layers are .NET/UI ==(pinvoke)== C++
 engine ==(mono VM)== Mono scripting). In that configuration, the
 application crash as soon as it tries to run some VM code that should
 trigger a breakpoint/MethodEntry event, i.e. running a constructor (the
 debugger connect, and I receive AssemblyLoad and TypeLoad event before it
 crashes). Log shows everything is fine but suddenly stop at the time
 breakpoint is supposed to be caught.

 I suppose this is due to a conflict about how Mono try to catch the
 breakpoint (using interrupt or something like that) and the .NET layer which
 probably try to catch those events as well for internal reasons (failure
 detection, or to transmit some other information maybe).
 I was wondering if someone could think of a way to make .NET runtime not
 conflict with Mono debug breakpoints.

 Also, just so you know, Mono.Debugger.Soft.dll shipped with Mono 2.8.1
 Windows doesn't work, I had to either recompile it or get the one from
 MonoDevelop.

 Virgile

 ___
 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] Conflict between Mono.Debugger.Soft and .NET

2010-12-04 Thread Zoltan Varga
Mono uses segmentation fault handling to implement both breakpoints/single
stepping and
null reference exception handling. MS.NET probably does the same, and the
two can't coexist. If you embed your code inside the MS.NET VM anyway, why
don't you use their vm for running this scripting code instead of mono ?

Zoltan

On Sat, Dec 4, 2010 at 10:01 AM, Virgile Bello virgile.be...@gmail.comwrote:

 As code inside both .NET VM is totally separate and won't reference each
 other, is it really a problem?
 So far, I could run code inside the embedded VM without any problem (main
 app is using MS VM for WPF, embedded inside PInvoke code is mono VM for user
 scripts, so code is totally separate, there should be no common DLL), only
 the breakpoint hook was problematic.

 Virgile

 On 2010/12/04, at 15:57, Zoltan Varga var...@gmail.com wrote:

 Hi,

You are basically embedding the mono runtime inside the .net runtime,
 this will not work, not just debugging, but other stuff as well.

  Zoltan

 On Sat, Dec 4, 2010 at 4:53 AM, Virgile Bello  virgile.be...@gmail.com
 virgile.be...@gmail.com wrote:

 Hello,

 I am embedding Mono VM from C++ using mono runtime API, and using
 Mono.Debugger.Soft to debug the code running inside the VM (for scripting
 purpose).
 I managed to make it work well (I receive TypeLoad  MethodEntry events
 from debugger).

 However, I tried to embed this C++ code inside a .NET application through
 P/Invoke to make some tools with UI (layers are .NET/UI ==(pinvoke)== C++
 engine ==(mono VM)== Mono scripting). In that configuration, the
 application crash as soon as it tries to run some VM code that should
 trigger a breakpoint/MethodEntry event, i.e. running a constructor (the
 debugger connect, and I receive AssemblyLoad and TypeLoad event before it
 crashes). Log shows everything is fine but suddenly stop at the time
 breakpoint is supposed to be caught.

 I suppose this is due to a conflict about how Mono try to catch the
 breakpoint (using interrupt or something like that) and the .NET layer which
 probably try to catch those events as well for internal reasons (failure
 detection, or to transmit some other information maybe).
 I was wondering if someone could think of a way to make .NET runtime not
 conflict with Mono debug breakpoints.

 Also, just so you know, Mono.Debugger.Soft.dll shipped with Mono 2.8.1
 Windows doesn't work, I had to either recompile it or get the one from
 MonoDevelop.

 Virgile

 ___
 Mono-devel-list mailing list
  Mono-devel-list@lists.ximian.comMono-devel-list@lists.ximian.com
  http://lists.ximian.com/mailman/listinfo/mono-devel-list
 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] Conflict between Mono.Debugger.Soft and .NET

2010-12-04 Thread Virgile Bello
I see, thanks for the details. I suppose I will probably need to separate
process or redesign to share VM (I won't be able to have WPF UI and mono VM
API at the same time tho). I will take a look if I can disable segfault
handling for MS (enclosing) VM when running PInvoke code as well.

The system/engine is supposed to run as C++ alone with mono embedded for
it's scripts. Additional enclosing VM was only for designer/editing WPF UI
tools calling directly this C++ API to run the engine.

Virgile

On 2010/12/04, at 18:18, Zoltan Varga var...@gmail.com wrote:

Mono uses segmentation fault handling to implement both breakpoints/single
stepping and
null reference exception handling. MS.NET probably does the same, and the
two can't coexist. If you embed your code inside the MS.NET VM anyway, why
don't you use their vm for running this scripting code instead of mono ?

Zoltan

On Sat, Dec 4, 2010 at 10:01 AM, Virgile Bello virgile.be...@gmail.comwrote:

 As code inside both .NET VM is totally separate and won't reference each
 other, is it really a problem?
 So far, I could run code inside the embedded VM without any problem (main
 app is using MS VM for WPF, embedded inside PInvoke code is mono VM for user
 scripts, so code is totally separate, there should be no common DLL), only
 the breakpoint hook was problematic.

 Virgile

 On 2010/12/04, at 15:57, Zoltan Varga var...@gmail.com wrote:

 Hi,

You are basically embedding the mono runtime inside the .net runtime,
 this will not work, not just debugging, but other stuff as well.

  Zoltan

 On Sat, Dec 4, 2010 at 4:53 AM, Virgile Bello  virgile.be...@gmail.com
 virgile.be...@gmail.com wrote:

 Hello,

 I am embedding Mono VM from C++ using mono runtime API, and using
 Mono.Debugger.Soft to debug the code running inside the VM (for scripting
 purpose).
 I managed to make it work well (I receive TypeLoad  MethodEntry events
 from debugger).

 However, I tried to embed this C++ code inside a .NET application through
 P/Invoke to make some tools with UI (layers are .NET/UI ==(pinvoke)== C++
 engine ==(mono VM)== Mono scripting). In that configuration, the
 application crash as soon as it tries to run some VM code that should
 trigger a breakpoint/MethodEntry event, i.e. running a constructor (the
 debugger connect, and I receive AssemblyLoad and TypeLoad event before it
 crashes). Log shows everything is fine but suddenly stop at the time
 breakpoint is supposed to be caught.

 I suppose this is due to a conflict about how Mono try to catch the
 breakpoint (using interrupt or something like that) and the .NET layer which
 probably try to catch those events as well for internal reasons (failure
 detection, or to transmit some other information maybe).
 I was wondering if someone could think of a way to make .NET runtime not
 conflict with Mono debug breakpoints.

 Also, just so you know, Mono.Debugger.Soft.dll shipped with Mono 2.8.1
 Windows doesn't work, I had to either recompile it or get the one from
 MonoDevelop.

 Virgile

 ___
 Mono-devel-list mailing list
  Mono-devel-list@lists.ximian.comMono-devel-list@lists.ximian.com
  http://lists.ximian.com/mailman/listinfo/mono-devel-list
 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