from:"Zoltan Varga"

Re: [Mono-dev] gdb and mono

2016-03-28 Thread Zoltan Varga

Hi,

  This was fixed some time ago by mono commit
a6380f15f0db533e30870925e0125a859ab815cf.

Zoltan

On Mon, Mar 28, 2016 at 2:21 PM, David Evans 
wrote:

> Sorry if this has been covered before, or is a current issue, but is there
> a way around these errors using gdb with mono 4.x?
>
>
>
> I generally see “/build/buildd/gdb-7.7.1/gdb/dwarf2-frame.c:692:
> internal-error: Unknown CFI encountered.” whenever trying to look at
> things in gdb.
>
>
>
> Thx!
>
>
>
> (gdb) bt
>
> #0  sem_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/sem_wait.S:85
>
> #1  0x0061f977 in mono_sem_wait (sem=sem@entry=0x7fbacc000940,
> alertable=alertable@entry=0) at mono-semaphore.c:107
>
> #2  0x0062465a in mono_thread_info_wait_for_resume
> (info=) at mono-threads.c:110
>
> #3  mono_thread_info_end_self_suspend () at mono-threads.c:692
>
> #4  0x005876dc in self_suspend_internal (thread=0x7fbadbb40430) at
> threads.c:4546
>
> #5  mono_thread_execute_interruption (thread=thread@entry=0x7fbadbb40430)
> at threads.c:4050
>
> #6  0x005879ac in mono_wait_uninterrupted 
> (thread=thread@entry=0x7fbadbb40430,
> multiple=multiple@entry=0,
>
> numhandles=numhandles@entry=1, handles=handles@entry=0x7fbad67fd638,
> waitall=waitall@entry=0, ms=ms@entry=1725, alertable=1)
>
> at threads.c:1455
>
> #7  0x00588f59 in
> ves_icall_System_Threading_WaitHandle_WaitOne_internal (this= out>, handle=0x100c, ms=1725,
>
> exitContext=) at threads.c:1583
>
> #8  0x40962760 in ?? ()
>
> #9  0x0038 in ?? ()
>
> #10 0x02521f28 in ?? ()
>
> #11 0x06bd in ?? ()
>
> #12 0x7fbada29f278 in ?? ()
>
> #13 0x06bd in ?? ()
>
> #14 0x7fbacc000e01 in ?? ()
>
> #15 0x41641e7d in ?? ()
>
> #16 0x7fbad67fd6f0 in ?? ()
>
> #17 0x7fbad67fd660 in ?? ()
>
> /build/buildd/gdb-7.7.1/gdb/dwarf2-frame.c:692: internal-error: Unknown
> CFI encountered.
>
> A problem internal to GDB has been detected,
>
> further debugging may prove unreliable.
>
> Quit this debugging session? (y or n) n
>
> /build/buildd/gdb-7.7.1/gdb/dwarf2-frame.c:692: internal-error: Unknown
> CFI encountered.
>
> A problem internal to GDB has been detected,
>
> further debugging may prove unreliable.
>
> Create a core file of GDB? (y or n) n
>
> Command aborted.
>
>
>
> ___
> 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] Using valgrind with Mono

2016-03-27 Thread Zoltan Varga

Hi,

  Fixed the last one in:
https://github.com/mono/mono/commit/b97ac0023256bf7d915552f5f24a7742b28c32b7

The first two are leaks, but they should be small and bounded. Will look
into fixing them to decrease the noise.

  Zoltan

On Sun, Mar 27, 2016 at 6:23 PM, Zinkevicius, Matt  wrote:

> Hello,
>
>
>
> Our backend service running on Mono 4.2.2 on Linux is experiencing an
> unmanaged memory leak. When running our stress tests for several hours, we
> see the managed heap sit around 50 MB, while private memory keeps growing
> until the process is killed because of OOM. I am therefore attempting to
> use valgrind to find the culprit, but I am getting so many leaks detected
> that I think many must be false positives, so I thought I would ask here
> for some guidance about which are safe to suppress or any other valgrind +
> mono tricks you can share.
>
>
>
> The vast majority of leaks reported have call stacks that closely match
> one of the following:
>
>
>
> ==16846== 4 bytes in 1 blocks are definitely lost in loss record 74 of
> 19,903
>
> ==16846==at 0x4C26FEF: calloc (vg_replace_malloc.c:711)
>
> ==16846==by 0x62D1D9: monoeg_malloc0 (in /usr/bin/mono-sgen)
>
> ==16846==by 0x4870F2: decode_exception_debug_info (in
> /usr/bin/mono-sgen)
>
> ==16846==by 0x488975: mono_aot_find_jit_info (in /usr/bin/mono-sgen)
>
> ==16846==by 0x53C3A7: mono_jit_info_table_find_internal (in
> /usr/bin/mono-sgen)
>
> ==16846==by 0x493C04: mini_jit_info_table_find_ext (in
> /usr/bin/mono-sgen)
>
> ==16846==by 0x4988FB: mini_add_method_trampoline (in
> /usr/bin/mono-sgen)
>
> ==16846==by 0x499067: common_call_trampoline_inner (in
> /usr/bin/mono-sgen)
>
> ==16846==by 0x403217C: ???
>
> ==16846==by 0x10D3FB63: ???
>
> ==16846==by 0x10D3F41B: ???
>
> ==16846==by 0x10D3F117: ???
>
>
>
> ==16846== 12 bytes in 1 blocks are definitely lost in loss record 1,172 of
> 19,903
>
> ==16846==at 0x4C2828A: malloc (vg_replace_malloc.c:299)
>
> ==16846==by 0x62D221: monoeg_malloc (in /usr/bin/mono-sgen)
>
> ==16846==by 0x55B8EF: mono_metadata_type_dup (in /usr/bin/mono-sgen)
>
> ==16846==by 0x49FC4B: get_shared_gparam (in /usr/bin/mono-sgen)
>
> ==16846==by 0x49FE70: get_shared_inst (in /usr/bin/mono-sgen)
>
> ==16846==by 0x4A073A: mini_get_shared_method_full (in
> /usr/bin/mono-sgen)
>
> ==16846==by 0x414723: lookup_method (in /usr/bin/mono-sgen)
>
> ==16846==by 0x4147FA: mono_jit_compile_method_with_opt (in
> /usr/bin/mono-sgen)
>
> ==16846==by 0x414B9A: mono_jit_compile_method (in /usr/bin/mono-sgen)
>
> ==16846==by 0x498DA4: common_call_trampoline_inner (in
> /usr/bin/mono-sgen)
>
> ==16846==by 0x403405C: ???
>
> ==16846==by 0x10D2DCA7: ???
>
>
>
> ==16846== 10 bytes in 1 blocks are definitely lost in loss record 739 of
> 19,903
>
> ==16846==at 0x4C2828A: malloc (vg_replace_malloc.c:299)
>
> ==16846==by 0x62D221: monoeg_malloc (in /usr/bin/mono-sgen)
>
> ==16846==by 0x62BA8C: monoeg_g_utf16_to_utf8 (in /usr/bin/mono-sgen)
>
> ==16846==by 0x5A8646: mono_string_to_utf8_checked (in
> /usr/bin/mono-sgen)
>
> ==16846==by 0x5A885B: mono_string_to_utf8 (in /usr/bin/mono-sgen)
>
> ==16846==by 0x52DE3C: ves_icall_Type_GetNestedTypes (in
> /usr/bin/mono-sgen)
>
> ==16846==by 0x120D4256: ???
>
> ==16846==by 0xE338A78:
> System_Type_GetMember_string_System_Reflection_BindingFlags (type.cs:806)
>
> ==16846==by 0x40C09EF: ???
>
> ==16846==by 0x1259A6AF: ???
>
> ==16846==by 0x73: ???
>
> ==16846==by 0x141D191D: ???
>
>
>
> Are these valid leaks or is valgrind confused/misconfigured? I am using
> the following command:
>
> valgrind --tool=memcheck -v --leak-check=full --log-file=val.txt
> --smc-check=all mono program.exe
>
>
>
> Thanks for any input you can offer,
>
> Matt Zinkevicius
>
>
>
>
>
> ___
> 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] Strange build problem

2016-01-19 Thread Zoltan Varga

Hi,

 If this used to work, you can try git bisect-ing it. Since its an s390x
problem, I'd guess it has to do with endianness.

   Zoltan

On Tue, Jan 19, 2016 at 9:13 PM, Neale Ferguson 
wrote:

> Re: bugzilla 37781
>
> On the same virtual machine in which the Jenkins bot successfully builds
> mono, I am encountering failures of an unusual type. Thinking it might be
> a hangover to something in the account’s home directory, I created a
> completely new account, cloned from master, configured and built. It craps
> out with the following:
>
> MCS [build] mscorlib.dll
> Assembly/AssemblyInfo.cs(33,5): error CS8025: Parsing error
> System/AndroidPlatform.cs(66,246): error CS1525: Unexpected symbol
> `end-of-file', expecting `end-of-file'
> System/Console.iOS.cs(127,246): error CS1525: Unexpected symbol
> `end-of-file', expecting `end-of-file'
> System/Guid.MonoTouch.cs(24,253): error CS1525: Unexpected symbol
> `end-of-file', expecting `end-of-file'
> System/TimeZoneInfo.Android.cs(737,246): error CS1525: Unexpected symbol
> `end-of-file', expecting `end-of-file'
> System/TimeZoneInfo.MonoTouch.cs(109,246): error CS1525: Unexpected symbol
> `end-of-file', expecting `end-of-file'
> System.Globalization/RegionInfo.MonoTouch.cs(54,246): error CS1525:
> Unexpected symbol `end-of-file', expecting `end-of-file'
> System.IO/LogcatTextWriter.cs(80,246): error CS1525: Unexpected symbol
> `end-of-file', expecting `end-of-file'
> System.Security/SecurityManager_mobile.cs(215,246): error CS1525:
> Unexpected symbol `end-of-file', expecting `end-of-file'
> System.Security.Cryptography/CryptoConfig.fullaot.cs(239,246): error
> CS1525: Unexpected symbol `end-of-file', expecting `end-of-file'
> ../../../external/referencesource/mscorlib/system/resources/__hresults.cs(2
> 6,246): error CS1525: Unexpected symbol `end-of-file', expecting
> `end-of-file'
> ../../../external/referencesource/mscorlib/system/resources/looselylinkedre
> sourcereference.cs(89,246): error CS1525: Unexpected symbol `end-of-file',
> expecting `end-of-file'
> Compilation failed: 12 error(s), 0 warnings
>
> I am at a loss to work out WTF is happening. I like the way the error
> message keeps a straight face when it complains about encountering
> “end-of-file” symbol when it was really expecting “end-of-file”!
>
>
> Any suggestions about where to look?
>
> 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

Re: [Mono-dev] Issues with Thread.CurrentThread on 4.2

2015-11-12 Thread Zoltan Varga

Hi,

  Reported as:
https://bugzilla.xamarin.com/show_bug.cgi?id=35828
Zoltan

On Thu, Nov 12, 2015 at 12:42 PM, Martin Potter  wrote:

> We have some code which works on Microsoft’s runtime and used to work on
> Mono 3.12, but now fails on Mono 4.2. Simplified code to reproduce the
> issue is as follows:
>
> public class WorkStateThread
> {
> public void Start()
> {
> m_thread = new Thread(ThreadProc);
> m_thread.Start(Thread.CurrentThread);
> m_thread.Join();
> }
>
> private void ThreadProc (object objData)
> {
> if (m_thread != Thread.CurrentThread)
> throw new InvalidOperationException ("m_thread != Thread.CurrentThread");
> }
>
> Thread m_thread;
> }
>
> class MainClass
> {
> public static void Main (string[] args)
> {
> WorkStateThread ws = new WorkStateThread ();
> ws.Start ();
> Console.WriteLine ("Done");
> }
> }
>
> [TestFixture]
> public class Test
> {
> [Test]
> public void TestCase ()
> {
> WorkStateThread ws = new WorkStateThread ();
> ws.Start ();
> }
> }
>
> This code runs as expected when run from the command line, but if run as
> part of a unit test using NUnit, the InvalidOperationException is thrown.
>
> — Martin
>
> ___
> 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] Link errors with mono-llvm

2015-10-23 Thread Zoltan Varga

Hi,

 No, building with the default options should work.

On Fri, Oct 23, 2015 at 1:45 PM, Bill Seurer <seu...@linux.vnet.ibm.com>
wrote:

> I originally used https://github.com/mono/llvm/mono-4-3 (though I don't
> remember why) but I will switch and try the master branch.  Using
> --with_llvm didn't work as things are set up now.
>
> Any special configuration options I should be using when building llvm?
>
> On 10/23/2015 11:00 AM, Zoltan Varga wrote:
>
>> Hi,
>>
>>Make sure you are using the 'master' branch of the mono llvm repo.
>> Also, try using --with-llvm= instead of --enable-llvm=yes, the
>> latter might pick up the system version of llvm. Otherwise, I don't know
>> what is causing the problem, those symbols are in libraries which are
>> supposed to be linked into the mono executable, i.e.:
>> mini/Makefile should contains something like:
>>
>> LLVM_LIBS = -lLLVMX86CodeGen -lLLVMX86Desc -lLLVMX86Info
>> -lLLVMMCDisassembler -lLLVMX86AsmPrinter -lLLVMX86Utils
>> -lLLVMSelectionDAG -lLLVMAsmPrinter -lLLVMMCJIT -lLLVMRuntimeDyld
>> -lLLVMObject -lLLVMMCParser -lLLVMBitReader -lLLVMJIT
>> -lLLVMExecutionEngine -lLLVMCodeGen -lLLVMScalarOpts -lLLVMInstCombine
>> -lLLVMTransformUtils -lLLVMipa -lLLVMBitWriter -lLLVMAnalysis
>> -lLLVMTarget -lLLVMMC -lLLVMCore -lLLVMSupport
>> -L/Users/vargaz/git/llvm/usr64/lib  -lz -lpthread -ledit -lcurses -lm
>> -lstdc++
>>
>> Zoltan
>>
>>
>> On Fri, Oct 23, 2015 at 11:51 AM, Bill Seurer <seu...@linux.vnet.ibm.com
>> <mailto:seu...@linux.vnet.ibm.com>> wrote:
>>
>> I am attempting to activate the llvm backend for power but am
>> running into linker issues.  I get hundreds of missing symbols
>> errors like this when I do an  --enable-llvm=yes build:
>>
>> /home/seurer/mono-git/mono-llvm/mono/mini/mini-llvm-cpp.cpp:557:
>> undefined reference to `llvm::createNoAAPass()'
>>
>> The symbols it is complaining about are in the libraries that were
>> created when I compiled the mono version of llvm.  I even specified
>> all the libraries directly in the LDFLAGS environment variable but
>> the symbols still are not found.
>>
>> Any ideas what I am doing wrong?
>> --
>>
>> -Bill Seurer
>>
>> ___
>> Mono-devel-list mailing list
>> Mono-devel-list@lists.ximian.com
>> <mailto:Mono-devel-list@lists.ximian.com>
>> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>>
>>
>>
>
> --
>
> -Bill Seurer
>
>
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Link errors with mono-llvm

2015-10-23 Thread Zoltan Varga

Hi,

  Make sure you are using the 'master' branch of the mono llvm repo. Also,
try using --with-llvm= instead of --enable-llvm=yes, the latter
might pick up the system version of llvm. Otherwise, I don't know what is
causing the problem, those symbols are in libraries which are supposed to
be linked into the mono executable, i.e.:
mini/Makefile should contains something like:

LLVM_LIBS = -lLLVMX86CodeGen -lLLVMX86Desc -lLLVMX86Info
-lLLVMMCDisassembler -lLLVMX86AsmPrinter -lLLVMX86Utils -lLLVMSelectionDAG
-lLLVMAsmPrinter -lLLVMMCJIT -lLLVMRuntimeDyld -lLLVMObject -lLLVMMCParser
-lLLVMBitReader -lLLVMJIT -lLLVMExecutionEngine -lLLVMCodeGen
-lLLVMScalarOpts -lLLVMInstCombine -lLLVMTransformUtils -lLLVMipa
-lLLVMBitWriter -lLLVMAnalysis -lLLVMTarget -lLLVMMC -lLLVMCore
-lLLVMSupport -L/Users/vargaz/git/llvm/usr64/lib  -lz -lpthread -ledit
-lcurses -lm  -lstdc++

   Zoltan

On Fri, Oct 23, 2015 at 11:51 AM, Bill Seurer 
wrote:

> I am attempting to activate the llvm backend for power but am running into
> linker issues.  I get hundreds of missing symbols errors like this when I
> do an  --enable-llvm=yes build:
>
> /home/seurer/mono-git/mono-llvm/mono/mini/mini-llvm-cpp.cpp:557: undefined
> reference to `llvm::createNoAAPass()'
>
> The symbols it is complaining about are in the libraries that were created
> when I compiled the mono version of llvm.  I even specified all the
> libraries directly in the LDFLAGS environment variable but the symbols
> still are not found.
>
> Any ideas what I am doing wrong?
> --
>
> -Bill Seurer
>
> ___
> 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] MonoJitInfo question

2015-08-19 Thread Zoltan Varga

Hi,

  method is valid if is_async is FALSE. aot_info is valid if is_async is
TRUE. image is an internal field, its used internally by the MonoJitInfo
code.

 Zoltan

On Wed, Aug 19, 2015 at 1:33 PM, Neale Ferguson ne...@sinenomine.net
wrote:

 In MonoJitInfo there is a union:

 union {
 MonoMethod *method;
 MonoImage *image;
 gpointer aot_info;
 gpointer tramp_info;
 } d;

 How do I know which thing to dereference against? There is a field
 is_trampoline which answers it for one of the fields but on what basis
 do I select the others?

 ___
 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] Number of elements in a fixed buffer

2015-08-11 Thread Zoltan Varga

Hi,

  Fixed buffers are a c# construct, the il code generared by the c#
compiler is not much different than the il code generated for this
declaration:

[StructLayout (LayoutKind.Sequential, Size=32)]
struct FooStruct {
   double d;
}

The Size= argument is kinda hard to handle in the runtime since it has no
counterpart in the native ABIs, the native ABIs assume that structs are
made of consecutive fields. So I think the best way to handle this is to
special case it as you said.

  Zoltan



On Tue, Aug 11, 2015 at 11:15 AM, Bill Seurer seu...@linux.vnet.ibm.com
wrote:

 The ELF ABI v2 changed how parameters that are structures are passed to
 functions and also how structures are returned.  One of the changes is that
 if a structure parameter is completely made up of 8 or fewer doubles xor
 floats then the structure is passed in FPRs instead of GPRs.

 The condition completely made up of includes nested structures and
 arrays (i.e., fixed buffers in C# parlance).  So

 public unsafe struct double_array4 {
 public fixed double f1[4];
 }

 needs to be passed in FPRs.  This is in fact the structure I was
 experimenting with in the output I showed earlier.

 I can sort of detect this by the size of the field being 32 while only
 having one double member (size of 8) but that seems clumsy and possibly
 inaccurate.  I figured that it should be possible to see that it is a fixed
 buffer (array) and that it has 4 elements.

 On 08/10/2015 11:32 AM, Zoltan Varga wrote:

 Hi,

 The class has an internal valuetype which represents the fixed buffer,
 and that valuetype has the FixedBufferAttribute.

 Runtime code generally doesn't need to care about fixed buffers, why is
 this needed ?


 

 .class public sequential ansi sealed beforefieldinit double_array4

 extends [mscorlib]System.ValueType

 {

.class sequential ansi sealed nested public beforefieldinit
 'f1__FixedBuffer0'

   extends [mscorlib]System.ValueType

{

  .pack 0

  .size 32

  .custom instance void

 [mscorlib]System.Runtime.CompilerServices.UnsafeValueTypeAttribute::.ctor()
 = ( 01 00 00 00 )

  .custom instance void

 [mscorlib]System.Runtime.CompilerServices.CompilerGeneratedAttribute::.ctor()
 = ( 01 00 00 00 )

  .field public float64 FixedElementField

} // end of class 'f1__FixedBuffer0'

.field public valuetype double_array4/'f1__FixedBuffer0' f1

.custom instance void

 [mscorlib]System.Runtime.CompilerServices.FixedBufferAttribute::.ctor(class
 [mscorlib]System.Type,


int32) = ( 01 00 5A 53 79 73 74 65 6D 2E 44 6F 75
 62 6C 65   // ..ZSystem.Double


2C 20 6D 73 63 6F 72 6C 69 62 2C 20
 56 65 72 73   // , mscorlib, Vers


69 6F 6E 3D 34 2E 30 2E 30 2E 30 2C
 20 43 75 6C   // ion=4.0.0.0, Cul


74 75 72 65 3D 6E 65 75 74 72 61 6C
 2C 20 50 75   // ture=neutral, Pu


62 6C 69 63 4B 65 79 54 6F 6B 65 6E
 3D 62 37 37   // blicKeyToken=b77


61 35 63 35 36 31 39 33 34 65 30 38
 39 04 00 00   // a5c561934e089...


00 00 00 )

 } // end of class double_array4




 On Mon, Aug 10, 2015 at 10:53 AM, Bill Seurer seu...@linux.vnet.ibm.com
 mailto:seu...@linux.vnet.ibm.com wrote:

 The only mention of FixedBufferAttribute I see is in the C# code in
 mcs.

 I looked through all the mono C code and I see several places where
 MonoCustomAttrInfo is used but no where is it doing anything with
 fixed buffers.  Is there some documentation or more examples of what
 is in the MonoCustomAttrInfo data for something like this?

 I experimented a bit and used mono_custom_attrs_from_class() to pull
 the MonoCustomAttrInfo for the class.  It looks like there are two
 attributes.

 {num_attrs = 2, cached = 0, image = 0x10566ed0, attrs = 0x1061c630}

 So looking at the two attributes I see

 attrs[0]:  {ctor = 0x1061cb10, data_size = 4, data = 0x3fffb7840e71
 \001}
 attrs[1]:  {ctor = 0x1061c990, data_size = 4, data = 0x3fffb7840e71
 \001}


 The data fields are identical and are 01 00 00 00 or maybe the other
 way around depending on what the field represents (this is a LE
 machine).

 The ctors are

 (gdb) print cinfo-attrs[0].ctor-klass-name
 $14 = 0x3fffb5b225b6 UnsafeValueTypeAttribute
 (gdb) print cinfo-attrs[1].ctor-klass-name
 $15 = 0x3fffb5b22281 CompilerGeneratedAttribute

 What do those represent?


 On 08/06/2015 12:23 PM, Zoltan Varga wrote:

 Hi,

 The type has a FixedBufferAttribute custom attribute which
 contains
 the length of the array. There are some functions in reflection.c
 like mono_custom_attrs_from_class () which can return
 information about

Re: [Mono-dev] Number of elements in a fixed buffer

2015-08-10 Thread Zoltan Varga

Hi,

The class has an internal valuetype which represents the fixed buffer, and
that valuetype has the FixedBufferAttribute.

Runtime code generally doesn't need to care about fixed buffers, why is
this needed ?



.class public sequential ansi sealed beforefieldinit double_array4

   extends [mscorlib]System.ValueType

{

  .class sequential ansi sealed nested public beforefieldinit
'f1__FixedBuffer0'

 extends [mscorlib]System.ValueType

  {

.pack 0

.size 32

.custom instance void
[mscorlib]System.Runtime.CompilerServices.UnsafeValueTypeAttribute::.ctor()
= ( 01 00 00 00 )

.custom instance void
[mscorlib]System.Runtime.CompilerServices.CompilerGeneratedAttribute::.ctor()
= ( 01 00 00 00 )

.field public float64 FixedElementField

  } // end of class 'f1__FixedBuffer0'

  .field public valuetype double_array4/'f1__FixedBuffer0' f1

  .custom instance void
[mscorlib]System.Runtime.CompilerServices.FixedBufferAttribute::.ctor(class
[mscorlib]System.Type,


  int32) = ( 01 00 5A 53 79 73 74 65 6D 2E 44 6F 75 62 6C
65   // ..ZSystem.Double


  2C 20 6D 73 63 6F 72 6C 69 62 2C 20 56 65 72
73   // , mscorlib, Vers


  69 6F 6E 3D 34 2E 30 2E 30 2E 30 2C 20 43 75
6C   // ion=4.0.0.0, Cul


  74 75 72 65 3D 6E 65 75 74 72 61 6C 2C 20 50
75   // ture=neutral, Pu


  62 6C 69 63 4B 65 79 54 6F 6B 65 6E 3D 62 37
37   // blicKeyToken=b77


  61 35 63 35 36 31 39 33 34 65 30 38 39 04 00
00   // a5c561934e089...


  00 00 00 )

} // end of class double_array4



On Mon, Aug 10, 2015 at 10:53 AM, Bill Seurer seu...@linux.vnet.ibm.com
wrote:

 The only mention of FixedBufferAttribute I see is in the C# code in mcs.

 I looked through all the mono C code and I see several places where
 MonoCustomAttrInfo is used but no where is it doing anything with fixed
 buffers.  Is there some documentation or more examples of what is in the
 MonoCustomAttrInfo data for something like this?

 I experimented a bit and used mono_custom_attrs_from_class() to pull the
 MonoCustomAttrInfo for the class.  It looks like there are two attributes.

 {num_attrs = 2, cached = 0, image = 0x10566ed0, attrs = 0x1061c630}

 So looking at the two attributes I see

 attrs[0]:  {ctor = 0x1061cb10, data_size = 4, data = 0x3fffb7840e71 \001}
 attrs[1]:  {ctor = 0x1061c990, data_size = 4, data = 0x3fffb7840e71 \001}


 The data fields are identical and are 01 00 00 00 or maybe the other way
 around depending on what the field represents (this is a LE machine).

 The ctors are

 (gdb) print cinfo-attrs[0].ctor-klass-name
 $14 = 0x3fffb5b225b6 UnsafeValueTypeAttribute
 (gdb) print cinfo-attrs[1].ctor-klass-name
 $15 = 0x3fffb5b22281 CompilerGeneratedAttribute

 What do those represent?


 On 08/06/2015 12:23 PM, Zoltan Varga wrote:

 Hi,

The type has a FixedBufferAttribute custom attribute which contains
 the length of the array. There are some functions in reflection.c
 like mono_custom_attrs_from_class () which can return information about
 it.

 Zoltan

 On Thu, Aug 6, 2015 at 12:32 PM, Bill Seurer seu...@linux.vnet.ibm.com
 mailto:seu...@linux.vnet.ibm.com wrote:

 In some code in mono/mini I need to figure out how many elements
 there are in a fixed buffer field in a struct, something like this:

  public unsafe struct double_array4 {
  public fixed double f1[4];
  }

 So I'd need to know 4.

 I can get the MonoClass of the field from the MonoFieldType and if I
 print out the name I get

 Test_double.double_array4.f1__FixedBuffer0

 so it knows it is a fixed buffer.  If I look at the fields of the
 struct in the above example there is just one and it's a double.

 So how can I figure out the number of elements?

 Thanks!



 --

 -Bill Seurer


___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Number of elements in a fixed buffer

2015-08-06 Thread Zoltan Varga

Hi,

  The type has a FixedBufferAttribute custom attribute which contains the
length of the array. There are some functions in reflection.c
like mono_custom_attrs_from_class () which can return information about it.

   Zoltan

On Thu, Aug 6, 2015 at 12:32 PM, Bill Seurer seu...@linux.vnet.ibm.com
wrote:

 In some code in mono/mini I need to figure out how many elements there are
 in a fixed buffer field in a struct, something like this:

 public unsafe struct double_array4 {
 public fixed double f1[4];
 }

 So I'd need to know 4.

 I can get the MonoClass of the field from the MonoFieldType and if I print
 out the name I get

 Test_double.double_array4.f1__FixedBuffer0

 so it knows it is a fixed buffer.  If I look at the fields of the struct
 in the above example there is just one and it's a double.

 So how can I figure out the number of elements?

 Thanks!
 --

 -Bill Seurer

 ___
 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] condition `class' not met

2015-07-28 Thread Zoltan Varga

Hi,

  It is a transient failure when using a mismatching mono runtime and
mscorlib.dll. Make sure you are using the latest version of both.

 Zoltan

On Tue, Jul 28, 2015 at 12:22 PM, Daniel Kuhne dakui...@gmail.com wrote:


 I test with a simple VB.NET Hello World console application. Just doing
 System.Console.WriteLine().

 I build with yocto using meta-mono where I am using for mono:
 c65aec96e46692ae68df34cf0849c8ff6871507e from master branch (git://
 github.com/mono/mono.git)
 and mono-basic 4.0

 Using origninal mono and mono-basic from meta-mono (not the git recipe)
 works.

 As this mailing list is not related to yocto or meta-mono, i just want to
 ask if there is any idea what can cause this issue.

 Please find my mono installation detail here:
 http://paste.ubuntu.com/11954303/
 And STRACE to the issue here: http://paste.ubuntu.com/11954389/

 # which mono
 /usr/bin/mono
 # mono --version
 Mono JIT compiler version 4.3.0 (explicit/c65aec9 Tue Jul 28 17:16:07 CEST
 2015)
 Copyright (C) 2002-2014 Novell, Inc, Xamarin Inc and Contributors.
 www.mono-project.com
 TLS:   __thread
 SIGSEGV:   normal
 Notifications: epoll
 Architecture:  x86
 Disabled:  none
 Misc:  softdebug
 LLVM:  supported, not enabled.
 GC:sgen

 Thanks!
 Daniel



 Miguel de Icaza mig...@xamarin.com schrieb am Di., 28. Juli 2015 um
 17:49 Uhr:

 yes, produce a minimal test case that exhibits the issue.

 On Tue, Jul 28, 2015 at 3:24 AM, Daniel Kuhne dakui...@gmail.com wrote:

 Hello,

 I am getting assertion:

 * Assertion at class.c:5078, condition `class' not met


 Native stacktrace:

 mono() [0x48f940]

 =
 Got a SIGABRT while executing native code. This usually indicates
 a fatal error in the mono runtime or one of the native libraries
 used by your application.
 =

 Aborted


 Any idea?
 Cheers,
 Daniel

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

Re: [Mono-dev] NRE when using pointers on armhf

2015-03-26 Thread Zoltan Varga

Hi,

 Mono sets up signal handlers in order to implement throwing null reference
exceptions. This means that some SIGSEGVs etc. get converted to
NullReferenceExceptions.

  Zoltan

On Thu, Mar 26, 2015 at 5:37 PM, Slide slide.o@gmail.com wrote:

 Yes, I can tell that the pointer is unaligned, I was wondering why I would
 get a NullReferenceException for an unaligned access. I would assume that
 mono sets up some handler or something that catches unaligned exceptions?
 Maybe not?

 On Thu, Mar 26, 2015 at 2:23 PM Brandon Perry bperry.volat...@gmail.com
 wrote:

 Could also cast to an IntPtr and check the Size property, which would
 return the number of bytes in the pointer?


 https://msdn.microsoft.com/en-us/library/system.intptr.size%28v=vs.110%29.aspx

 Might be misunderstanding the issue though.

 On Thu, Mar 26, 2015 at 4:20 PM, Zoltan Varga var...@gmail.com wrote:

 Hi,

   You can check whenever the pointer is aligned by converting it into an
 int.

  Zoltan

 On Thu, Mar 26, 2015 at 4:53 PM, Slide slide.o@gmail.com wrote:

 That's a good point! Can you tell me where in the mono code that the
 unaligned accesses are handled? I'd just like to confirm.

 Thanks!

 slide

 On Thu, Mar 26, 2015 at 1:13 PM Zoltan Varga var...@gmail.com wrote:

 Hi,

  arm might require aligned reads, i.e. 'p' should be 4 byte aligned in
 this case.

   Zoltan

 On Thu, Mar 26, 2015 at 3:28 PM, Slide slide.o@gmail.com wrote:

 I am trying to compile and use the ZeroC Ice remoting library for
 armhf to run on my RaPi 2. The compilation goes fine, but when running 
 the
 test suite I am getting a NullReferenceException on the pointer 
 assignment
 in the following code:

 fixed(byte* p = _bytes[_position])
 {
 *((float*)p) = _valBytes.floatVal; // exception here
 }

 This same code works on x86_64, so I am assuming there is something
 that is missing in the armhf implementation.

 Is there something I can do to debug what might be missing and
 provide a patch? I've never done work on the mono runtime itself.

 Thanks,

 slide


 ___
 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




 --
 http://volatile-minds.blogspot.com -- blog
 http://www.volatileminds.net -- website


___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] NRE when using pointers on armhf

2015-03-26 Thread Zoltan Varga

Hi,

 arm might require aligned reads, i.e. 'p' should be 4 byte aligned in this
case.

  Zoltan

On Thu, Mar 26, 2015 at 3:28 PM, Slide slide.o@gmail.com wrote:

 I am trying to compile and use the ZeroC Ice remoting library for armhf to
 run on my RaPi 2. The compilation goes fine, but when running the test
 suite I am getting a NullReferenceException on the pointer assignment in
 the following code:

 fixed(byte* p = _bytes[_position])
 {
 *((float*)p) = _valBytes.floatVal; // exception here
 }

 This same code works on x86_64, so I am assuming there is something that
 is missing in the armhf implementation.

 Is there something I can do to debug what might be missing and provide a
 patch? I've never done work on the mono runtime itself.

 Thanks,

 slide


 ___
 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] NRE when using pointers on armhf

2015-03-26 Thread Zoltan Varga

Hi,

  You can check whenever the pointer is aligned by converting it into an
int.

 Zoltan

On Thu, Mar 26, 2015 at 4:53 PM, Slide slide.o@gmail.com wrote:

 That's a good point! Can you tell me where in the mono code that the
 unaligned accesses are handled? I'd just like to confirm.

 Thanks!

 slide

 On Thu, Mar 26, 2015 at 1:13 PM Zoltan Varga var...@gmail.com wrote:

 Hi,

  arm might require aligned reads, i.e. 'p' should be 4 byte aligned in
 this case.

   Zoltan

 On Thu, Mar 26, 2015 at 3:28 PM, Slide slide.o@gmail.com wrote:

 I am trying to compile and use the ZeroC Ice remoting library for armhf
 to run on my RaPi 2. The compilation goes fine, but when running the test
 suite I am getting a NullReferenceException on the pointer assignment in
 the following code:

 fixed(byte* p = _bytes[_position])
 {
 *((float*)p) = _valBytes.floatVal; // exception here
 }

 This same code works on x86_64, so I am assuming there is something that
 is missing in the armhf implementation.

 Is there something I can do to debug what might be missing and provide a
 patch? I've never done work on the mono runtime itself.

 Thanks,

 slide


 ___
 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] Runtime crashing when evaluating System.Diagnostics.Process.HasExited property

2015-01-14 Thread Zoltan Varga

Hi,

  A workaround is to do:
   if (proc != Process.CurrentProcess)
  proc.HasExited

Since the bug only affects the current process.

 Zoltan

On Wed, Jan 14, 2015 at 5:53 PM, Mark McDowall markus.m...@gmail.com
wrote:

 This bug: https://bugzilla.xamarin.com/show_bug.cgi?id=25720 (now fixed
 in master) is present in mono 3.12.0 and affects, OS X, Debian/Ubuntu and
 Fedora releases. I have received several confirmations on this from users
 of my application as we use this check and have personally verified its
 presence on Ubuntu 14.04.

 Other users have confirmed things are working properly after building from
 master, so people compiling from there are unaffected.

 Wondering if there is a plan to release 3.12.1 or another updated version
 to correct this issue?

 --

 Mark McDowall

 ___
 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] Illegal instruction - mono ARM

2015-01-14 Thread Zoltan Varga

Hi,

  There could be multiple reasons for this, for example the cpu might not
match the runtime configuration, i.e. it uses hard float abi instead of a
soft float abi, it could be an old cpu that mono no longer supports (armv5
etc).

  Zoltan

On Wed, Jan 14, 2015 at 10:51 AM, oferyach o...@orpak.com wrote:

 Hi

 I compile mono with following configuration
 ./configure --host=arm-linux-gnueabi --disable-mcs-build
 --prefix=/home/MONOTEST CC=arm-linux-gnueabi-gcc CFLAGS='-march=armv5te
 -mfloat-abi=softfp '

 On target machine I can run mono --version to get
 Mono JIT compiler version 3.10.0 (tarball Thu Jan  1 17:44:51 IST 2015)
 Copyright (C) 2002-2014 Novell, Inc, Xamarin Inc and Contributors.
 www.mono-project.com
 TLS:   normal
 SIGSEGV:   normal
 Notifications: epoll
 Architecture:  armel,vfp
 Disabled:  none
 Misc:  softdebug
 LLVM:  supported, not enabled.
 GC:sgen

 But trying to run any Hello application (that runs OK on host mono) result
 in

 Illegal instruction

 Running under strace does not help to understand the problem

 Any ideas?










 --
 View this message in context:
 http://mono.1490590.n4.nabble.com/Illegal-instruction-mono-ARM-tp4665217.html
 Sent from the Mono - Dev mailing list archive at Nabble.com.
 ___
 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] Heads up: Elimination of the 2.0 and 4.0 profiles

2015-01-13 Thread Zoltan Varga

Hi,

  Merged this by running the tools themselves.

  Zoltan

On Wed, Oct 22, 2014 at 4:04 PM, akoeplinger alex.koeplin...@outlook.com
wrote:

 Sounds like a good thing ;-)

 I've got a branch in my fork where I removed the NET_2_0 ifdefs:
 https://github.com/akoeplinger/mono/compare/remove-net20-ifdefs, @kumpera
 told me a while ago that removing the 2.0 profile is on the horizon when I
 asked about why the ifdefs are still there.

 I refrained from making a PR so far because it is quite huge, do you think
 now would be a good time?

 -- Alex



 --
 View this message in context:
 http://mono.1490590.n4.nabble.com/Heads-up-Elimination-of-the-2-0-and-4-0-profiles-tp4664323p4664325.html
 Sent from the Mono - Dev mailing list archive at Nabble.com.
 ___
 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] SafeFileHandle

2015-01-12 Thread Zoltan Varga

Hi,

  This is a bug, it shouldn't happen. If you have some kind of reproducible
test case, please file a bug report with it.

Zoltan

On Mon, Jan 12, 2015 at 5:28 PM, Greg Young gregoryyou...@gmail.com wrote:

 _wapi_handle_unref_full: Attempting to unref unused handle 0x8a

 I seem to be getting this message from the runtime not sure what could
 be causing it. From some googling this appears to happen when you
 close a file handle multiple times.

 The only place close is called is :

 protected override void Dispose(bool disposing)
 {
 if(_handle == null) return;
 Flush();
 _handle.Close();
 _handle = null;
snip

 Not sure how it could be called multiple times. I don't get any issues
 on the CLR.

 Any ideas?

 Greg

 --
 Studying for the Turing test
 ___
 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] SafeFileHandle

2015-01-12 Thread Zoltan Varga

Hi,

  Yes, please file a report.

 Zoltan

On Mon, Jan 12, 2015 at 5:42 PM, Greg Young gregoryyou...@gmail.com wrote:

 I have one I can file. I figured it was something on my side though.

 Could it be the FileHandle closing itself later for a second time? Are
 there other scenarios aside from close this can happen on?

 In general SafeFileHandle is pretty painful to use since none of the
 definitions support it.

 Want me to create an issue?

 Greg

 On Tue, Jan 13, 2015 at 12:32 AM, Zoltan Varga var...@gmail.com wrote:
  Hi,
 
This is a bug, it shouldn't happen. If you have some kind of
 reproducible
  test case, please file a bug report with it.
 
  Zoltan
 
  On Mon, Jan 12, 2015 at 5:28 PM, Greg Young gregoryyou...@gmail.com
 wrote:
 
  _wapi_handle_unref_full: Attempting to unref unused handle 0x8a
 
  I seem to be getting this message from the runtime not sure what could
  be causing it. From some googling this appears to happen when you
  close a file handle multiple times.
 
  The only place close is called is :
 
  protected override void Dispose(bool disposing)
  {
  if(_handle == null) return;
  Flush();
  _handle.Close();
  _handle = null;
 snip
 
  Not sure how it could be called multiple times. I don't get any issues
  on the CLR.
 
  Any ideas?
 
  Greg
 
  --
  Studying for the Turing test
  ___
  Mono-devel-list mailing list
  Mono-devel-list@lists.ximian.com
  http://lists.ximian.com/mailman/listinfo/mono-devel-list
 
 



 --
 Studying for the Turing test

___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Heads up: Elimination of the 2.0 and 4.0 profiles

2015-01-09 Thread Zoltan Varga

Hi,

  It should be ok to do the NET_2_0 define removal now.

   Zoltan

On Wed, Oct 22, 2014 at 4:04 PM, akoeplinger alex.koeplin...@outlook.com
wrote:

 Sounds like a good thing ;-)

 I've got a branch in my fork where I removed the NET_2_0 ifdefs:
 https://github.com/akoeplinger/mono/compare/remove-net20-ifdefs, @kumpera
 told me a while ago that removing the 2.0 profile is on the horizon when I
 asked about why the ifdefs are still there.

 I refrained from making a PR so far because it is quite huge, do you think
 now would be a good time?

 -- Alex



 --
 View this message in context:
 http://mono.1490590.n4.nabble.com/Heads-up-Elimination-of-the-2-0-and-4-0-profiles-tp4664323p4664325.html
 Sent from the Mono - Dev mailing list archive at Nabble.com.
 ___
 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] Possible bugs in tramp-amd64.c when addresses span 4Gb boundary

2014-09-23 Thread Zoltan Varga

Hi,

  Mono tries to allocate all its code into the lower 32 bit part of the
address space (see MAP_32BIT in mono-codeman.c). What platform is this ?

Zoltan


On Tue, Sep 23, 2014 at 6:02 AM, Ben Carter be...@saillune.net wrote:


  Hi,

  I've been looking into a bug that I've encountered running Mono on a
 64-bit x86 system - specifically, where the ((code - start)  buf_len)
 assert in mono_arch_get_static_rgctx_trampoline() fires. This seems to be
 a result of this code:

 if guint64)addr)  32) == 0)
 buf_len = 16;
 else
 buf_len = 30;

 ...which assumes that if the destination address is 4Gb then a 32-bit
 jump will be used, which isn't true if the code being generated is more
 than ~2Gb away.

  Looking further into this, I found that this pattern appears elsewhere in
 tramp-amd64.c as well - and may explain another problem I've been seeing
 where trampolines get randomly corrupted to point to nonsensical
 addresses.

  Specifically, what I think is happening there is that
 mono_arch_create_specific_trampoline() is creating the trampoline, and
 that at the time of creation the target address is within a 32-bit jump
 from the source, so it generates a regular 32-bit CALL.

  However, mono_arch_patch_callsite() appears to only check for the target
 address being 4Gb when patching, meaning that it can (as far as I can see)
 end up doing a 32-bit InterlockedExchange() that truncates the offset in
 the case where the target is too far away. This would then result in what
 I'm seeing, which is that the trampoline code is well-formed by the target
 of the CALL is non-executable memory with nothing in it.

  Does this sound like a reasonable hypothesis? Or is there something that
 I'm missing about how trampolines operate that means that offsets of this
 nature shouldn't occur in the first place?

  Thanks for any ideas or advice!
 --
  Ben Carter - b...@saillune.net
 ___
 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] MonoDevelop not retrieving object values from debug agent

2014-09-19 Thread Zoltan Varga

Hi,

Try passing --debugger-agent=loglevel=10 to the runtime, that will cause
the debugger agent to print logging information. Also, make sure the symbol
files (.mdb files) are right next to the assemblies on the target.

Zoltan

On Fri, Sep 19, 2014 at 11:13 AM, SilentBob cinnamondon...@gmail.com
wrote:

Hi,

I have been looking at the debug agent on my target platform and getting
the
MonoDevelop debugger to connect.

All was seeming to go well, I can attach, pause, run, hit break points but
then I noticed:

- None of the local vars are showing up.
- Vars in the watch window are shown as An object refererence is
required...
- The yellow arrow that shows your position in the code when stepping is
not
visible.

Can someone please point me in the right direction with respect to
debugging
this, I don't fully understand the sequence of messaged from the debugger
to
the agent in order to request this information.

With respect to the local vars I would guess something like:

- command set: CMD_SET_TYPE, command CMD_TYPE_GET_FIELDS to retrieve a list
of the fields in a object possibly followed by:
- GET_VALUES?

With respect to the yellow arrow that should be pointing to the next line
of
code, hm, erm, urm...

Thank you for all and any assistance in advance :)

--
View this message in context:
http://mono.1490590.n4.nabble.com/MonoDevelop-not-retrieving-object-values-from-debug-agent-tp4663944.html
Sent from the Mono - Dev mailing list archive at Nabble.com.
___
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] Show thread names with ps or top?

2014-09-16 Thread Zoltan Varga

Hi,

 It should be in mono 3.6.0 and later versions.

 Zoltan

On Tue, Sep 16, 2014 at 5:59 PM, BlueWall jam...@bluewallgroup.com wrote:

 On Wed, Mar 19, 2014 at 4:01 PM, mickeyf lt;mickey@gt; wrote:

  I can show the threads associated with my process using ps or top, but
 not
  their names.
 
  Should I expect to be able to show the names of threads that were named
 in
  mono using myThread.Name = whatever?
 
  If so, how?
 
  Or is this information not available at that level?
 
  Thanks
 


 Did this make it's way into a release? If so, which version supports it?

 Thanks



 --
 View this message in context:
 http://mono.1490590.n4.nabble.com/Show-thread-names-with-ps-or-top-tp4662286p4663909.html
 Sent from the Mono - Dev mailing list archive at Nabble.com.
 ___
 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] How do I avoid these assertions?

2014-09-05 Thread Zoltan Varga

Hi,

  The mini.c:4656 assertion is a runtime bug, it happens when a method
becomes too large.

 Zoltan


On Fri, Sep 5, 2014 at 1:40 PM, mono user mono.user...@gmail.com wrote:

 Could somebody please tell me what might be triggering the assertions
 below? They happen when I generate my own IL. While the same IL works fine
 under .net, it could still be that I am doing something wrong because .net
 tends to be more forgiving than the spec requires.

 * Assertion at mini.c:4175, condition `code' not met

 * Assertion at mini.c:4656, condition `cfg-code_size - cfg-epilog_begin
  0x' not met

 On a related note, how do I run peverify please? I always seem to get the
 following. The code runs fine (which seems to suggest the libraries are
 available, which in turn seems to be the main reason for why it doesn't
 work for others who ask about it in places Google can see). I think the
 assertions might just go away if I fix whatever is reported by peverify.
 Having said that, the .net version of peverify says everything is fine.

 peverify /CLOCK /VERBOSE tmp.exe
 Could not load class with token 202
 * Assertion at class.c:5600, condition `!mono_loader_get_last_error ()'
 not met

 Many thanks.

 ___
 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] --nodebug

2014-09-04 Thread Zoltan Varga

Hi,

 nodebug means the aot compiler doesn't emit dwarf debug information, it
shouldn't cause problems for the mono debugger.

Zoltan


On Thu, Sep 4, 2014 at 3:00 PM, SilentBob cinnamondon...@gmail.com wrote:

 Hi,

 Could someone please provide an explanation of the effects of using
 --nodebug as an option to the cross-compiler. I can probably guess at what
 is going to happen but it is more useful to have an explanation from
 someone
 better positioned and more failure with the code ;-).

 I'm particularly interested in how it would affect connecting MonoDevelop
 to
 the debug-agent. How would it, if at all, impact debug functionality
 (pause,
 run, step-into, etc).

 For some background. The reason I ask is that calling the cross compiler
 with without --nodebug seems to cause a call to: mono_dwarf_writer_create()
 on our target platform which causes strange problems further down the line.

 Cheers in advance!



 --
 View this message in context:
 http://mono.1490590.n4.nabble.com/nodebug-tp4663757.html
 Sent from the Mono - Dev mailing list archive at Nabble.com.
 ___
 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] MIPS64 port status

2014-07-15 Thread Zoltan Varga

Hi,

  mips32 support used to work a few years ago, i.e. it could run a full
bootstrap and a large portion of the mono test suite. It might be somewhat
broken now but it could probably be fixed with a small amount of work.
Doing a new port, even a 32-64 bit port is a large amount of work.

  Zoltan


On Wed, Jul 16, 2014 at 1:28 AM, Jose A. Saumell saumell.j...@gmail.com
wrote:

 Hello!

 I have the task to port mono runtime to an Octeon MIPS64 based platform
 running OpenWrt.

 I have tried to cross-compile but eventually run into an error:
 
 ake[7]: Entering directory
 `/home/jose/erl/openwrt/build_dir/target-mips64_octeon_64_eglibc-2.19/mono-3.0.10/mono/utils'
 ../../doltcompile mips64-openwrt-linux-gnu-gcc -DHAVE_CONFIG_H -I.
 -I../..  -I../.. -I../../mono -I../../libgc/include -I../../eglib/src
 -I../../eglib/src
 -I/home/jose/erl/openwrt/staging_dir/target-mips64_octeon_64_eglibc-2.19/usr/include
 -I/home/jose/erl/openwrt/staging_dir/target-mips64_octeon_64_eglibc-2.19/include
 -I/home/jose/erl/openwrt/staging_dir/toolchain-mips64_octeon_64_gcc-4.6-linaro_eglibc-2.19/usr/include
 -I/home/jose/erl/openwrt/staging_dir/toolchain-mips64_octeon_64_gcc-4.6-linaro_eglibc-2.19/include
 -DGC_LINUX_THREADS -D_GNU_SOURCE -D_REENTRANT -DUSE_MMAP -DUSE_MUNMAP
 -D__default_codegen__ -DUSE_COMPILER_TLS -DNO_UNALIGNED_ACCESS  -Os -pipe
 -mno-branch-likely -march=octeon -mabi=64 -fno-caller-saves -fhonour-copts
 -Wno-error=unused-but-set-variable -msoft-float -Wformat
 -Werror=format-security  -fno-strict-aliasing -Wdeclaration-after-statement
 -Wno-unused-but-set-variable -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 -Werror-implicit-function-declaration
 -MT mono-io-portability.lo -MD -MP -MF .deps/mono-io-portability.Tpo -c -o
 mono-io-portability.lo mono-io-portability.c
 In file included from ../../mono/utils/mono-stack-unwinding.h:10:0,
  from ../../mono/metadata/object-internals.h:13,
  from ../../mono/metadata/gc-internal.h:14,
  from mono-io-portability.c:13:
 ../../mono/utils/mono-context.h:470:2: error: #error Implement
 mono-context for the current arch
 In file included from ../../mono/utils/mono-stack-unwinding.h:10:0,
  from ../../mono/metadata/object-internals.h:13,
  from ../../mono/metadata/gc-internal.h:14,
  from mono-io-portability.c:13:
 ../../mono/utils/mono-context.h:474:44: error: unknown type name
 'MonoContext'
 


 Before I dig any further I wanted to consult the developer community on
 mips64 port status and any other relevant information you could provide to
 move forward with this task.

 I appreciate your help,

 Regards, Jose

 ___
 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] Mutex Bug

2014-07-02 Thread Zoltan Varga

Hi,

  mono used to support this functionality, but the code to do that was very
problematic, and it is disabled in recent mono releases.

   Zoltan


On Wed, Jul 2, 2014 at 9:31 PM, Edward Ned Harvey (mono) 
edward.harvey.m...@clevertrove.com wrote:

 Before anything else ...  Can anybody recommend a way to do interprocess
 mutex?

 I would like to confirm this is a bug before I go create a bug report in
 bugzilla.  Can anybody please confirm both (a) you get the same behavior,
 and (b) it's not correct behavior?

 I want to make this observation as well:  The class in question is
 System.Threading.Mutex.  But on the mono class status pages, there seems to
 be no System.Threading.Mutex.  So that sounds a little suspicious to me,
 but maybe it's ok?  Or maybe I'm overlooking it somehow?

 Here is some sample source code:
 using System;
 using System.Threading;

 namespace FunWithMutex
 {
 class MainClass
 {
 static string mutexName;
 const int numThreads = 5;
 static Thread[] allThreads = new Thread[numThreads];
 public static void Main(string[] args)
 {
 mutexName = @Global\mutex-test-erihjbnkjvwiuehrnkjcxvjhwehiu;
 for (int i=0; inumThreads; i++)
 {
 allThreads[i] = new Thread(new ThreadStart(DoSomething));
 allThreads[i].Name = Thread # + i.ToString();
 allThreads[i].Start();
 }
 }
 static void DoSomething()
 {
 System.Console.Error.WriteLine(Thread.CurrentThread.Name + 
 starting...);
 using (var myMutex = new Mutex(false,mutexName))
 {
 myMutex.WaitOne();
 try
 {
 System.Console.Error.WriteLine(
 Thread.CurrentThread.Name +  running...);
 Thread.Sleep(TimeSpan.FromSeconds(5));
 System.Console.Error.WriteLine(
 Thread.CurrentThread.Name +  finished...);
 }
 finally
 {
 myMutex.ReleaseMutex();
 }
 }
 }
 }
 }


 When run in windows .NET, you launch several processes that each run the
 above code, and the Mutex will only allow one process to enter at a time.

 When run in Mono, a single process obeys the mutex correctly, but multiple
 processes that are launched concurrently, each have an apparently private
 mutex, because each process will allow a single thread to enter the mutex
 concurrently.

 In other words, the mutex *should* provide synchronization across multiple
 processes, but it doesn't.  Instead, it only provides synchronization
 across multiple threads within a single process.

 ___
 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] Running autogen.sh from outside of source tree?

2014-05-21 Thread Zoltan Varga

Hi,

  autogen.sh needs to be run from the tree, its configure+make which can be
run out-of-tree.

Zoltan


On Wed, May 21, 2014 at 9:32 PM, Chris Morgan chmor...@gmail.com wrote:

 Hello.

 I'm trying to build mono under Yocto. Recently (so I've heard) there
 were some changes such that the autotools scripts are being run from
 outside of the source tree.

 I presume this is something like:

 cd mono
 mkdir monobuild
 cd monobuild
 ../autogen.sh


 [cmorgan@localhost monobuild]$ ../autogen.sh
 --prefix=/home/cmorgan/mono-prefix
 grep: configure.in: No such file or directory
 ../autogen.sh: line 125: mono/mini/Makefile.am: No such file or directory
 ../autogen.sh: line 126: mono/metadata/Makefile.am: No such file or
 directory
 Running aclocal -I m4 -I .  ...
 aclocal: error: 'configure.ac' is required

 **Error**: aclocal failed. This may mean that you have not
 installed all of the packages you need, or you may need to
 set ACLOCAL_FLAGS to include -I $prefix/share/aclocal
 for the prefix where you installed the packages whose
 macros were not found


 This doesn't appear to work because several things in autogen.sh
 assume that the files are present in the current working directory.
 Some other steps however do use $srcdir.

 My question is whether it seems like a reasonable idea to correct
 autogen.sh to remove the assumption that builddir == sourcedir. If so
 then I'll go down this route and send a patch. If not then I'll use a
 Yocto work around for projects that don't/can't support doing that.
 I'm not big on papering over issues so I do prefer the first option
 but I didn't want to start work if it turns out that it may be a
 nearly impossible task.

 Chris
 ___
 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] Running autogen.sh from outside of source tree?

2014-05-21 Thread Zoltan Varga

Hi,

  autogen.sh is designed to generate configure and Makefile.in files into
the source tree, so they can be distributed. Generating them outside the
source tree doesn't serve much purpose imho.

Zoltan


On Wed, May 21, 2014 at 9:54 PM, Chris Morgan chmor...@gmail.com wrote:

 So I'm just trying to find out if it seems feasible, at which point
 I'll go to it for a few and see if I can do so.

 Chris


 On Wed, May 21, 2014 at 3:39 PM, Chris Morgan chmor...@gmail.com wrote:
  Hi Zoltan.
 
  No, I get that. The question is whether its possible to improve
  autogen.sh to support running out of tree by adding some more $srcdir
  entries, or whatever, at the appropriate locations.
 
  Chris
 
 
 
  On Wed, May 21, 2014 at 3:37 PM, Zoltan Varga var...@gmail.com wrote:
  Hi,
 
autogen.sh needs to be run from the tree, its configure+make which
 can be
  run out-of-tree.
 
  Zoltan
 
 
  On Wed, May 21, 2014 at 9:32 PM, Chris Morgan chmor...@gmail.com
 wrote:
 
  Hello.
 
  I'm trying to build mono under Yocto. Recently (so I've heard) there
  were some changes such that the autotools scripts are being run from
  outside of the source tree.
 
  I presume this is something like:
 
  cd mono
  mkdir monobuild
  cd monobuild
  ../autogen.sh
 
 
  [cmorgan@localhost monobuild]$ ../autogen.sh
  --prefix=/home/cmorgan/mono-prefix
  grep: configure.in: No such file or directory
  ../autogen.sh: line 125: mono/mini/Makefile.am: No such file or
 directory
  ../autogen.sh: line 126: mono/metadata/Makefile.am: No such file or
  directory
  Running aclocal -I m4 -I .  ...
  aclocal: error: 'configure.ac' is required
 
  **Error**: aclocal failed. This may mean that you have not
  installed all of the packages you need, or you may need to
  set ACLOCAL_FLAGS to include -I $prefix/share/aclocal
  for the prefix where you installed the packages whose
  macros were not found
 
 
  This doesn't appear to work because several things in autogen.sh
  assume that the files are present in the current working directory.
  Some other steps however do use $srcdir.
 
  My question is whether it seems like a reasonable idea to correct
  autogen.sh to remove the assumption that builddir == sourcedir. If so
  then I'll go down this route and send a patch. If not then I'll use a
  Yocto work around for projects that don't/can't support doing that.
  I'm not big on papering over issues so I do prefer the first option
  but I didn't want to start work if it turns out that it may be a
  nearly impossible task.
 
  Chris
  ___
  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] Show thread names with ps or top?

2014-03-29 Thread Zoltan Varga

Hi,

  Support for this is now implemented in mono master.

   Zoltan


On Wed, Mar 19, 2014 at 4:01 PM, mickeyf mic...@thesweetoasis.com wrote:

 I can show the threads associated with my process using ps or top, but not
 their names.

 Should I expect to be able to show the names of threads that were named in
 mono using myThread.Name = whatever?

 If so, how?

 Or is this information not available at that level?

 Thanks






 --
 View this message in context:
 http://mono.1490590.n4.nabble.com/Show-thread-names-with-ps-or-top-tp4662286.html
 Sent from the Mono - Dev mailing list archive at Nabble.com.
 ___
 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] crash with nunit

2014-03-25 Thread Zoltan Varga

Hi,

  Could you try with master or the mono-3.4.0-branch ? If the problem is
still there, please log a bug report with reproduction instructions/a
testcase if possible.

 Zoltan


On Tue, Mar 25, 2014 at 10:44 AM, David Schmitt da...@dasz.at wrote:

 Hi,

 I've finally updated to 3.2.8 (recompiled from debian experimental) and am
 now triggering the attached segfault approximately every second run.

 For further analysis I could run this under master; try to upgrade nunit;
 try to get more debugging symbols into the package; try to reduce the
 amount of code running to trigger the problem.

 The project is open source, so if that would be easier I can provide
 public repro steps too.


 Please advise,

 Thanks David


 ___
 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] Register allocation and overlapping registers

2014-03-25 Thread Zoltan Varga

Hi,

The mono JIT only uses double precision registers in most cases and only
uses single precision ones for temporary purposes, like to implement casts.
There were some problems with choosing these temporary registers, but they
should be fixed in 3.4.0/master.

Zoltan

On Tue, Mar 25, 2014 at 12:23 PM, SilentBob cinnamondon...@gmail.comwrote:

Hi,

I'm hoping someone can provide some insight into how the cross-compiler
handles allocating registers when the registers overlap.

I'm looking at a case on ARM where the following code:

double d = 7.21790001;
float f = (f)d;

Results in:

vcvt.f32.f64 s4, d2

Because the 'd' registers are made up of pairs of 's' registers (in this
case d2 overlaps with s4 and s5) there is the potential for collision as in
this case. The end result is that d2 changes as s4 is updated. It would be
fine if it was not for d2 then being used immediately by the next
instruction.

mono_local_regalloc () in mini-codegen.c seems to be translating
'float_conv_to_r4 R25 - R24' and ending up with dreg = 4 and sreg1 = 4
this
eventually gets emitted as above.

Thank you in advance for all help.

Regards,
Shaun

--
View this message in context:
http://mono.1490590.n4.nabble.com/Register-allocation-and-overlapping-registers-tp4662363.html
Sent from the Mono - Dev mailing list archive at Nabble.com.
___
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] (no subject)

2014-03-22 Thread Zoltan Varga

Hi,

  This is already fixed in master.

  Zoltan


On Sat, Mar 22, 2014 at 11:02 AM, Rodrigo Kumpera kump...@gmail.com wrote:

 We got a similar issue on our ARM devices.

 Alex, has this been fixed?


 On Thu, Mar 20, 2014 at 1:36 PM, Greg Young gregoryyou...@gmail.comwrote:

 Just ran with redirected output this is the issue.

 AOT [build] mcs.exe.so
 Mono Ahead of Time compiler - compiling assembly
 /home/greg/mono/mcs/class/lib/build/mcs.exe
 * Assertion at method-to-ir.c:13337, condition `load_opcode !=
 OP_LOADV_MEMBASE' not met

 Stacktrace:


 Native stacktrace:

 /home/greg/mono/mono/mini/mono() [0x4b8668]
 /lib/x86_64-linux-gnu/libpthread.so.0(+0xfbb0) [0x2ab35a4eabb0]
 /lib/x86_64-linux-gnu/libc.so.6(gsignal+0x37) [0x2ab35a72ef77]
 /lib/x86_64-linux-gnu/libc.so.6(abort+0x148) [0x2ab35a7325e8]
 /home/greg/mono/mono/mini/mono() [0x639385]
 /home/greg/mono/mono/mini/mono() [0x6394c6]
 /home/greg/mono/mono/mini/mono() [0x47974a]
 /home/greg/mono/mono/mini/mono() [0x422d8a]
 /home/greg/mono/mono/mini/mono() [0x49dd42]
 /home/greg/mono/mono/mini/mono() [0x49fb6a]

 Debug info from gdb:

 [New LWP 6528]
 [Thread debugging using libthread_db enabled]
 Using host libthread_db library /lib/x86_64-linux-gnu/libthread_db.so.1.
 0x2ab35a4ea757 in __libc_waitpid (pid=pid@entry=6529,
 stat_loc=stat_loc@entry=0x7fffc0f9740c, options=options@entry=0) at
 ../sysdeps/unix/sysv/linux/waitpid.c:40
 40  ../sysdeps/unix/sysv/linux/waitpid.c: No such file or directory.
   Id   Target Id Frame
   2Thread 0x2ab35d6b6700 (LWP 6528) mono sem_wait () at
 ../nptl/sysdeps/unix/sysv/linux/x86_64/sem_wait.S:85
 * 1Thread 0x2ab359be6500 (LWP 6519) mono 0x2ab35a4ea757 in
 __libc_waitpid (pid=pid@entry=6529, stat_loc=stat_loc@entry=0x7fffc0f9740c,
 options=options@entry=0) at ../sysdeps/unix/sysv/linux/waitpid.c:40

 Thread 2 (Thread 0x2ab35d6b6700 (LWP 6528)):
 #0  sem_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/sem_wait.S:85
 #1  0x0062fd57 in mono_sem_wait (sem=sem@entry=0x9834c0
 finalizer_sem, alertable=alertable@entry=1) at mono-semaphore.c:119
 #2  0x005ad9ea in finalizer_thread (unused=unused@entry=0x0) at
 gc.c:1073
 #3  0x0058fe0b in start_wrapper_internal (data=0x1401fd0) at
 threads.c:647
 #4  start_wrapper (data=0x1401fd0) at threads.c:692
 #5  0x0063482e in inner_start_thread (arg=0x7fffc0f98cd0) at
 mono-threads-posix.c:94
 #6  0x2ab35a4e2f6e in start_thread (arg=0x2ab35d6b6700) at
 pthread_create.c:311
 #7  0x2ab35a7f29cd in clone () at
 ../sysdeps/unix/sysv/linux/x86_64/clone.S:113

 Thread 1 (Thread 0x2ab359be6500 (LWP 6519)):
 #0  0x2ab35a4ea757 in __libc_waitpid (pid=pid@entry=6529,
 stat_loc=stat_loc@entry=0x7fffc0f9740c, options=options@entry=0) at
 ../sysdeps/unix/sysv/linux/waitpid.c:40
 #1  0x004b86f5 in mono_handle_native_sigsegv (signal=optimized
 out, ctx=optimized out) at mini-exceptions.c:2305
 #2  signal handler called
 #3  0x2ab35a72ef77 in __GI_raise (sig=sig@entry=6) at
 ../nptl/sysdeps/unix/sysv/linux/raise.c:56
 #4  0x2ab35a7325e8 in __GI_abort () at abort.c:90
 #5  0x00639385 in monoeg_g_logv (log_domain=log_domain@entry=0x0,
 log_level=log_level@entry=G_LOG_LEVEL_ERROR, format=format@entry=0x641ee8
 * Assertion at %s:%d, condition `%s' not met\n, 
 args=args@entry=0x7fffc0f98338)
 at goutput.c:175
 #6  0x006394c6 in monoeg_assertion_message 
 (format=format@entry=0x641ee8
 * Assertion at %s:%d, condition `%s' not met\n) at goutput.c:195
 #7  0x0047974a in mono_spill_global_vars (cfg=cfg@entry=0x5ff3e90,
 need_local_opts=need_local_opts@entry=0x7fffc0f9877c) at
 method-to-ir.c:13337
 #8  0x00422d8a in mini_method_compile (method=method@entry=0x5788730,
 opts=optimized out, domain=optimized out, flags=flags@entry=JIT_FLAG_AOT,
 parts=parts@entry=0) at mini.c:5610
 #9  0x0049dd42 in compile_method (acfg=acfg@entry=0x1409f10,
 method=0x5788730) at aot-compiler.c:6513
 #10 0x0049fb6a in compile_method (method=optimized out,
 acfg=0x1409f10) at aot-compiler.c:8426
 #11 compile_methods (acfg=optimized out) at aot-compiler.c:8428
 #12 mono_compile_assembly (ass=ass@entry=0x1404dd0, 
 opts=opts@entry=37023,
 aot_options=aot_options@entry=0x7fffc0f9b31a
 bind-to-runtime-version,outfile=./../../class/lib/build//mcs.exe.so)
 at aot-compiler.c:8835
 #13 0x0048dadc in main_thread_handler (user_data=synthetic
 pointer) at driver.c:1045
 #14 mono_main (argc=6, argv=optimized out) at driver.c:2024
 #15 0x2ab35a719de5 in __libc_start_main (main=0x419800 main,
 argc=6, ubp_av=0x7fffc0f990b8, init=optimized out, fini=optimized out,
 rtld_fini=optimized out, stack_end=0x7fffc0f990a8) at libc-start.c:260
 #16 0x00419aac in _start ()

 =
 Got a SIGABRT while executing native code. This usually

Re: [Mono-dev] Question about issue building basic.exe and mscorlib paths

2014-03-02 Thread Zoltan Varga

Hi,

  mono requires an existing mono installation to work, and will only fall
back to monolite if it is missing. If you want it to use monolite, then
remove the existing mono installation from the PATH.

Zoltan


On Sun, Mar 2, 2014 at 8:24 AM, Alex J Lennon ajlen...@dynamicdevices.co.uk
 wrote:

 Hi,

 I'm updating a recipe for Yocto/Openembedded layer, meta-mono, which
 cross-compiles Mono 3.2.8 for embedded Linux targets.

 I am using an Ubuntu 12.04 LTS host for build and previously this has
 worked well with the default mono support available in precise, version
 2.10 I think.

 (NB the Yocto  build environment shouldn't have any external
 dependencies on the  host version of mono as it is building its own
 native, host, build  prior to the cross-compiled build).

 When I updated the host to use Mono  3.2.1 from ppa:directhex/monoxide
 for some other work I was doing, I started getting unexpected build
 problems with the meta-mono recipe.

 From what I've been able to track down, what is happening is that the
 build process is building basic/basic.exe from the basic profile. I'm
 not sure why this is happening as we already have the bootstrap
 basic.exe in monolite.

 This new basic.exe should have a dependency on the apropriate
 mscorlib.dl that is being built with it, but instead has a dependency on
 an external mscorlib.dll on the host. With Mono 3.2.1 installed this
 dependency is on /usr/lib/mono/4.5/mscorlib.dll

 As a result of this dependency when the new basic.exe is executed we get
 various warnings of the form,

 ../corlib/Mono/DataConverter.cs(759,25): warning CS0436: The type
 `Mono.DataConverter' conflicts with the imported type of same name'.
 Ignoring the imported type definition
 ../../build/common/MonoTODOAttribute.cs(38,17): (Location of the symbol
 related to previous warning)
 /usr/lib/mono/4.5/mscorlib.dll (Location of the symbol related to
 previous warning)

 Then an error

 MCS [build] mscorlib.dll
 Unhandled Exception:
 System.TypeLoadException: Could not load type
 'Mono.CSharp.CommandLineParser' from assembly 'basic, Version=3.2.8.0,
 Culture=neutral, PublicKeyToken=null'.
 [ERROR] FATAL UNHANDLED EXCEPTION: System.TypeLoadException: Could not
 load type 'Mono.CSharp.CommandLineParser' from assembly 'basic,
 Version=3.2.8.0, Culture=neutral, PublicKeyToken=null'.
 make[8]: *** [../../class/lib/build/tmp/mscorlib.dll] Error 1

 I took a look at the basic profile make file for missing paths and I
 think it may be missing the required dependency path. When I added this
 in the build works,

 --- 3.2.8-r0/mcs/build/profiles/basic.make.org  2014-03-01
 17:51:52.904670729 +
 +++ 3.2.8-r0/mcs/build/profiles/basic.make  2014-03-01
 17:46:50.476669939 +
 @@ -12,7 +12,7 @@
  PROFILE_RUNTIME = $(with_mono_path_monolite) $(RUNTIME)
  BOOTSTRAP_MCS = $(PROFILE_RUNTIME) $(RUNTIME_FLAGS) $(MONOLITE_MCS) -sdk:2
  else
 -PROFILE_RUNTIME = $(EXTERNAL_RUNTIME)
 +PROFILE_RUNTIME = ${with_mono_path) $(EXTERNAL_RUNTIME)
  BOOTSTRAP_MCS = $(EXTERNAL_MCS)
  endif

 Could somebody please comment on whether this makes sense? If so I'd be
 happy to provide the patch to you in whatever format is required.

 Thanks  Best Regards,

 Alex Lennon
 Dynamic Devices Ltd


 ___
 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] mono-master: windows fixes

2014-02-03 Thread Zoltan Varga

Hi,

  Applied a variant of these to mono master as
83139b20e228e6f41d346a70a84a8c00ee64b2c2/0c279149286a35474068190238574d1ca57a00be.

Zoltan


On Mon, Feb 3, 2014 at 9:23 PM, Frank Fuchs fk.fu...@googlemail.com wrote:

 Hi, I just checked if I can build the runtime of mono-master on Windows 7
 (64bit) using mingw-w64-tdm (gcc 4.8.1) + msys. Build works fine using an
 external boehm and adding the following patches:





 Now I was not able to really test the patches (due to a lack of a
 up-to-date
 corelib),
 but I think they are straight-forward. The first patch also is inherently
 64
 bit proof.

 Thx!



 --
 View this message in context:
 http://mono.1490590.n4.nabble.com/mono-master-windows-fixes-tp4661840.html
 Sent from the Mono - Dev mailing list archive at Nabble.com.
 ___
 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] EntryPointNotFoundException: CreateZStream

2013-11-24 Thread Zoltan Varga

Hi,

So the problem is that recent mono packages are missing the
MonoPosixHelper.dll file for some reason, and the system has an old
version lying around in some other package, leading to this error.

 Zoltan



On Sun, Nov 24, 2013 at 5:43 PM, Marcelo Zabani mzab...@gmail.com wrote:

 It seems like I'm not authorized to view that bug


 On Fri, Nov 22, 2013 at 6:38 PM, Zoltan Varga var...@gmail.com wrote:

 Hi,

   Probably:
 https://bugzilla.xamarin.com/show_bug.cgi?id=15507

Zoltan


 On Fri, Nov 22, 2013 at 8:19 PM, Marcelo Zabani mzab...@gmail.comwrote:

 I'm running into the following exception:

 *System.EntryPointNotFoundException: CreateZStream at (wrapper
 managed-to-native) System.IO.Compression.DeflateStreamNative:CreateZStream
 (System.IO.Compression.CompressionMode,bool,System.IO.Compression.DeflateStreamNative/UnmanagedReadOrWrite,intptr)
 at System.IO.Compression.DeflateStreamNative.Create (System.IO.Stream
 compressedStream, CompressionMode mode, Boolean gzip) [0x0] in
 filename unknown:0 at System.IO.Compression.DeflateStream..ctor
 (System.IO.Stream compressedStream, CompressionMode mode, Boolean
 leaveOpen, Boolean gzip) [0x0] in filename unknown:0 *

 with Mono 3.2.3 on Windows 8.

 I'm running a console project in cmd, just plain old mono app.exe.
 What could this be?

 Thanks,
 Marcelo.

 ___
 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] EntryPointNotFoundException: CreateZStream

2013-11-22 Thread Zoltan Varga

Hi,

  Probably:
https://bugzilla.xamarin.com/show_bug.cgi?id=15507

   Zoltan


On Fri, Nov 22, 2013 at 8:19 PM, Marcelo Zabani mzab...@gmail.com wrote:

 I'm running into the following exception:

 *System.EntryPointNotFoundException: CreateZStream at (wrapper
 managed-to-native) System.IO.Compression.DeflateStreamNative:CreateZStream
 (System.IO.Compression.CompressionMode,bool,System.IO.Compression.DeflateStreamNative/UnmanagedReadOrWrite,intptr)
 at System.IO.Compression.DeflateStreamNative.Create (System.IO.Stream
 compressedStream, CompressionMode mode, Boolean gzip) [0x0] in
 filename unknown:0 at System.IO.Compression.DeflateStream..ctor
 (System.IO.Stream compressedStream, CompressionMode mode, Boolean
 leaveOpen, Boolean gzip) [0x0] in filename unknown:0 *

 with Mono 3.2.3 on Windows 8.

 I'm running a console project in cmd, just plain old mono app.exe.
 What could this be?

 Thanks,
 Marcelo.

 ___
 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] mono from git will not build on cygwin 32

2013-11-19 Thread Zoltan Varga

Hi,

  This is a bug in the mingw header files, two header define the same type
(PEXECUTION_STATE). This happens on some systems, and doesn't happen on
others. The only workaround is to fix the header files by hand, i.e. rename
one of the definitions to PEXECUTION_STATE2 or something.

  Zoltan


On Tue, Nov 19, 2013 at 7:20 AM, mobin.seven mobin.se...@live.com wrote:

 I have done ALL above BUT still getting this:
 socket-io.c:2353:2: warning: pointer targets in passing argument 7 of
 'WSAIoctl'
  differ in signedness [-Wpointer-sign]
 In file included from ../../mono/io-layer/io-layer.h:24:0,
  from ./process.h:17,
  from
 /usr/i686-pc-mingw32/sys-root/mingw/include/unistd.h:37,
  from socket-io.c:24:
 /usr/i686-pc-mingw32/sys-root/mingw/include/winsock2.h:1178:32: note:
 expected '
 LPDWORD' but argument is of type 'glong *'
   CC   libmonoruntime_la-process.lo
 In file included from process.c:37:0:
 /usr/i686-pc-mingw32/sys-root/mingw/include/ddk/ntapi.h:49:15: error:
 conflictin
 g types for 'PEXECUTION_STATE'
 In file included from
 /usr/i686-pc-mingw32/sys-root/mingw/include/windows.h:62:0
 ,
  from
 /usr/i686-pc-mingw32/sys-root/mingw/include/winsock2.h:40,

  from ../../mono/io-layer/io-layer.h:24,
  from ../../mono/metadata/domain-internals.h:15,
  from ../../mono/metadata/metadata-internals.h:8,
  from ../../mono/metadata/class-internals.h:10,
  from ../../mono/metadata/object-internals.h:8,
  from process.c:16:
 /usr/i686-pc-mingw32/sys-root/mingw/include/winbase.h:1973:33: note:
 previous de
 claration of 'PEXECUTION_STATE' was here
 process.c: In function
 'ves_icall_System_Diagnostics_Process_GetProcesses_intern
 al':
 process.c:912:3: warning: passing argument 1 of 'EnumProcesses' from
 incompatibl
 e pointer type [enabled by default]
 In file included from ../../mono/io-layer/io-layer.h:34:0,
  from ../../mono/metadata/domain-internals.h:15,
  from ../../mono/metadata/metadata-internals.h:8,
  from ../../mono/metadata/class-internals.h:10,
  from ../../mono/metadata/object-internals.h:8,
  from process.c:16:
 /usr/i686-pc-mingw32/sys-root/mingw/include/psapi.h:108:13: note: expected
 'DWOR
 D *' but argument is of type 'guint32 *'
 Makefile:2168: recipe for target 'libmonoruntime_la-process.lo' failed
 make[3]: *** [libmonoruntime_la-process.lo] Error 1
 make[3]: Leaving directory '/usr/src/Mono-3.2.3/mono/metadata'
 Makefile:380: recipe for target 'all-recursive' failed
 make[2]: *** [all-recursive] Error 1
 make[2]: Leaving directory '/usr/src/Mono-3.2.3/mono'
 Makefile:460: recipe for target 'all-recursive' failed
 make[1]: *** [all-recursive] Error 1
 make[1]: Leaving directory '/usr/src/Mono-3.2.3'
 Makefile:387: recipe for target 'all' failed
 make: *** [all] Error 2

 Is your problem solved? what should I do?



 --
 View this message in context:
 http://mono.1490590.n4.nabble.com/mono-from-git-will-not-build-on-cygwin-32-tp4660749p4661343.html
 Sent from the Mono - Dev mailing list archive at Nabble.com.
 ___
 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] SGEN support when cross compiling

2013-08-26 Thread Zoltan Varga

Hi,

  It might be easier to compile on the device itself using distcc+a cross
compiler.

  Zoltan


On Tue, Aug 27, 2013 at 1:36 AM, Bassam Tabbara bas...@symform.com wrote:

  Thanks Rodrigo. Is there a trick then to bypass the __thread check
 during configuration?

  ./configure --host=armv5te-unknown-linux-gnueabi

  Fails with:

  configure: error: cannot run test program while cross compiling

  I worked around it with the following:


 https://github.com/symform/mono/commit/fe5c582a1a2d241f368c86081b3cb7ea53994f51

  Do others not see this?

   From: Rodrigo Kumpera kump...@gmail.com
 Date: Monday, August 26, 2013 4:30 PM
 To: Bassam Tabbara bas...@symform.com
 Cc: mono-devel-list@lists.ximian.com mono-devel-list@lists.ximian.com
 Subject: Re: [Mono-dev] SGEN support when cross compiling

   sgen works fine on ARM and so does cross compiling to it.


 On Mon, Aug 26, 2013 at 6:19 PM, Bassam Tabbara bas...@symform.comwrote:

  Hello,

  I'm working in mono master, and it looks like sgen is not support when
 cross compiling. Sgen requiren with-tls=__thread and during configuration a
 check is made if __thread is functioning and that fails with the following
 error when cross compiling:

  configure: error: cannot run test program while cross compiling
 [

  I can work around this but disable the check during configuration, but
 I'm now wondering whether anyone is using sgen on ARM platforms? Are you
 cross compiling for those platforms? I must be missing something simple
 here.

  Thanks!
  Bassam

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

Re: [Mono-dev] Failing to compile mono on Windows cygwin

2013-08-25 Thread Zoltan Varga

Hi,

  mono master can be built on windows using the mingw cross-compiler gcc,
i.e. install the mingw-gcc package, and configure using:

./autogen.sh --host=i686-pc-mingw32

  Zoltan


On Mon, Aug 26, 2013 at 1:20 AM, Bryan Crotaz 
bryan.cro...@silvercurve.co.uk wrote:

 I have gcc 4.7.3.  You say I have to install gcc v3 but no clue as to
 where I might find such a mythical beast.  Do you have a url for the
 installer?

 Bryan


 On 26 August 2013 00:01, jean-michel.perr...@csiro.au wrote:

 A blank line is certainly not the expected behaviour of a Mono 'make'. I
 tried to checkout the master branch to double check what you describe but
 encountered instead fatal: Not a git repository for an external module.
 Seen that git annoyance in the past, can fix but I don't have enough time.
 I very much doubt the cygwin build is as broken as you describe.

 I'll forward you in a separate email a PDF of a personal wiki page I have
 to remind myself how to go about compiling Mono on Windows, in case this
 helps.

 You certainly to not need all cygwin packages. From my notes what I
 typically need to add to a rather Spartan cygwin setup:
  “autogen.sh requires a few additional packages to be installed in
 cygwin: bison, libtools, automake of course, and the gettext packages (incl
 devel packages), or you get a configure: error: msgfmt not found. You need
 to install the 'gettext' package, or pass --enable-nls=no to autogen.sh or
 configure”

 Not sure exactly what you are after with Alternatively, where can I
 download a zip of the binaries and VS project so that I can start adding
 tests and fixing bugs?. Which binaries: the mono runtime and/or including
 the framework (C# assemblies)?

 Assuming you'd be OK to recompile the mono runtime and the C# assemblies
 (sounds like you have VS), the core mono runtime (mono-2.0.dll) is
 relatively easy to build in VS, though sometimes broken and VisualCPP
 and/or C code needs update/adjustments to get things going. Look under the
 'msvc' folder (past outdated instructions). One can definitely set up a
 mono runtime in debug mode in VS.

 You can, with a fair bit of work, get the VS project files/solutions:
 look at msvc/scripts/README. You can even build most of them, though
 there are quirks. However to my knowledge you cannot debug these through
 VS, unless something like Mono Tools for Visual Studio is alive and
 maintained unknown to me.

 FYI I have a fork intended to better document and improve the VS build
 use cases, but it is a draft and I struggle to find time for it
 https://github.com/jmp75/mono/tree/msvc_build_20130604

 By the way if someone had advice on a feasible procedure and setup with
 MonoDevelop for contributors to Mono itself, I for one would be interested.

 Hope this helps.
 J-M



 From: mono-devel-list-boun...@lists.ximian.com [mailto:
 mono-devel-list-boun...@lists.ximian.com] On Behalf Of Bryan Crotaz
 Sent: Sunday, 25 August 2013 9:43 PM
 To: mono-devel-list@lists.ximian.com
 Subject: [Mono-dev] Failing to compile mono on Windows cygwin

 I've found a bug in mono, logged it, and created a unit test for it.  Now
 I want to add the test to the Mono test suite, and fix it.

 So I've now spent 2 days attempting to work out how to get cygwin to
 work, ending up installing ALL the packages to get autogen to run
 successfully.

 I'm now stuck.

 I run make and get nothing.  No error, just a blank line and back to the
 prompt.  I'm assuming this isn't correct.  What do I do to fix this?


 Alternatively, where can I download a zip of the binaries and VS project
 so that I can start adding tests and fixing bugs?

 Bryan




 --
 Bryan Crotaz
 Managing Director
 Silver Curve

 ___
 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] Patch sgen-stw.c update_current_thread_stack windows mono 3.2.1

2013-08-25 Thread Zoltan Varga

Hi,

  This was already fixed in a different way in mono master.

 Zoltan


On Sun, Aug 25, 2013 at 4:02 PM, Vardar Sahin sakirs...@gmail.com wrote:

 Hello Mono Team,

 i found a bug which i want to submit a patch for.

 The bug is in update_current_thread_stack in sgen-stw.c.

 This line does not work as intended.

 ARCH_STORE_REGS (reg_ptr);
 memcpy (info-regs, reg_ptr, sizeof (info-regs));

 for some reason the pointer address gets the content of ebi register of
 the cpu. So after
 ARCH_STORE_REGS (reg_ptr);

 reg_ptr directs to the content of ebi an loses its orginal pointer
 address.

 Before that line reg_ptr  is defined as fallows:
 void *reg_ptr = cur_thread_regs;

 In theory it should work that way. But it does not.

 The fix is pretty simple use cur_thread_regs instand of reg_ptr  and it
 works.

 Best regards
 Sahin Vardar



 ___
 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] Assert in mini-arm.c

2013-08-13 Thread Zoltan Varga

Hi,

  This is a JIT problem, it will be hard to track down without a testcase.
You can try changing this line in mono/utils/mono-codeman.c:

#define BIND_ROOM 8

to

#define BIND_ROOM 4

It might fix the issue.

   Zoltan


On Tue, Aug 13, 2013 at 7:44 AM, Bassam Tabbara bas...@symform.com wrote:

  Folks,

  Any insights into why the assert would trigger? Is this a resource
 exhaustion issue, or is specific to certain code that is being JITed? I
 need someone to point me in the right direction. I'm able to reproduce this
 but only in the context of our application. This did not happen with the
 mono-2-10 branch.

  Thanks!
 Bassam

   From: Bassam Tabbara bas...@symform.com
 Date: Friday, August 9, 2013 10:36 AM
 To: mono-devel-list@lists.ximian.com mono-devel-list@lists.ximian.com
 Subject: [Mono-dev] Assert in mini-arm.c

   Hello,

  I'm seeing the following assert on an armv5tel using latest from master:

  http://pastebin.com/raw.php?i=CLDXxiPy

  I'm trying to get an isolated repro but it proving to be elusive. In our
 full test runs we see this all the time.

  Any tips on how to debug this further?

  Thanks!
 Bassam

 ___
 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] Assert in mini-arm.c

2013-08-13 Thread Zoltan Varga

Hi,

Can you see whats at 'code' and 'target' at frame #3, i.e.
x/10i code
x/10i target

 Zoltan


On Wed, Aug 14, 2013 at 1:48 AM, Bassam Tabbara bas...@symform.com wrote:

  Unfortunately that did not help. Still seeing the problem. I'm still
 working on a test case but I'm not having much luck so far in getting an
 isolated repro.

  I was able to get a debugger attached to the process right when
 handle_thunk asserts, and there were 6 threads with the following call
 stack:

  Thread 5 (Thread 0x558ff460 (LWP 9201)):
 #0  handle_thunk (method=0x0, domain=0x4ce44e58, absolute=1,
 code=0x427f8f08 Q\364\377\353\367\377\377\352,
 target=0x511f02a0 \r\300\240\341\360_-\351(\320M\342k\323\377\353,
 dyn_code_mp=0x0) at mini-arm.c:3373
 #1  0x00172764 in arm_patch_general (method=0x0, domain=0x0,
 code=0x427f8f08 Q\364\377\353\367\377\377\352,
 target=0x511f02a0 \r\300\240\341\360_-\351(\320M\342k\323\377\353,
 dyn_code_mp=0x0) at mini-arm.c:3425
 #2  0x00172ca8 in arm_patch (code=0x427f8f08
 Q\364\377\353\367\377\377\352, target=0x511f02a0
 \r\300\240\341\360_-\351(\320M\342k\323\377\353) at mini-arm.c:3536
 #3  0x001830bc in mono_arch_patch_callsite (method_start=0x427f8e90
 \r\300\240\341\360_-\351(\320M\342, code_ptr=0x427f8f0c
 \367\377\377\352,
 addr=0x511f02a0 \r\300\240\341\360_-\351(\320M\342k\323\377\353) at
 tramp-arm.c:87
 #4  0x0012c5c8 in common_call_trampoline (regs=0x558fd090, code=0x427f8f0c
 \367\377\377\352, m=0x2a08a000, tramp=0x2e4bcd80 x\320\217U, vt=0x0,
 vtable_slot=0x0,
 need_rgctx_tramp=0) at mini-trampolines.c:673
 #5  0x0012c67c in mono_magic_trampoline (regs=0x558fd090, code=0x427f8f0c
 \367\377\377\352, arg=0x2a08a000, tramp=0x2e4bcd80 x\320\217U) at
 mini-trampolines.c:690
 #6  0x403f5060 in ?? ()
 #7  0x403f5060 in ?? ()

  All 6 threads where in a trampoline. The method in frame 4 was
 mono_thread_interruption_checkpoint for all six threads.

  Does this give you any more clues into what is going on?

  This is blocking our upgrade to mono-3-0 unfortunately. Any help will be
 greatly appreciated.

   From: Zoltan Varga var...@gmail.com
 Date: Tuesday, August 13, 2013 3:20 AM
 To: Bassam Tabbara bas...@symform.com
 Cc: mono-devel-list@lists.ximian.com mono-devel-list@lists.ximian.com
 Subject: Re: [Mono-dev] Assert in mini-arm.c

   Hi,

This is a JIT problem, it will be hard to track down without a
 testcase. You can try changing this line in mono/utils/mono-codeman.c:

  #define BIND_ROOM 8

  to

  #define BIND_ROOM 4

  It might fix the issue.

 Zoltan


 On Tue, Aug 13, 2013 at 7:44 AM, Bassam Tabbara bas...@symform.comwrote:

  Folks,

  Any insights into why the assert would trigger? Is this a resource
 exhaustion issue, or is specific to certain code that is being JITed? I
 need someone to point me in the right direction. I'm able to reproduce this
 but only in the context of our application. This did not happen with the
 mono-2-10 branch.

  Thanks!
 Bassam

   From: Bassam Tabbara bas...@symform.com
 Date: Friday, August 9, 2013 10:36 AM
 To: mono-devel-list@lists.ximian.com mono-devel-list@lists.ximian.com
 Subject: [Mono-dev] Assert in mini-arm.c

   Hello,

  I'm seeing the following assert on an armv5tel using latest from master:

  http://pastebin.com/raw.php?i=CLDXxiPy

  I'm trying to get an isolated repro but it proving to be elusive. In
 our full test runs we see this all the time.

  Any tips on how to debug this further?

  Thanks!
  Bassam

 ___
 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] Assert in mini-arm.c

2013-08-13 Thread Zoltan Varga

I meant frame #2, i.e.
#2  0x00172ca8 in arm_patch

  Zoltan


On Wed, Aug 14, 2013 at 2:14 AM, Zoltan Varga var...@gmail.com wrote:

 Hi,

 Can you see whats at 'code' and 'target' at frame #3, i.e.
 x/10i code
 x/10i target

  Zoltan


 On Wed, Aug 14, 2013 at 1:48 AM, Bassam Tabbara bas...@symform.comwrote:

  Unfortunately that did not help. Still seeing the problem. I'm still
 working on a test case but I'm not having much luck so far in getting an
 isolated repro.

  I was able to get a debugger attached to the process right when
 handle_thunk asserts, and there were 6 threads with the following call
 stack:

  Thread 5 (Thread 0x558ff460 (LWP 9201)):
 #0  handle_thunk (method=0x0, domain=0x4ce44e58, absolute=1,
 code=0x427f8f08 Q\364\377\353\367\377\377\352,
 target=0x511f02a0 \r\300\240\341\360_-\351(\320M\342k\323\377\353,
 dyn_code_mp=0x0) at mini-arm.c:3373
 #1  0x00172764 in arm_patch_general (method=0x0, domain=0x0,
 code=0x427f8f08 Q\364\377\353\367\377\377\352,
 target=0x511f02a0 \r\300\240\341\360_-\351(\320M\342k\323\377\353,
 dyn_code_mp=0x0) at mini-arm.c:3425
 #2  0x00172ca8 in arm_patch (code=0x427f8f08
 Q\364\377\353\367\377\377\352, target=0x511f02a0
 \r\300\240\341\360_-\351(\320M\342k\323\377\353) at mini-arm.c:3536
 #3  0x001830bc in mono_arch_patch_callsite (method_start=0x427f8e90
 \r\300\240\341\360_-\351(\320M\342, code_ptr=0x427f8f0c
 \367\377\377\352,
 addr=0x511f02a0 \r\300\240\341\360_-\351(\320M\342k\323\377\353) at
 tramp-arm.c:87
 #4  0x0012c5c8 in common_call_trampoline (regs=0x558fd090,
 code=0x427f8f0c \367\377\377\352, m=0x2a08a000, tramp=0x2e4bcd80
 x\320\217U, vt=0x0, vtable_slot=0x0,
 need_rgctx_tramp=0) at mini-trampolines.c:673
 #5  0x0012c67c in mono_magic_trampoline (regs=0x558fd090, code=0x427f8f0c
 \367\377\377\352, arg=0x2a08a000, tramp=0x2e4bcd80 x\320\217U) at
 mini-trampolines.c:690
 #6  0x403f5060 in ?? ()
 #7  0x403f5060 in ?? ()

  All 6 threads where in a trampoline. The method in frame 4 was
 mono_thread_interruption_checkpoint for all six threads.

  Does this give you any more clues into what is going on?

  This is blocking our upgrade to mono-3-0 unfortunately. Any help will
 be greatly appreciated.

   From: Zoltan Varga var...@gmail.com
 Date: Tuesday, August 13, 2013 3:20 AM
 To: Bassam Tabbara bas...@symform.com
 Cc: mono-devel-list@lists.ximian.com mono-devel-list@lists.ximian.com
 Subject: Re: [Mono-dev] Assert in mini-arm.c

   Hi,

This is a JIT problem, it will be hard to track down without a
 testcase. You can try changing this line in mono/utils/mono-codeman.c:

  #define BIND_ROOM 8

  to

  #define BIND_ROOM 4

  It might fix the issue.

 Zoltan


 On Tue, Aug 13, 2013 at 7:44 AM, Bassam Tabbara bas...@symform.comwrote:

  Folks,

  Any insights into why the assert would trigger? Is this a resource
 exhaustion issue, or is specific to certain code that is being JITed? I
 need someone to point me in the right direction. I'm able to reproduce this
 but only in the context of our application. This did not happen with the
 mono-2-10 branch.

  Thanks!
 Bassam

   From: Bassam Tabbara bas...@symform.com
 Date: Friday, August 9, 2013 10:36 AM
 To: mono-devel-list@lists.ximian.com mono-devel-list@lists.ximian.com
 
 Subject: [Mono-dev] Assert in mini-arm.c

   Hello,

  I'm seeing the following assert on an armv5tel using latest from
 master:

  http://pastebin.com/raw.php?i=CLDXxiPy

  I'm trying to get an isolated repro but it proving to be elusive. In
 our full test runs we see this all the time.

  Any tips on how to debug this further?

  Thanks!
  Bassam

 ___
 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] build error on latest mono from git

2013-08-09 Thread Zoltan Varga

Should be fixed now.

 Zoltan


On Fri, Aug 9, 2013 at 8:11 AM, Venkatesh Mahadev 
venkatesh.maha...@gmail.com wrote:

 Hi,

 I pulled the latest sources for mono from git, ran autogen.sh and then
 make. I am seeing this build error. I've attached the output from make, and
 am hoping someone could help me with this error.

 [~/Projects/mono] $ uname -a
 Linux minchu 3.9.11-200.fc18.x86_64 #1 SMP Mon Jul 22 21:04:50 UTC 2013
 x86_64 x86_64 x86_64 GNU/Linux

 -Venkatesh


 ___
 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] Mono 3.2.1 OS X Build on Mountain Lion with threads failure [libmonoruntime_la-threads.lo] Error 1

2013-08-07 Thread Zoltan Varga

Hi,

 Instead of CFLAGS=-m32, try configure --build=i386-apple-darwin11.2.0 or
something.

 Zoltan


On Wed, Aug 7, 2013 at 4:13 AM, Michael Franz mvfr...@gmail.com wrote:

 Hi,

 I download the latest tar file 
 (mono-3.2.1.tar.bz2http://download.mono-project.com/sources/mono/mono-3.2.1.tar.bz2)
  and
 followed the OS X build instructions.  The 32 bit build is failing, similar
 to this old thread
 http://mono.1490590.n4.nabble.com/mono-io-layer-mono-mutex-h-Errors-in-Current-Master-td3515845.html#a3515916.
   The 64 bit build works just fine.  How do I get more details of the
 exact error?

   $ CC='cc -m32' ./configure --prefix=DIR --enable-nls=no
   $ make

 Making all in metadata
   CC   libmonoruntime_la-threads.lo
 make[3]: *** [libmonoruntime_la-threads.lo] Error 1
 make[2]: *** [all-recursive] Error 1
 make[1]: *** [all-recursive] Error 1
 make: *** [all] Error 2

 I have tried 'make V=1', but that just seems to give me the information
 about the command used to build and not the details on the problem.

 My system detail ares:
 mono-3.2.1$ uname -a
 Darwin MacMini.local 12.4.0 Darwin Kernel Version 12.4.0: Wed May  1
 17:57:12 PDT 2013; root:xnu-2050.24.15~1/RELEASE_X86_64 x86_64

 mono-3.2.1$ gcc --version
 i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build
 5658) (LLVM build 2336.11.00)

 Any help is appreciated.

 Michael

 ___
 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] /mono/mini/main.c build error: depends on HAVE_SGEN_GC define, making it impossible to compile for sgen

2013-05-29 Thread Zoltan Varga

Hi,

  This should be fixed now by 655afb183bd8abac0b60307645c9b43ff37b3082.
Could you try it out ?

   Zoltan


On Wed, May 29, 2013 at 6:00 PM, Jeremy Bell bell.jer...@gmail.com wrote:

 I'm not sure if this is the best way to fix the issue, but I've submitted
 a pull request with a small fix:
 https://github.com/mono/mono/pull/650

 This is my first mono pull request, so please let me know if there are any
 contrib guidelines I missed.

 Regards,
 Jeremy


 On Thu, May 23, 2013 at 2:25 PM, Jeremy Bell bell.jer...@gmail.comwrote:


 These:
 export SYSROOT=$NDK/platforms/android-14/arch-arm
 export PATH=$NDK_STANDALONE/bin:$PATH
 export CC=arm-linux-androideabi-gcc
 export CXX=arm-linux-androideabi-g++
 export AR=arm-linux-androideabi-ar
 export AS=arm-linux-androideabi-as
 export CPP=arm-linux-androideabi-cpp
 export LD=arm-linux-androideabi-ld
 export RANLIB=arm-linux-androideabi-ranlib
 export STRIP=arm-linux-androideabi-strip
 ./autogen.sh --build=i686-pc-linux-gnu --host=arm-linux-androideabi
 --target=arm-linux-androideabi --enable-nls=no --with-mcs-docs=no
 --with-mcs-build=no CFLAGS=-DARM_FPU_NONE=1 CXXFLAGS=-DARM_FPU_NONE=1
 --prefix=$PREFIX

 Same issue with the armv7-a build:
 export SYSROOT=$NDK/platforms/android-14/arch-arm
 export PATH=$NDK_STANDALONE/bin:$PATH
 export CC=arm-linux-androideabi-gcc
 export CXX=arm-linux-androideabi-g++
 export AR=arm-linux-androideabi-ar
 export AS=arm-linux-androideabi-as
 export CPP=arm-linux-androideabi-cpp
 export LD=arm-linux-androideabi-ld
 export RANLIB=arm-linux-androideabi-ranlib
 export STRIP=arm-linux-androideabi-strip
 ./autogen.sh --build=i686-pc-linux-gnu --host=armv7-a-linux-androideabi
 --target=armv7-a-linux-androideabi --enable-nls=no --with-mcs-docs=no
 --with-mcs-build=no CFLAGS=-DARM_FPU_VFP=1 CXXFLAGS=-DARM_FPU_VFP
 --prefix=$INSTALL_PREFIX


 My system:
 Ubuntu 13.04

 Thanks,
 Jeremy


 On Thu, May 23, 2013 at 1:39 PM, Zoltan Varga var...@gmail.com wrote:

 Hi,

  buildver.h is always built unless some configure flag disables it. What
 configure arguments are you using ?

   Zoltan


 On Thu, May 23, 2013 at 5:01 PM, Jeremy Bell bell.jer...@gmail.comwrote:

 At some point between branch mono-2-10-9 and branch master, a change
 was made to /mono/mini/main.c:

 branch mono-2-10-9:

 main.c:
 #include config.h
 #include mini.h
 #ifndef HOST_WIN32
 #include buildver.h
 #endif


 branch master:
 #include config.h
 #include mini.h
 #ifndef HOST_WIN32
 #ifdef HAVE_SGEN_GC
 #include buildver-sgen.h
 #else
 #include buildver.h
 #endif
 #endif

 This makes main.c impossible to compile when buildver-sgen.h is
 generated and not buildver.h. First of all, HAVE_SGEN_GC is never defined
 for files in /mini as far as I can tell, so main.c always attempts to
 include buildver.h, which does not exist when buildver-sgen.h is generated
 instead.

 However, even if you explicitly define HAVE_SGEN_GC in CFLAGS, etc...
 then you will still get an error, in mini.h, because it believes it is an
 error to have either HAVE_SGEN_GC or HAVE_BOEHM_GC defined when mini.h is
 included, as /mini code should not have dependencies on the GC being used,
 so it says:

 mini.h:
 /*
  * The mini code should not have any compile time dependencies on the
 GC being used, so the same object file from mini/
  * can be linked into both mono and mono-sgen.
  */
 #if defined(HAVE_BOEHM_GC) || defined(HAVE_SGEN_GC)
 #error The code in mini/ should not depend on these defines.
 #endif


 So, either way, main.c won't compile without modification. Is the error
 in /mono/mini/mini.h no longer valid? Or was the change to
 /mono/mini/main.c to depend on the HAVE_SGEN_GC define a regression?

 Thanks,
 Jeremy

 ___
 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] /mono/mini/main.c build error: depends on HAVE_SGEN_GC define, making it impossible to compile for sgen

2013-05-23 Thread Zoltan Varga

Hi,

 buildver.h is always built unless some configure flag disables it. What
configure arguments are you using ?

  Zoltan


On Thu, May 23, 2013 at 5:01 PM, Jeremy Bell bell.jer...@gmail.com wrote:

 At some point between branch mono-2-10-9 and branch master, a change was
 made to /mono/mini/main.c:

 branch mono-2-10-9:

 main.c:
 #include config.h
 #include mini.h
 #ifndef HOST_WIN32
 #include buildver.h
 #endif


 branch master:
 #include config.h
 #include mini.h
 #ifndef HOST_WIN32
 #ifdef HAVE_SGEN_GC
 #include buildver-sgen.h
 #else
 #include buildver.h
 #endif
 #endif

 This makes main.c impossible to compile when buildver-sgen.h is generated
 and not buildver.h. First of all, HAVE_SGEN_GC is never defined for files
 in /mini as far as I can tell, so main.c always attempts to include
 buildver.h, which does not exist when buildver-sgen.h is generated instead.

 However, even if you explicitly define HAVE_SGEN_GC in CFLAGS, etc... then
 you will still get an error, in mini.h, because it believes it is an error
 to have either HAVE_SGEN_GC or HAVE_BOEHM_GC defined when mini.h is
 included, as /mini code should not have dependencies on the GC being used,
 so it says:

 mini.h:
 /*
  * The mini code should not have any compile time dependencies on the GC
 being used, so the same object file from mini/
  * can be linked into both mono and mono-sgen.
  */
 #if defined(HAVE_BOEHM_GC) || defined(HAVE_SGEN_GC)
 #error The code in mini/ should not depend on these defines.
 #endif


 So, either way, main.c won't compile without modification. Is the error in
 /mono/mini/mini.h no longer valid? Or was the change to /mono/mini/main.c
 to depend on the HAVE_SGEN_GC define a regression?

 Thanks,
 Jeremy

 ___
 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] AMD64 AOT code and bad IMT

2013-05-20 Thread Zoltan Varga

Hi,

On Tue, May 21, 2013 at 1:37 AM, Gavin Dodd
ga...@wholesalealgorithms.comwrote:


 To make things more interesting I'm working with a branch of mono 2.8 (I
 think) and I don't have any symbols for the AOT compiled code at run time,


You should try a 3.0 based mono version first, you might be running into a
bug which is already fixed.




 My questions are:

 Is the lmf address the correct value for the return of
 mono_arch_find_imt_method? If not what should it be?
 What generates the IMT for AOT compiled code?
 What sets the IMT address table at run time and where is it stored? I
 haven't seen any breakpoints on IMT functions get hit at runtime.

 Thanks

 The C code is called from an IMT thunk, which is generated by
arch_emit_imt_thunk () in aot-compiler.c. The thunks are stored in a table
pointed to by the symbol 'imt_thunks' in the mscorlib aot image.
The thunk receives the imt argument in MONO_ARCH_IMT_REG which is r10 in
this case. This register needs to be set by the caller, which is AOT
generated code.

   Zoltan



 Gavin




 ___
 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] AMD64 AOT code and bad IMT

2013-05-20 Thread Zoltan Varga

Hi,

  R11 is a scratch register overwritten by a lot of code including various
trampolines, so thats why we use r10.

   Zoltan


On Tue, May 21, 2013 at 4:13 AM, Wholesale ga...@wholesalealgorithms.comwrote:

 Thanks for the info.

 I'm not sure it is possible to switch to 3.0, but I'll look into it.

 The register in my version is R11, should code be emitted to look up the
 correct table or is mono_get_lmf_addr the correct call?



 On May 20, 2013, at 16:52, Zoltan Varga var...@gmail.com wrote:

 Hi,

 On Tue, May 21, 2013 at 1:37 AM, Gavin Dodd ga...@wholesalealgorithms.com
  wrote:


 To make things more interesting I'm working with a branch of mono 2.8 (I
 think) and I don't have any symbols for the AOT compiled code at run time,


 You should try a 3.0 based mono version first, you might be running into a
 bug which is already fixed.




 My questions are:

 Is the lmf address the correct value for the return of
 mono_arch_find_imt_method? If not what should it be?
 What generates the IMT for AOT compiled code?
 What sets the IMT address table at run time and where is it stored? I
 haven't seen any breakpoints on IMT functions get hit at runtime.

 Thanks

 The C code is called from an IMT thunk, which is generated by
 arch_emit_imt_thunk () in aot-compiler.c. The thunks are stored in a table
 pointed to by the symbol 'imt_thunks' in the mscorlib aot image.
 The thunk receives the imt argument in MONO_ARCH_IMT_REG which is r10 in
 this case. This register needs to be set by the caller, which is AOT
 generated code.

Zoltan



 Gavin




 ___
 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] Build mono from git sources.

2013-04-21 Thread Zoltan Varga

Hi,

  Run autogen.sh.

  Zoltan


On Sun, Apr 21, 2013 at 3:11 PM, telebovich telebov...@yahoo.com wrote:

 Hello

 I am updating my copy of git repository more or less frequently.
 Recently when i tried to build my sources i have got an error

 Making all in io-layer
 make[3]: Entering directory `/home/telebovich/Projects/mono/mono/io-layer'
 make[3]: *** No rule to make target `atomic.c', needed by `atomic.lo'.
 Stop.
 make[3]: Leaving directory `/home/telebovich/Projects/mono/mono/io-layer'
 make[2]: *** [all-recursive] Error 1

 I have not find this file in the directory and any link to it.
 Configuration
 works fine.
 Is it possible that the error was caused by commit
 7547f6f2f1162a62129e669710053e7c2b8293ad
 ?

 How can i fix this error?

 Thank you,
 Robert Lebovich.



 --
 View this message in context:
 http://mono.1490590.n4.nabble.com/Build-mono-from-git-sources-tp4659438.html
 Sent from the Mono - Dev mailing list archive at Nabble.com.
 ___
 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] ARM/NativeClient port

2013-02-22 Thread Zoltan Varga

Hi,

 I added some comments using the github review system. The rest of the
stuff looks ok, All the #ifdefs make the code look a bit ugly, but I don't
know how else to do it. So its ok.

   Zoltan

On Thu, Feb 21, 2013 at 6:04 PM, Nikolay Igotti olo...@google.com wrote:

 Hi,

  This pull request https://github.com/mono/mono/pull/571 implements
 approach suggested
 (only jumptables are no longer bound to domain, as trampolines init
 happens eariler than root domain init) and it would be great to have change
 reviewed and integrated.

  It passes SciMark and few other tests. SciMark score with jumptables is
 44.5MFlops, vs.  55.7MFlops without on Google Nexus 7, which is pretty
 natural, considering nature of the change.
 Performance likely could be improved, as in few places we could replace
 always
 indirect jumps with direct ones.

Thanks,
  Nikolay

 On Tue, Feb 5, 2013 at 4:14 PM, Nikolay Igotti olo...@google.com wrote:

Hi Zoltan,

  Good idea, but unfortunately for [reg + reg] loads it's hard to easily
 verify
 that address does not escapes sandbox, so NaCL only allows [reg + imm]
 addressing mode.

  So far, my approach is to augment MonoDomain with jumptable field, and
 replace inline jumptable with access to this domain-wide table.

  Generated ASM for trampoline looks like:

   movw rX, lo(jump_table_entry_addr)
   movt rX, hi(jump_table_entry_addr)
   ldr rX, [rX]
   bic rX, rX, #MASK ; for NaCL only
   bx rX

 and patching code decodes location to patch from movw/movt instruction
 (similar to what you suggested).

  Nikolay.


 On Tue, Feb 5, 2013 at 10:35 AM, Zoltan Varga var...@gmail.com wrote:


 On Mon, Feb 4, 2013 at 10:34 AM, Nikolay Igotti olo...@google.comwrote:

Hi Zoltan,

  For PC-relative addressing at least 2 conditions has to be satisfied:
  1. code must know which PC it runs at
  2. offset to data must be smaller than 4K to fit into immediate
 encoding

 If we're not using inline constant pools, it would lead to rather
 tricky memory layout of code
 interleaved with data.

   Nikolay


 PC relative addressing is already used by the runtime in AOT mode, see
 the implementation of the OP_AOTCONST opcode, you can generate:
 movw temp reg, 0
 movt temp reg, 0
 mov dreg, [pc+temp reg]
 and patch the movw/movt when the address of the code and the data is
 known. I.e. for trampolines, this is already known, for methods, you can
 patch the movw/movt
 in mono_arch_patch_code ().

 Zoltan



 On Sun, Feb 3, 2013 at 10:09 PM, Zoltan Varga var...@gmail.com wrote:

   Hi,
 
   We're working on implementation of Mono JIT/ARM for Native Client,
 and want to discuss certain details about design of our solution.
   Native Client's sandboxing mechanism, being a SFI solution, has
 rather strict  limitations on how verifiable machine code may look like. 
 To
 be precise:

   Our idea is to emit per-method (or per class?) jump table
 somewhere in .data, which contains list of all relocations, and use some
 register to point to this table.
  So for example, trampoline like this:
 ldr ip, [pc, #0]
  b skip
 .word target
   skip:
  mov lr, pc
  mov pc, ip
  would become (if r10 is used as jump table base register):
   .align 4 # for NaCl only
  ldr ip, [r10, #32] # unique (per-method or class) index for
 every callsite
  nop  # for NaCl only, to have bl at bundle end
  bic r10, r10, #0xc00f # for NaCl only
  bl ip # or blx
   r10 could point somewhere in method metadata, where its relocation
 table is stored.

  So our question is if someone sees problem with such approach, or
 could suggest better alternative. Also advises which register could be 
 used
 as the jump table base, and where  to store
  such a table (maybe patch info?) are very welcome.

 Hi,

 ARM has PC relative addressing, so it would be easier to use that
 instead of reserving a register.

  Zoltan

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

Re: [Mono-dev] Embedded mono; getting in C a pointer from an IntPtr object

2013-02-18 Thread Zoltan Varga

Hi,

 If you have an IntPtr object, you can simply unbox it, that will return a
pointer to the value boxed inside the object, i.e., then you can
dereference it to get the value:

void *ptr = *(gpointer*)mono_object_unbox (obj);

Zoltan

On Mon, Feb 18, 2013 at 11:46 AM, jean-michel.perr...@csiro.au wrote:

 Hi,

 I have a scenario where some C function is getting a MonoObject (*pobj)
 that happens to be an IntPtr. As the native pointer is known to be of a
 certain native type (SEXP), how do I retrieve it? I tried a few things, the
 latest being:

 type_il =
 mono_type_get_type(mono_class_get_type(mono_object_get_class(pobj)));
 switch(type_il)  /*MonoTypeEnum*/
 {
 case MONO_TYPE_I: // IntPtr, that we assume to be
 a SEXP as coming from R.NET.  result =
 (SEXP)(void*)mono_object_unbox(rclr_mono_call_inst_method(ToPointer,
 pobj, NULL, 0));
 break;

 I soon get an access violation not long after the function return.

 I have a working solution when hosting the Microsoft CLR but this is not
 directly transferable to Mono given the significantly different APIs.

 Regards
 ___
 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] ARM/NativeClient port

2013-02-04 Thread Zoltan Varga

Hi,

On Mon, Feb 4, 2013 at 10:34 AM, Nikolay Igotti olo...@google.com wrote:

Hi Zoltan,

  For PC-relative addressing at least 2 conditions has to be satisfied:
  1. code must know which PC it runs at
  2. offset to data must be smaller than 4K to fit into immediate encoding

 If we're not using inline constant pools, it would lead to rather tricky
 memory layout of code
 interleaved with data.

   Nikolay


PC relative addressing is already used by the runtime in AOT mode, see the
implementation of the OP_AOTCONST opcode, you can generate:
movw temp reg, 0
movt temp reg, 0
mov dreg, [pc+temp reg]
and patch the movw/movt when the address of the code and the data is known.
I.e. for trampolines, this is already known, for methods, you can patch the
movw/movt
in mono_arch_patch_code ().

Zoltan



 On Sun, Feb 3, 2013 at 10:09 PM, Zoltan Varga var...@gmail.com wrote:

   Hi,
 
   We're working on implementation of Mono JIT/ARM for Native Client, and
 want to discuss certain details about design of our solution.
   Native Client's sandboxing mechanism, being a SFI solution, has rather
 strict  limitations on how verifiable machine code may look like. To be
 precise:

   Our idea is to emit per-method (or per class?) jump table somewhere
 in .data, which contains list of all relocations, and use some register to
 point to this table.
  So for example, trampoline like this:
 ldr ip, [pc, #0]
  b skip
 .word target
   skip:
  mov lr, pc
  mov pc, ip
  would become (if r10 is used as jump table base register):
   .align 4 # for NaCl only
  ldr ip, [r10, #32] # unique (per-method or class) index for
 every callsite
  nop  # for NaCl only, to have bl at bundle end
  bic r10, r10, #0xc00f # for NaCl only
  bl ip # or blx
   r10 could point somewhere in method metadata, where its relocation
 table is stored.

  So our question is if someone sees problem with such approach, or could
 suggest better alternative. Also advises which register could be used as
 the jump table base, and where  to store
  such a table (maybe patch info?) are very welcome.

 Hi,

 ARM has PC relative addressing, so it would be easier to use that instead
 of reserving a register.

  Zoltan

 ___
 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] ARM/NativeClient port

2013-02-03 Thread Zoltan Varga

  Hi,

  We're working on implementation of Mono JIT/ARM for Native Client, and
want to discuss certain details about design of our solution.
  Native Client's sandboxing mechanism, being a SFI solution, has rather
strict  limitations on how verifiable machine code may look like. To be
precise:

  Our idea is to emit per-method (or per class?) jump table somewhere in
.data, which contains list of all relocations, and use some register to
point to this table.
 So for example, trampoline like this:
ldr ip, [pc, #0]
 b skip
.word target
  skip:
 mov lr, pc
 mov pc, ip
 would become (if r10 is used as jump table base register):
  .align 4 # for NaCl only
 ldr ip, [r10, #32] # unique (per-method or class) index for every
callsite
 nop  # for NaCl only, to have bl at bundle end
 bic r10, r10, #0xc00f # for NaCl only
 bl ip # or blx
  r10 could point somewhere in method metadata, where its relocation table
is stored.

 So our question is if someone sees problem with such approach, or could
suggest better alternative. Also advises which register could be used as
the jump table base, and where  to store
 such a table (maybe patch info?) are very welcome.

Hi,

ARM has PC relative addressing, so it would be easier to use that instead
of reserving a register.

 Zoltan
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] minimal mono embedding profile - hpc twist

2012-10-04 Thread Zoltan Varga

Hi,


 A more general question to the Mono team, does the mono-llvm fork pull in
 new functionality from the LLVM project from time to time?  Should we
 expect to be able to take advantage of the new optimisations (for example
 the deeper vectorization work in progress) when they become available?I
 recall that there were a number of deficiencies with the LLVM that required
 a lot of scaffolding in order to interoperate with the mono runtime.
 Curious whether the LLVM foks have thought to address these so that could
 make more direct use of core LLVM in the future?

 Yes, we do rebase our changes on top of LLVM HEAD from time to time. About
our changes, most of them are mono specific, and won't help LLVM very much.
for the others, it would require a lot of time to transform them into a
format suitable for inclusion into LLVM proper, so we didn't do that. As
for the LLVM deficiencies, most of them are solved/worked around in our
changes, so for example, LLVM can compile about 95% of mscorlib methods on
x86.

Zoltan
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] PrelinkAll leads to assertion failure

2012-01-03 Thread Zoltan Varga

Hi,

  This is now fixed in HEAD/2.10 branch.

Zoltan

On Tue, Jan 3, 2012 at 1:34 PM, Martin Däumler m...@cs.tu-chemnitz.dewrote:

 Hello,

 I wanted to use Marshal.PrelinkAll() in order to pre-initialize a
 PInvoke. Unfortunately, executing this method leads to an assertion
 failure on x86/Linux. The C# code is quite simple:

 using System;
 using System.Runtime.InteropServices;
 class Test1
 {
[DllImport(libpinvoke)]
public static extern int pinvoke(int value);

static void Main (string[] args)
{
Marshal.PrelinkAll(typeof(Test1));
int ret = pinvoke(1);
Console.WriteLine(return value:  + ret.ToString());
}
 }

 .. as well as the library code (pinvoke.c):

 int pinvoke( int value ) {
return value;
 }

 The full example including Makefile can be downloaded [1].
 Surprisingly, the assertion is raised by Mono 2.6.1 and
 2.10.7, but not by Mono 2.8.2 (the versions I tested).
 Further, the assertion is not raised when the C# code
 was AOT-compiled in advance (works with each tested Mono
 version).

 Is it a bug or a feature?


 With kind regards,
 Martin Däumler


 [1] http://www-user.tu-chemnitz.de/~mdae/PrelinkAllTest.tar
 ___
 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] Post-mortem debugging

2011-12-27 Thread Zoltan Varga

Hi,

  It won't work. The information required to construct managed stack traces
is contained in runtime data structures, and it is only available while the
program is running. You can
AOT your application, then you will have more usable stack traces.

Zoltan

On Tue, Dec 27, 2011 at 10:54 PM, Bassam Tabbara bas...@symform.com wrote:

 Hello,

 ** **

 I’m debugging a core file with gdb and I’m not able to find mono managed
 symbols:

 ** **

 (gdb) where

 #0  0x7f93c9096ed5 in raise () from /lib/libc.so.6

 #1  0x7f93c90983f3 in abort () from /lib/libc.so.6

 #2  0x004933d0 in mono_handle_native_sigsegv (signal=-907561328,
 ctx=value optimized out) at mini-exceptions.c:2246

 #3  0x004e6c9d in mono_arch_handle_altstack_exception
 (sigctx=0x7f93c9e7bc40, fault_addr=value optimized out, stack_ovf=0) at
 exceptions-amd64.c:957

 #4  0x004176e4 in mono_sigsegv_signal_handler (_dummy=11,
 info=0x7f93c9e7bd70, context=0x7f93c9e7bc40) at mini.c:5882

 #5  signal handler called

 #6  0x7f93c9d18cc0 in ?? ()

 #7  0x413fb199 in ?? ()

 #8  0x0025 in ?? ()

 #9  0x7f93c9cb6a90 in ?? ()

 #10 0x7f93c3cff150 in ?? ()

 #11 0x in ?? ()

 ** **

 (gdb) p mono_pmip(0x7f93c9d18cc0)

 You can't do that without a process to debug.

 ** **

 I looked at http://www.mono-project.com/Debugging and I can’t tell if
 this is supposed to work on core dumps or not. How do you guys do it?
 What’s your secret?

 ** **

 Thanks!

 Bassam

 ___
 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] Post-mortem debugging

2011-12-27 Thread Zoltan Varga

Hi,

  Also, if the problem is reproducible, then you can run mono with the
MONO_DEBUG=suspend-on-sigsegv environment variable set, which will force
the runtime  to spin in the sigsegv signal handler, allowing you to attach
to it with gdb.

 Zoltan

On Tue, Dec 27, 2011 at 11:43 PM, Zoltan Varga var...@gmail.com wrote:

 Hi,

   It won't work. The information required to construct managed stack
 traces is contained in runtime data structures, and it is only available
 while the program is running. You can
 AOT your application, then you will have more usable stack traces.

 Zoltan

 On Tue, Dec 27, 2011 at 10:54 PM, Bassam Tabbara bas...@symform.comwrote:

 Hello,

 ** **

 I’m debugging a core file with gdb and I’m not able to find mono managed
 symbols:

 ** **

 (gdb) where

 #0  0x7f93c9096ed5 in raise () from /lib/libc.so.6

 #1  0x7f93c90983f3 in abort () from /lib/libc.so.6

 #2  0x004933d0 in mono_handle_native_sigsegv (signal=-907561328,
 ctx=value optimized out) at mini-exceptions.c:2246

 #3  0x004e6c9d in mono_arch_handle_altstack_exception
 (sigctx=0x7f93c9e7bc40, fault_addr=value optimized out, stack_ovf=0) at
 exceptions-amd64.c:957

 #4  0x004176e4 in mono_sigsegv_signal_handler (_dummy=11,
 info=0x7f93c9e7bd70, context=0x7f93c9e7bc40) at mini.c:5882

 #5  signal handler called

 #6  0x7f93c9d18cc0 in ?? ()

 #7  0x413fb199 in ?? ()

 #8  0x0025 in ?? ()

 #9  0x7f93c9cb6a90 in ?? ()

 #10 0x7f93c3cff150 in ?? ()

 #11 0x in ?? ()

 ** **

 (gdb) p mono_pmip(0x7f93c9d18cc0)

 You can't do that without a process to debug.

 ** **

 I looked at http://www.mono-project.com/Debugging and I can’t tell if
 this is supposed to work on core dumps or not. How do you guys do it?
 What’s your secret?

 ** **

 Thanks!

 Bassam

 ___
 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] Assertion at mini-arm.c:5559, condition `IS_LDR_PC (code_ptr [0])' not met

2011-12-21 Thread Zoltan Varga

Hi,

  A reproducible testcase, along with the device+os specs would help us
debug the problem.

  Zoltan

On Thu, Dec 22, 2011 at 12:15 AM, Bassam Tabbara bas...@symform.com wrote:

 Hello,

 ** **

 We are seeing the following on ARM devices. Running mono built from the
 2-10 branch. Any ideas for where to start here?

 ** **

 invalid code stream, instruction before IMT value is not a LDC in
 mono_arch_find_imt_method() (code 0x40be8868 value 0: 0xe1a06000 -1:
 0xe591f028 -2: 0xe1a0e00f)

 * Assertion at mini-arm.c:5559, condition `IS_LDR_PC (code_ptr [0])' not
 met

 ** **

 Stacktrace:

 ** **

   at System.StringComparer.GetHashCode (object) 0x00067

   at System.Collections.Hashtable.GetHash (object) 0x00033

   at System.Collections.Hashtable.get_Item (object) 0x00057

   at
 System.Collections.Specialized.NameObjectCollectionBase.FindFirstMatchedItem
 (string) 0x00033

   at System.Collections.Specialized.NameObjectCollectionBase.BaseGet
 (string) 0x0001b

   at System.Configuration.PropertyInformationCollection.get_Item (string)
 0x0001b

   at System.Configuration.ConfigurationElement.get_Item (string) 0x00033
 

   at Foo.Bar.NodeSettings.get_ServerAddress () 0x0001f

   at Foo.Bar.Storage.ContributionHost.Start (System.Action) 0x000c7

   at (wrapper remoting-invoke-with-check)
 Foo.Bar.Storage.ContributionHost.Start (System.Action) 0x

   at Symform.Storage.Node.Contribution.ContributionService.OnStart
 (string[]) 0x00113

   at (wrapper runtime-invoke) Module.runtime_invoke_void__this___object
 (object,intptr,intptr,intptr) 0x

   at System.Reflection.MonoMethod.Invoke
 (object,System.Reflection.BindingFlags,System.Reflection.Binder,object[],System.Globalization.CultureInfo)
 0x00197

   at System.Reflection.MethodBase.Invoke (object,object[]) 0x00047

   at MonoServiceRunner.call (object,string,object[]) 0x00087

   at MonoServiceRunner.MainLoop (System.ServiceProcess.ServiceBase[])
 0x005af

   at System.ServiceProcess.ServiceBase.Run
 (System.ServiceProcess.ServiceBase[]) 0x0004f

   at System.ServiceProcess.ServiceBase.Run
 (System.ServiceProcess.ServiceBase) 0x00047

   at Symform.Storage.Node.Program.Main (string[]) 0x00383

   at (wrapper runtime-invoke) Module.runtime_invoke_int_object
 (object,intptr,intptr,intptr) 0x

   at System.AppDomain.ExecuteAssemblyInternal
 (System.Reflection.Assembly,string[]) 0x0003b

   at System.AppDomain.ExecuteAssembly
 (string,System.Security.Policy.Evidence,string[]) 0x00033

   at (wrapper remoting-invoke-with-check) System.AppDomain.ExecuteAssembly
 (string,System.Security.Policy.Evidence,string[]) 0x

   at MonoServiceRunner.StartService () 0x0040f

   at (wrapper runtime-invoke) Module.runtime_invoke_int__this__
 (object,intptr,intptr,intptr) 0x

   at System.Runtime.Remoting.RemotingServices.InternalExecuteMessage
 (System.MarshalByRefObject,System.Runtime.Remoting.Messaging.IMethodCallMessage)
 0x0022f

   at System.Runtime.Remoting.Messaging.StackBuilderSink.SyncProcessMessage
 (System.Runtime.Remoting.Messaging.IMessage) 0x000e3

   at
 System.Runtime.Remoting.Messaging.ServerObjectTerminatorSink.SyncProcessMessage
 (System.Runtime.Remoting.Messaging.IMessage) 0x0008f

   at System.Runtime.Remoting.Lifetime.LeaseSink.SyncProcessMessage
 (System.Runtime.Remoting.Messaging.IMessage) 0x0003b

   at
 System.Runtime.Remoting.ClientActivatedIdentity.SyncObjectProcessMessage
 (System.Runtime.Remoting.Messaging.IMessage) 0x00097

   at
 System.Runtime.Remoting.Messaging.ServerContextTerminatorSink.SyncProcessMessage
 (System.Runtime.Remoting.Messaging.IMessage) 0x001c3

   at
 System.Runtime.Remoting.Contexts.CrossContextChannel.SyncProcessMessage
 (System.Runtime.Remoting.Messaging.IMessage) 0x0010b

   at System.Runtime.Remoting.Channels.ChannelServices.SyncDispatchMessage
 (System.Runtime.Remoting.Messaging.IMessage) 0x0004f

   at System.AppDomain.ProcessMessageInDomain
 (byte[],System.Runtime.Remoting.Messaging.CADMethodCallMessage,byte[],System.Runtime.Remoting.Messaging.CADMethodReturnMessage)
 0x00097

   at (wrapper remoting-invoke-with-check)
 System.AppDomain.ProcessMessageInDomain
 (byte[],System.Runtime.Remoting.Messaging.CADMethodCallMessage,byte[],System.Runtime.Remoting.Messaging.CADMethodReturnMessage)
 0x

   at
 System.Runtime.Remoting.Channels.CrossAppDomainSink.ProcessMessageInDomain
 (byte[],System.Runtime.Remoting.Messaging.CADMethodCallMessage) 0x0007b*
 ***

   at (wrapper runtime-invoke)
 Module.runtime_invoke_CrossAppDomainSink/ProcessMessageRes_object_object
 (object,intptr,intptr,intptr) 0x

   at System.AppDomain.InvokeInDomainByID
 (int,System.Reflection.MethodInfo,object,object[]) 0x000a7

   at
 System.Runtime.Remoting.Channels.CrossAppDomainSink.SyncProcessMessage

Re: [Mono-dev] how to coerce MonoObject* holding a System.Type to MonoClass*

2011-12-14 Thread Zoltan Varga

Hi,

  Try mono_type_get_object () in reflection.h.

Zoltan

On Wed, Dec 14, 2011 at 8:51 PM, Jonathan Shore jonathan.sh...@gmail.comwrote:

 Thanks,

 Is it possible to get the reverse as well, from either MonoType* or
 MonoClass* - a System.Type object?


 On Wed, Dec 14, 2011 at 6:14 AM, Rodrigo Kumpera kump...@gmail.comwrote:

 Hi Jonathan,

 If you're using trunk, Zoltan Varga added a mono_reflection_type_get_type
 to handle that.

 On Tue, Dec 13, 2011 at 11:47 AM, Jonathan Shore 
 jonathan.sh...@gmail.com wrote:

 Thanks.  That works



 ___
 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] building mono with llvm support from git repositories (missing llvm header?)

2011-11-20 Thread Zoltan Varga

Hi,

  You should use the 'mono-2-10' branch of the llvm repo.

   Zoltan

On Sun, Nov 20, 2011 at 5:48 PM, Jonathan Shore jonathan.sh...@gmail.comwrote:

 Hi,

 I have pulled the repositories:

 - http://github.com/mono/llvm.git
 - http://github.com/mono/

 And am on the *mono-2.10 *branch of the mono git repo and the *mono *branch of
 the llvm git repo.   The build proceeded smoothly until attempting to build
 the LLVM backend mapping in mono/mini:

 make[1]: Entering directory `/home/jshore/Srcs/mono-src/mono/mono/mini'
 CC mini-llvm-cpp.lo
 mini-llvm-cpp.cpp:42:41: fatal error: llvm/Support/StandardPasses.h: No
 such file or directory

 I cannot find StandardPasses.h anywhere in either tree.   Perhaps there is
 either a file missing for checkin in the repositiory or this file needs to
 get generated somehow?   I did the configure for mono with the flag
 --enable-llvm.

 Is there a problem with the sources in these repos or is there a build
 step that generates the missing header?

 Thanks
 Jonathan

 ___
 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] building mono with llvm support from git repositories (missing llvm header?)

2011-11-20 Thread Zoltan Varga

Hi,

  What is on the mono-2-10 branch is intented for the next 2.10 release,
whats is master is intented for mono 2.12.

   Zoltan

On Sun, Nov 20, 2011 at 8:24 PM, Jonathan Shore jonathan.sh...@gmail.comwrote:

 Thanks!Out of curiosity, is what is on the head for mono/llvm 
 mono/mono stable and intended for 2.10.7?

 On Nov 20, 2011, at 2:04 PM, Zoltan Varga wrote:

 Hi,

   You should use the 'mono-2-10' branch of the llvm repo.

Zoltan

 On Sun, Nov 20, 2011 at 5:48 PM, Jonathan Shore 
 jonathan.sh...@gmail.comwrote:

 Hi,

 I have pulled the repositories:

 - http://github.com/mono/llvm.git
 - http://github.com/mono/

 And am on the *mono-2.10 *branch of the mono git repo and the *mono *branch 
 of
 the llvm git repo.   The build proceeded smoothly until attempting to build
 the LLVM backend mapping in mono/mini:

 make[1]: Entering directory `/home/jshore/Srcs/mono-src/mono/mono/mini'
 CC mini-llvm-cpp.lo
  mini-llvm-cpp.cpp:42:41: fatal error: llvm/Support/StandardPasses.h: No
 such file or directory

 I cannot find StandardPasses.h anywhere in either tree.   Perhaps there
 is either a file missing for checkin in the repositiory or this file needs
 to get generated somehow?   I did the configure for mono with the flag
 --enable-llvm.

 Is there a problem with the sources in these repos or is there a build
 step that generates the missing header?

 Thanks
 Jonathan

 ___
 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] embedded mono and .NET 4.0 assemblies [peculiar error]

2011-11-04 Thread Zoltan Varga

Hi,


 Note that I am not initializing mono_domain_assembly_open() with an exe,
 rather with a dll.  Perhaps there is some setup I need to do?


The dll is probably compiled against an older net version, causing the
runtime to load
an older mscorlib.

Zoltan
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] LLVM with current Mono

2011-10-20 Thread Zoltan Varga

Hi,

  You should use the branch in the LLVM repo corresponding to your mono
version,
i.e. mono-2-10.

Zoltan

2011/10/19 Konrad M. konrad.kruczyn...@gmail.com

 Hi,
  which branch of mono's LLVM repository should I use to compile mono
 2.10.6 with --enabled-llvm? mono-2-10 one gives me:
 mini-llvm-cpp.cpp: In function ‘LLVMOpaqueExecutionEngine*
 mono_llvm_create_ee(LLVMOpaqueModuleProvider*, unsigned char*
 (*)(LLVMOpaqueValue*, int), void (*)(LLVMOpaqueValue*, void*, void*),
 void (*)(void*))’:
 mini-llvm-cpp.cpp:469: error: cannot allocate an object of abstract type
 ‘MonoJITMemoryManager’
 mini-llvm-cpp.cpp:59: note:   because the following virtual functions
 are pure within ‘MonoJITMemoryManager’:
 /usr/include/llvm/ExecutionEngine/JITMemoryManager.h:115: note:
 virtual
 void llvm::JITMemoryManager::deallocateFunctionBody(void*)
 /usr/include/llvm/ExecutionEngine/JITMemoryManager.h:131: note:
 virtual
 void llvm::JITMemoryManager::deallocateExceptionTable(void*)

 Regards,
  Konrad

 ___
 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] LLVM with current Mono

2011-10-20 Thread Zoltan Varga

Hi,

  I can't reproduce this.

Zoltan

2011/10/20 Konrad Kruczyński konrad.kruczyn...@gmail.com

 Hi Zoltan,

 2011/10/20 Zoltan Varga var...@gmail.com:
  Hi,
You should use the branch in the LLVM repo corresponding to your mono
  version,
  i.e. mono-2-10.
  Zoltan
 

 Generally it was what I did. Specifically:
 LLVM from mono-2-10 branch, last commit
 ab6947203a665efa0d7676f19cabf2fa70e3af60
 configured with:
 ./configure --enable-optimized --enable-targets=x86 x86_64 --prefix=/usr/
 Mono 2.10.5 tarball from mono site. Configured with:
 ./configure --prefix=/usr/ --enable-llvm=yes
 LLVM compilation went fine, hovewer Mono's ended with error attached
 in previous message.

 --
 Regards,
  Konrad

___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Test suite failures (Mono 2.10.2)

2011-06-23 Thread Zoltan Varga

Hi,

  Our test suite contains 1000s of tests, written by dozens of people, its a
bit hard to keep them all passing.

Zoltan

On Thu, Jun 23, 2011 at 7:44 PM, Harry Wilkinson hwilkin...@mdsol.comwrote:

 Hi,

 I'm encountering some test failures with the Mono 2.10.2 source tarball
 distributed at http://ftp.novell.com/pub/mono/sources/mono/

 Basically I'm trying to package it for deployment on Ubuntu 10.04.2 servers
 in a cloud configuration.  So far I've been building from source and
 encountered no significant problems other than the long build time.  I'd
 like to be able to reduce that by building it once and deploying a compiled
 package.  So I'm using dpkg-buildpackage.

 However, now that I'm packaging rather than just building and installing,
 it seems that the test suite is run and there are some test failures.  The
 first and most obvious one is that it appears that a file is missing from
 the source tarball:


 mcs/class/corlib/Test/System.Runtime.Serialization.Formatters.Binary/VersionTolerantSerialization/VersionTolerantSerializationTestLib/6.0/Address.cs

 The file is there in the Git repo under the 2.10.2 tag, but it's not in the
 tarball.  Unfortunately it's referenced in the associated Makefile
 (mcs/class/corlib/Makefile).  The same applies to 2.10.1, so I'm guessing
 the file is omitted from whatever process builds the tarballs.

 I switched to compiling from the source taken from Git, checkout out the
 2.10.2 tag, and I get a different error (which is also what I get with the
 tarball version if I just hack the makefile):

 make[8]: Entering directory
 `/home/hwilkinson/mono/mcs/class/System.Web.DynamicData'
 MCS [net_2_0] System.Web.DynamicData_test_net_2_0.dll
 Test/../../System.Web/Test/mainsoft/NunitWeb/NunitWeb/MyTemplateControls.cs(43,19):
 error CS0507:
 `MyTemplateControls.TestTemplateControl.CreateChildControls()': cannot
 change access modifiers when overriding `protected' inherited member
 `System.Web.UI.Control.CreateChildControls()'
 /home/hwilkinson/mono/mcs/class/lib/net_2_0/System.Web.dll (Location of the
 symbol related to previous error)
 Compilation failed: 1 error(s), 0 warnings
 make[8]: *** [System.Web.DynamicData_test_net_2_0.dll] Error 1

 It looks like this could well be an incorrect preprocessor definition
 'SYSTEM_WEB_EXTENSIONS' (not sure whether it should be defined or not)
 in mcs/class/System.Web/Test/mainsoft/NunitWeb/NunitWeb/MyTemplateControls.cs.

 Is this expected?  I had sort of assumed that a released version would have
 a passing test suite.  Am I doing something wrong?

 Any advice (well, almost) would be gratefully received.

 Thanks.

 Harry Wilkinson

 ___
 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] compiling (2.10.2) on a beagleboard-xm running Ubuntu

2011-06-13 Thread Zoltan Varga

Hi,

You are probably running into:
https://bugzilla.novell.com/show_bug.cgi?id=683409

On Mon, Jun 13, 2011 at 4:07 AM, rstat1 rst...@gmail.com wrote:

 What kind of errors are you getting, just out of curiosity?

 I'm having issues of my own with 2.10.2 and getting mono apps to run on a
 Tegra 2 ARM chip. It compiles just fine, and ./mono --help works perfectly.
 But running any sort actual app makes mono segfault, after 4 or 5
 inconsistent metadata errors.

 --
 View this message in context:
 http://mono.1490590.n4.nabble.com/compiling-2-10-2-on-a-beagleboard-xm-running-Ubuntu-tp3527139p3593000.html
 Sent from the Mono - Dev mailing list archive at Nabble.com.
 ___
 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] compiling (2.10.2) on a beagleboard-xm running Ubuntu

2011-06-13 Thread Zoltan Varga

The bug is fixed in HEAD and our mono 2.10 branch, not in the released mono
2.10.2.
Also, it was a random crash, which could manifest in a variety of ways.

 Zoltan

On Mon, Jun 13, 2011 at 6:22 PM, Ryan Statzer rst...@gmail.com wrote:

 That bug has been marked fixed. Also it doesn't mention anything about
 inconsistent metadata.
 On Jun 13, 2011 7:09 AM, Zoltan Varga var...@gmail.com wrote:
  Hi,
 
  You are probably running into:
  https://bugzilla.novell.com/show_bug.cgi?id=683409
 
  On Mon, Jun 13, 2011 at 4:07 AM, rstat1 rst...@gmail.com wrote:
 
  What kind of errors are you getting, just out of curiosity?
 
  I'm having issues of my own with 2.10.2 and getting mono apps to run on
 a
  Tegra 2 ARM chip. It compiles just fine, and ./mono --help works
 perfectly.
  But running any sort actual app makes mono segfault, after 4 or 5
  inconsistent metadata errors.
 
  --
  View this message in context:
 
 http://mono.1490590.n4.nabble.com/compiling-2-10-2-on-a-beagleboard-xm-running-Ubuntu-tp3527139p3593000.html
  Sent from the Mono - Dev mailing list archive at Nabble.com.
  ___
  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] Embedding Mono: multiple calls to mono_jit_init

2011-05-13 Thread Zoltan Varga

Hi,

   Supporting this would be a _lot_ of work, the most basic problem is that
the runtime depends on non-automatic C variables being 0 initialized on
startup. You can support this in your app by putting the runtime into a
linux shared library (.so) and loading/unloading the shared library yourself
using dlopen/dlclose.

  Zoltan

On Fri, May 13, 2011 at 11:56 AM, MartinAlexander 
martin.arvids...@gmail.com wrote:

 Hello,

 Calling mono_jit_init several times is not supported as discussed in other
 forum posts, but my question is why?

 Is it a bug that have plans to be solved?
 Or is it a problem with the Linux architecture?

 My problem is that I am writing a DLL which is called from an closed-source
 commercial application with calls like OnInit, OnUninit, OnThis, OnThat and
 so on. This application has a reload/restart function which unloads the DLL
 completely and then starts it again. On Windows this works, but not on
 Linux.

 Thanks!

 --
 View this message in context:
 http://mono.1490590.n4.nabble.com/Embedding-Mono-multiple-calls-to-mono-jit-init-tp3519842p3519842.html
 Sent from the Mono - Dev mailing list archive at Nabble.com.
 ___
 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] Embedding Mono: multiple calls to mono_jit_init

2011-05-13 Thread Zoltan Varga

You need to use mono's shared library libmono.so, and somehow make the OS
load/unload it. Its not easy to do, but doable.

   Zoltan

On Fri, May 13, 2011 at 2:43 PM, MartinAlexander martin.arvids...@gmail.com
 wrote:

 How do you mean? I think this is what I am doing now . I admit I was
 unclear
 but the commercial application is written in native C++ and calls my native
 library (dll/so). In OnInit I call mono_jit_init and in OnUninit I call
 mono_jit_cleanup.

 --
 View this message in context:
 http://mono.1490590.n4.nabble.com/Embedding-Mono-multiple-calls-to-mono-jit-init-tp3519842p3520110.html
 Sent from the Mono - Dev mailing list archive at Nabble.com.
 ___
 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] scratchbox devkit?

2011-05-07 Thread Zoltan Varga

Cross AOT means that the resulting runtime can't run code, it will only
support the
--aot command line option, creating an AOT image which can be run on the
target platform.
I'm not sure this is what you are looking for.

 Zoltan

On Sat, May 7, 2011 at 7:49 PM, Liam Staskawicz lst...@gmail.com wrote:

  Interesting! I haven't found any docs mentioning cross AOT, but that
 could be exactly what I'm looking for.

 Does this mean that if I specify armv5tel-unknown-linux-gnueabi* as a
 target to ./configure, that any time I make an AOT build it will target 
 armv5tel?
 Would I be able to execute bytecode normally with the resultant mono binary
 on the host? I guess I'm not fully clear why I would specify the cross AOT
 target to the ./configure script for mono itself. Are there other
 implications to a normal mono binary that setting the target flag would
 have?

 Thanks again,
 Liam

 On Friday, May 6, 2011 at 6:59 PM, Zoltan Varga wrote:

 Hi,

   That code is actually for cross AOT, i.e. using a runtime running on x86
 to generate AOT code for arm, for example. I.e. it checks host and target,
 and not host and build.

  Zoltan

 On Sat, May 7, 2011 at 3:51 AM, Liam Staskawicz lst...@gmail.com wrote:

  Actually, I just had a chance to look at the ./configure script and it
 looks like there is a fair amount of support in there for cross compiling:
 the targets powerpc64-ps3-linux-gnu, powerpc64-xbox360-linux-gnu, 
 x86_64-*-nacl,
 armv7l-unknown-linux-gnueabi*, and armv5tel-unknown-linux-gnueabi* all
 seem to have entries in the ` if test x$host != x$target; ` condition.

 I was wondering if you could provide a bit more detail about the state of
 support for these targets (happily, mine is on the list). Are these not
 actively maintained, or not known to work, or perhaps covered by some other
 disclaimer?

 Thanks!
 Liam

   On Wednesday, May 4, 2011 at 9:00 AM, Liam Staskawicz wrote:

  Ah, also - http://www.mono-project.com/Mono:ARM recommends using
 scratchbox to build mono for ARM. Would be nice to clarify there as
 well, if possible.

 Thanks,
 Liam

 On Wednesday, May 4, 2011 at 8:06 AM, Liam Staskawicz wrote:

  OK, thanks!

 Liam

 On Wednesday, May 4, 2011 at 2:05 AM, Zoltan Varga wrote:

 Hi,

   We recommend compiling on the device itself if possible, using distcc for
 example. Our configure scripts etc. are not really written with
 cross-compilation in mind.

   Zoltan

 On Wed, May 4, 2011 at 9:04 AM, Liam Staskawicz lst...@gmail.com wrote:

  Hi,

 I'm just getting set up trying to cross compile mono for an ARM target
 using scratchbox. The wiki page at 
 http://www.mono-project.com/Scratchboxmentions a mono devkit, but the only 
 address is to
 svn://anonsvn.mono-project.com which now redirects to github, and I can't
 find the subproject mentioned (garmono?) anywhere in the sources on github.

 Did this component not survive the transition to github? Anybody have any
 tips on where to find it if it still exists?

 Of course this is coming from the perspective of somebody searching high
 and low for info, but if the maintainer is still around it would be nice to
 update the wiki page, even to say that it's out of date :)

 Thanks!
 Liam

 ___
 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] scratchbox devkit?

2011-05-07 Thread Zoltan Varga

On Sat, May 7, 2011 at 7:57 PM, Liam Staskawicz lst...@gmail.com wrote:

  I think I understand. So if I were interested in both running normal
 assemblies on the host *and* creating AOT images for a target platform, I
 would simply ./configure and build 2 separate mono builds on the host?


Yes

   Zoltan

 Thanks for the quick replies btw!

 Liam

 On Saturday, May 7, 2011 at 10:54 AM, Zoltan Varga wrote:

 Cross AOT means that the resulting runtime can't run code, it will only
 support the
 --aot command line option, creating an AOT image which can be run on the
 target platform.
 I'm not sure this is what you are looking for.

  Zoltan

 On Sat, May 7, 2011 at 7:49 PM, Liam Staskawicz lst...@gmail.com wrote:

  Interesting! I haven't found any docs mentioning cross AOT, but that
 could be exactly what I'm looking for.

 Does this mean that if I specify armv5tel-unknown-linux-gnueabi* as a
 target to ./configure, that any time I make an AOT build it will target 
 armv5tel?
 Would I be able to execute bytecode normally with the resultant mono binary
 on the host? I guess I'm not fully clear why I would specify the cross AOT
 target to the ./configure script for mono itself. Are there other
 implications to a normal mono binary that setting the target flag would
 have?

 Thanks again,
 Liam

 On Friday, May 6, 2011 at 6:59 PM, Zoltan Varga wrote:

 Hi,

   That code is actually for cross AOT, i.e. using a runtime running on x86
 to generate AOT code for arm, for example. I.e. it checks host and target,
 and not host and build.

  Zoltan

 On Sat, May 7, 2011 at 3:51 AM, Liam Staskawicz lst...@gmail.com wrote:

   Actually, I just had a chance to look at the ./configure script and it
 looks like there is a fair amount of support in there for cross compiling:
 the targets powerpc64-ps3-linux-gnu, powerpc64-xbox360-linux-gnu, 
 x86_64-*-nacl,
 armv7l-unknown-linux-gnueabi*, and armv5tel-unknown-linux-gnueabi* all
 seem to have entries in the ` if test x$host != x$target; ` condition.

 I was wondering if you could provide a bit more detail about the state of
 support for these targets (happily, mine is on the list). Are these not
 actively maintained, or not known to work, or perhaps covered by some other
 disclaimer?

 Thanks!
 Liam

   On Wednesday, May 4, 2011 at 9:00 AM, Liam Staskawicz wrote:

  Ah, also - http://www.mono-project.com/Mono:ARM recommends using
 scratchbox to build mono for ARM. Would be nice to clarify there as
 well, if possible.

 Thanks,
 Liam

 On Wednesday, May 4, 2011 at 8:06 AM, Liam Staskawicz wrote:

  OK, thanks!

 Liam

 On Wednesday, May 4, 2011 at 2:05 AM, Zoltan Varga wrote:

 Hi,

   We recommend compiling on the device itself if possible, using distcc for
 example. Our configure scripts etc. are not really written with
 cross-compilation in mind.

   Zoltan

 On Wed, May 4, 2011 at 9:04 AM, Liam Staskawicz lst...@gmail.com wrote:

  Hi,

 I'm just getting set up trying to cross compile mono for an ARM target
 using scratchbox. The wiki page at 
 http://www.mono-project.com/Scratchboxmentions a mono devkit, but the only 
 address is to
 svn://anonsvn.mono-project.com which now redirects to github, and I can't
 find the subproject mentioned (garmono?) anywhere in the sources on github.

 Did this component not survive the transition to github? Anybody have any
 tips on where to find it if it still exists?

 Of course this is coming from the perspective of somebody searching high
 and low for info, but if the maintainer is still around it would be nice to
 update the wiki page, even to say that it's out of date :)

 Thanks!
 Liam

 ___
 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] [patch] Clean up

2011-05-03 Thread Zoltan Varga

Hi,

  This will never work, the runtime depends on variables being zero
initalized in a mirriad places. Neither java's hotspot, nor MS.NET CLR
allows you to start/stop the runtime multiple times.

 Zoltan

On Tue, May 3, 2011 at 3:54 PM, Richard Sykes jit...@gmail.com wrote:

 Hi,

 I'm new here (just signed up), following the
 http://mono-project.com/Contributing #Ways to Contribute. If
 okay/appropriate, I would like to throw into the ring suggested fixed as I
 find them.
 Constructive feedback is appreciated.
 My motive/goal: To get this working...
  MonoDomain* domain = mono_jit_init_version (Root Domain, v2.0.50727);
  mono_jit_cleanup(domain);
  domain = mono_jit_init_version (Root Domain, v2.0.50727);
 The fix: The first one (of many) is very simple  trivial; set the
 global_codeman back to NULL so that it goes through the correct code path in
 function mono_global_codeman_reserve
 My Code base: Tarball 2.10.2
 File: mini.c
 Function: mini_cleanup
 Line: 6706 to 6707
 Old code:

  if (!mono_dont_free_global_codeman)

 mono_code_manager_destroy (global_codeman);
 New code:

  if (!mono_dont_free_global_codeman)

 {

 mono_code_manager_destroy (global_codeman);

 global_codeman = NULL;

 }

 Regards,


 Richard Sykes.

 ___
 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] StackOverflow on System.Delegate.Equals

2011-05-01 Thread Zoltan Varga

Hi,

This was probably caused by:

https://bugzilla.novell.com/show_bug.cgi?id=687902

https://bugzilla.novell.com/show_bug.cgi?id=687902which is now fixed.

Zoltan

On Mon, May 2, 2011 at 2:45 AM, pwo szy...@onet.pl wrote:

Hi,

I'd like to provide some additional data on this problem.

I added some code into Equals method of System.MulticastDelegate that uses
Object.ReferenceEquals(this,this.prev) to check whether this == this.prev,
I
used it instead of this.Equals(this.prev) because we suspected that
original
Equals method is responsible for generating stack overflow. When these
references are equal I'm writing it into error log of apache2. So far
without any success.

After testing application with heavier load StackOverflow happens or entire
application crashes ( when SO occured apache2 log looks like this:
http://monobin.com/__f495ba429 )

I also managed to receive error page like this (I was trying to sign up
into
application after stack overflow without restarting the apache server):
http://monobin.com/__f6f4607b3

We modified our application so we can use external session state provider,
but it didn't help. From our observations we can tell that if we are using
asp-state2 for session data the stack overflow is likely to appear and if
we
change it into in-procces mode whole application crashes. The weird thing
is
that under light load everything works fine, so it looks like under heavy
load all session data magically disapear. This is the lead we will try to
investigate now.

This behaviour occurs on mono 2.10.1 compiled from tarball. This week I'll
try to switch it to 2.10.2 and if anything changes I'll let You know.

I can provide more data/logs if needed

Thanks in advance for any piece of advice
Best Regards,
Pawel

krlm wrote:

Hello,

I've found an issue in my ASP.NET application when it's running under
heavy load. It throws an exception like that:
http://pastebin.com/DRAYVM0F
and then the whole application is down, i've to restart
apache/mod-mono-server. It's running under mono 2.10.1, apache2 and
mod-mono. On IIS/MS.NET i've not found any problems, even on heavier
load.
Maybe someone has any thoughts/ideas what might causing problem like
this?
Thanks in advance.

Kind regards,
Marcin
--
View this message in context:
http://mono.1490590.n4.nabble.com/StackOverflow-on-System-Delegate-Equals-tp3411024p3489060.html
Sent from the Mono - Dev mailing list archive at Nabble.com.
___
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] System.Threading.Monitor::Exit fails in latest trees

2011-04-29 Thread Zoltan Varga

Hi,

  Those trampolines are in tramp-ARCH.c, they are called
monitor_enter/exit_trampoline ().

Zoltan

On Fri, Apr 29, 2011 at 3:39 PM, Martin Daeumler m...@cs.tu-chemnitz.dewrote:

 On March 10, 2010, Paolo Molaro wrote:

  Further, I traced it down into the mono 2.6.1 code tree, and
  mono_monitor_exit is never called. The trampoline generates the code,
 but
  it's never called. Can you provide a quick fix? It seems like a glaring
  bug.

 There is no bug, on your architecture the fast path is optimized and it
 won't go to the unmanaged function in the runtime.

 Hello,

 how does this fast path work on x86 and Mono 2.6.1? During JITing this
 code:

 class Test {
int test1;

public int callInst(Test myClass) {
lock (this) {
myClass.test1 = 1;
}
return myClass.test1;
}

static int Main() {
Test meineKlasse = new Test();
int ret = meineKlasse.callInst(meineKlasse);
Console.WriteLine(meineKlasse:  + ret.ToString());
return 0;
}
 }

 , mono_monitor_get_fast_enter_method() and
 mono_monitor_get_fast_exit_method()
 are not called. While executing the method callInst() the unmanaged
 function
 mono_monitor_enter() (mono/metadata/monitor.c) is called through a
 generic
 trampoline.

 Q1: The generic (monitor) trampoline is not called directly by the code of
 callInst().
 There is a kind of wrapper that calls the generic trampoline. Where is the
 wrapper
 generated?

 When leaving the lock-block, i.e., calling
 System.Threading.Monitor::Exit() from within
 the finally-block in den CIL-code, the unmanaged function
 mono_monitor_exit()
 (mono/metadata/monitor.c) is not called at all. There is an ominous piece
 of
 code that
 returns to callInst().

 Q2: How is the monitor exit fast path realized? Where is the wrapper
 generated
 which does not call mono_monitor_exit()?


 With kind regards,
 Martin Däumler

 --
 View this message in context:
 http://mono.1490590.n4.nabble.com/System-Threading-Monitor-Exit-fails-in-latest-trees-tp1578116p3483712.html
 Sent from the Mono - Dev mailing list archive at Nabble.com.
 ___
 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] can't find a register in class BREG while reloading asm

2011-04-21 Thread Zoltan Varga

Hi,

  Upgrade to a newer gcc version. 4.1.2 was released in 2007.

Zoltan

On Thu, Apr 21, 2011 at 12:38 PM, jcmschoot j.sch...@divitec.nl wrote:

 Hello,

 I am trying to get mono 2.10.1 working on linux of a NAS unit. Since there
 is no mono 2.10.1 package available for my linux environment I try to
 compile it on my linux.

 It all looks promising until make give the following error:

 mini-amd64.c: In function cpuid:
 mini-amd64.c:1242: error: can't find a register in class BREG while
 reloading asm

 the same error occurs when I try to compile mono-2.6.7 tarball

 I have been searching for a solution but I can't find any that work.

 I am using:
 mono.2.10.1 tarball
 gcc 4.1.2
 linux kernal 2.6.37.5.RNx86_64.2.1 #1 SMP Tue Mar 29 16:38:58 PDT 2011
 x86_64 GNU/Linux
 processor Intel Atom D525

 Does anyone have any ideas?

 Greetings,
 Joris

 --
 View this message in context:
 http://mono.1490590.n4.nabble.com/can-t-find-a-register-in-class-BREG-while-reloading-asm-tp3465596p3465596.html
 Sent from the Mono - Dev mailing list archive at Nabble.com.
 ___
 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] eglib changes for Moonlight

2011-04-18 Thread Zoltan Varga

Hi,

  Looks ok, except perhaps this:

+#include unistd.h
+#include float.h
+#include iconv.h

I'm not sure headers are present everywhere, esp. on windows.

 Zoltan

On Mon, Apr 18, 2011 at 9:14 PM, Chris Toshok tos...@gmail.com wrote:

 Attached is the patch we're currently working with wrt moonlight running on
 eglib (needed for our coming embedded dominance, and used in the android
 port).  Anyone care to review it?  I'd love to commit it today sometime so
 we can move forward with merging all the rest of the moonlight changes into
 the mainline.

 There are a couple of FIXME's in the patch, all of which will be addressed
 pretty quickly (the exception perhaps being g_unichar_break_type - we're
 going to need someone who knows unicode to deal with that mess).

 Thoughts, comments?
 Chris


 ___
 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] Mono 2.8 (trunk) compiling on Mac OS X 10.6 (SL)

2011-04-17 Thread Zoltan Varga

Hi,

You probably need to install g++ too in addition to gcc.

Zoltan

On Sun, Apr 17, 2011 at 6:39 PM, Geoff Norton gnor...@novell.com wrote:

As per your output this isn't a mono issue, but a toolchain issue:

checking for C compiler default output file name...
configure: error: in `/Users/nmccready/Desktop/mono-20110416':
configure: error: C compiler cannot create executables
See `config.log' for more details.

Have you checked the config.log for more details like it says?

Geoff

On 2011-04-16, at 10:30 PM, nmccready wrote:

I am having the same problems on compiling too.

nems-MacBook-Pro:mono-20110416 nmccready$ ./configure
checking build system type... i386-apple-darwin10.7.0
checking host system type... i386-apple-darwin10.7.0
checking target system type... i386-apple-darwin10.7.0
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... ./install-sh -c -d
checking for gawk... no
checking for mawk... no
checking for nawk... no
checking for awk... awk
checking whether make sets $(MAKE)... yes
checking how to create a ustar tar archive... gnutar
checking whether to enable maintainer-specific portions of Makefiles...
no
checking whether ln -s works... yes
checking host platform characteristics... ok
checking for gcc... gcc
checking for gcc... (cached) gcc
checking for C compiler default output file name...
configure: error: in `/Users/nmccready/Desktop/mono-20110416':
configure: error: C compiler cannot create executables
See `config.log' for more details.

--
View this message in context:
http://mono.1490590.n4.nabble.com/Mono-2-8-trunk-compiling-on-Mac-OS-X-10-6-SL-tp2133834p3454908.html
Sent from the Mono - Dev mailing list archive at Nabble.com.
___
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] Cross directory function call in Mono's build system

2011-04-14 Thread Zoltan Varga

Hi,

  Add a new entry to MonoRuntimeCallbacks and make the code in mini.c
initialize it to the function you want to call, then call this entry from
object.c.

Zoltan

On Thu, Apr 14, 2011 at 1:55 PM, Martin Däumler m...@cs.tu-chemnitz.dewrote:

 Hello,

 I'm modifying Mono 2.6.1 and I want to call a function from
 within function 'mono_delegate_ctor()' in source file
 mono/metadata/object.c. The function to be called is a
 custom function defined in source file mono/mini/mysourcefile.c
 (which is already included in the build process of directory
 mono/mini). So, I added mysourcefile.c to the list of
 source files in Makefile.am in mono/metadata. However, the
 code in mysourcefile.c uses a lot of functions of source
 files in mono/mini.c. So, the linker says there are a lot
 of undefined references. Including the referenced source
 files works as far as the function
 'MONO_DEBUGGER__notification_function()' is referenced. It
 is declared in mono/debug-debugger.c and marked as extern.
 Although mono/debug-debugger.c is included, the linker
 says the reference to this function is undefined.

 This is the point where I hang. Any hints how to get Mono
 built with my custom function call?


 With kind regards,
 Martin Däumler
 ___
 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] [Embedded] GetEnumerator on a Listint

2011-04-05 Thread Zoltan Varga

Hi,

  In this line:

printf (%u\n, *(bool*)mono_object_unbox( mono_runtime_invoke
(moveNext, enumerator,
NULL, NULL)));

You probably have to change 'moveNext' to 'mono_object_unbox(moveNext)'.

   Zoltan

On Tue, Apr 5, 2011 at 10:05 AM, Viktor Hermansson 
viktor.hermans...@gmail.com wrote:

 On Mon, 4 Apr 2011 15:37:07 +0200
 Zoltan Varga var...@gmail.com wrote:

  Hi,
 
Enumerator is probably a valuetype, and those have to be unbox-ed
  before passing them to mono_runtime_invoke ().
 
 Zoltan

 If I do that it can't find the MoveNext()-method, so that's probably
 not the issue or did I misinterpret your idea?

 /Viktor

 
  On Mon, Apr 4, 2011 at 2:10 PM, viktor.hermansson 
  viktor.hermans...@gmail.com wrote:
 
   I have a problem to use an Enumerator in the unmaneged world.
  
   When I execute MoveNext() it doesn't return the expected value
   (true).
  
   example code:
   (an extension to Roberts code here:
   http://go-mono.com/forums/#nabble-td1538089)
  
   c++-code:
   http://pastebin.com/aMHmnHRC
  
   c#-code:
   http://pastebin.com/MpktHBTB
  
   platform:
   Linux 2.6.38 64bit
   Mono git snapshot and 2.10.1
   GCC 4.6.0
  
  
  
   --
   View this message in context:
  
 http://mono.1490590.n4.nabble.com/Embedded-GetEnumerator-on-a-List-int-tp3425288p3425288.html
   Sent from the Mono - Dev mailing list archive at Nabble.com.
   ___
   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] [Embedded] GetEnumerator on a Listint

2011-04-05 Thread Zoltan Varga

I mean, change 'enumerator' to 'mono_object_unbox(enumerator)'.

 Zoltan

On Tue, Apr 5, 2011 at 10:24 AM, Zoltan Varga var...@gmail.com wrote:

 Hi,

   In this line:

 printf (%u\n, *(bool*)mono_object_unbox( mono_runtime_invoke
 (moveNext, enumerator,
 NULL, NULL)));

 You probably have to change 'moveNext' to 'mono_object_unbox(moveNext)'.

Zoltan

 On Tue, Apr 5, 2011 at 10:05 AM, Viktor Hermansson 
 viktor.hermans...@gmail.com wrote:

 On Mon, 4 Apr 2011 15:37:07 +0200
 Zoltan Varga var...@gmail.com wrote:

  Hi,
 
Enumerator is probably a valuetype, and those have to be unbox-ed
  before passing them to mono_runtime_invoke ().
 
 Zoltan

 If I do that it can't find the MoveNext()-method, so that's probably
 not the issue or did I misinterpret your idea?

 /Viktor

 
  On Mon, Apr 4, 2011 at 2:10 PM, viktor.hermansson 
  viktor.hermans...@gmail.com wrote:
 
   I have a problem to use an Enumerator in the unmaneged world.
  
   When I execute MoveNext() it doesn't return the expected value
   (true).
  
   example code:
   (an extension to Roberts code here:
   http://go-mono.com/forums/#nabble-td1538089)
  
   c++-code:
   http://pastebin.com/aMHmnHRC
  
   c#-code:
   http://pastebin.com/MpktHBTB
  
   platform:
   Linux 2.6.38 64bit
   Mono git snapshot and 2.10.1
   GCC 4.6.0
  
  
  
   --
   View this message in context:
  
 http://mono.1490590.n4.nabble.com/Embedded-GetEnumerator-on-a-List-int-tp3425288p3425288.html
   Sent from the Mono - Dev mailing list archive at Nabble.com.
   ___
   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] [Embedded] GetEnumerator on a Listint

2011-04-04 Thread Zoltan Varga

Hi,

  Enumerator is probably a valuetype, and those have to be unbox-ed before
passing them to mono_runtime_invoke ().

   Zoltan

On Mon, Apr 4, 2011 at 2:10 PM, viktor.hermansson 
viktor.hermans...@gmail.com wrote:

 I have a problem to use an Enumerator in the unmaneged world.

 When I execute MoveNext() it doesn't return the expected value (true).

 example code:
 (an extension to Roberts code here:
 http://go-mono.com/forums/#nabble-td1538089)

 c++-code:
 http://pastebin.com/aMHmnHRC

 c#-code:
 http://pastebin.com/MpktHBTB

 platform:
 Linux 2.6.38 64bit
 Mono git snapshot and 2.10.1
 GCC 4.6.0



 --
 View this message in context:
 http://mono.1490590.n4.nabble.com/Embedded-GetEnumerator-on-a-List-int-tp3425288p3425288.html
 Sent from the Mono - Dev mailing list archive at Nabble.com.
 ___
 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] Trouble compiling Mono on Cygwin

2011-04-03 Thread Zoltan Varga

Hi,

  Try configure-ing with --with-nls=no.

   Zoltan

On Sun, Apr 3, 2011 at 8:49 AM, vinculum t...@raccoon-interactive.comwrote:

 Hi,

 Well now it downloads but I get the following error when it tries to
 extract
 things:

 Extracting to cygwin-deps/ ...tar (child): *.tar.gz: Cannot open: No such
 file or directory
 tar (child): Error is not recoverable: exiting now
 tar: Child returned status 2
 tar: Error is not recoverable: exiting now

 I removed the line from the script since it doesn't seem to download any
 tar.gz files, which is odd...

 Then another problem. I get this when building androidmono:

 : --update es.po mcs.pot
 rm -f es.gmo  : -c --statistics -o es.gmo es.po
 mv: cannot stat `t-es.gmo': No such file or directory
 make[4]: *** [es.gmo] Error 1
 make[4]: Leaving directory `/home/Timo
 Heubach/src/androidmono/hostbuild/mono/po
 /mcs'
 make[3]: *** [stamp-po] Error 2
 make[3]: Leaving directory `/home/Timo
 Heubach/src/androidmono/hostbuild/mono/po
 /mcs'
 make[2]: *** [all-recursive] Error 1
 make[2]: Leaving directory `/home/Timo
 Heubach/src/androidmono/hostbuild/mono/po
 '
 make[1]: *** [all-recursive] Error 1
 make[1]: Leaving directory `/home/Timo
 Heubach/src/androidmono/hostbuild/mono'
 make: *** [all] Error 2

 Is this a problem?

 -
 Timo Heinäpurola
 Raccoon Interactive

 http://www.raccoon-interactive.com
 @raccoon_int
 --
 View this message in context:
 http://mono.1490590.n4.nabble.com/Trouble-compiling-Mono-on-Cygwin-tp3421942p3423115.html
 Sent from the Mono - Dev mailing list archive at Nabble.com.
 ___
 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] Trouble compiling Mono on Cygwin

2011-04-03 Thread Zoltan Varga

mcs/configure is a leftover which was already removed in HEAD, use the one
the root directory of the source distribution.

 Zoltan

On Sun, Apr 3, 2011 at 9:18 AM, vinculum t...@raccoon-interactive.comwrote:

 Hi,

 Oh, I missed configuration all together... The documentation tells me to
 run
 ./configure --prefix=/tmp/install in the mono source directory. Which
 directory is this exactly? mono/mcs contains a configure script but it does
 not accept --with-nls. But doesn't mcs contain the C# code? So which
 configure to run?

 Thanks for the help so far :)

 -
 Timo Heinäpurola
 Raccoon Interactive

 http://www.raccoon-interactive.com
 @raccoon_int
 --
 View this message in context:
 http://mono.1490590.n4.nabble.com/Trouble-compiling-Mono-on-Cygwin-tp3421942p3423144.html
 Sent from the Mono - Dev mailing list archive at Nabble.com.
 ___
 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] Trouble compiling Mono on Cygwin

2011-04-02 Thread Zoltan Varga

Hi,

  You might want to try mono/scripts/get-cygwin-deps.sh instead of
downloading the dependencies manually.

   Zoltan

On Sat, Apr 2, 2011 at 12:37 PM, vinculum t...@raccoon-interactive.comwrote:

 Hi,

 I'm having trouble compiling Mono on Cygwin. The following links to
 dependencies are broken:

 * http://www.gimp.org/~tml/gimp/win32/pkgconfig-0.15.zip
 * http://www.gimp.org/~tml/gimp/win32/libiconv-1.9.1.bin.woe32.zip
 * http://www.gimp.org/~tml/gimp/win32/gettext-0.14.5.zip
 * http://www.gimp.org/~tml/gimp/win32/gettext-dev-0.14.5.zip
 *

 http://anonsvn.mono-project.com/viewvc/trunk/release/packaging/do-install-zip-pkgs?view=co

 The list is collected from here:
 http://www.mono-project.com/Compiling_Mono_on_Windows

 I've found newer versions of the packages but I can't find
 do-install-zip-pkgs anywhere, since anosvn.mono-project.com redirects me
 directly to git hub.

 I can't do a Visual Studio build because I'm building androidmono
 (https://github.com/koush/androidmono).

 -
 Timo Heinäpurola
 Raccoon Interactive

 http://www.raccoon-interactive.com
 @raccoon_int
 --
 View this message in context:
 http://mono.1490590.n4.nabble.com/Trouble-compiling-Mono-on-Cygwin-tp3421942p3421942.html
 Sent from the Mono - Dev mailing list archive at Nabble.com.
 ___
 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] [PATCH] Enable sgen on sparc and Solaris

2011-03-29 Thread Zoltan Varga

Yes.

  Zoltan

On Tue, Mar 29, 2011 at 4:09 PM, Dick Porter dpor...@codicesoftware.comwrote:

 On 01/10/2010 2:35PM, Dick Porter wrote:
  Hi all
 
  Attached is a patch that implements the arch-specific register handling
  code for sparc, and ports the x86 ucontext macros to OpenSolaris/x86
  (also enabling sgen for this platform).
 

 Ok to commit these patches to git head?

 - Dick
 ___
 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] Issue Building on Windows

2011-03-22 Thread Zoltan Varga

Hi,

  I think this is some kind of cygwin/mingw/gcc bug. If you run:

mono hello.exe; echo X

The X gets printed before the Hello, World, which means the 'mono'
executable doesn't wait for the real .libs/mono.exe executable to finish
before exiting.

.libs/mono.exe hello.exe; echo X

works fine.

   Zoltan

On Wed, Mar 9, 2011 at 4:46 AM, Jonathan Chambers jonc...@gmail.com wrote:

 Hello,

 I am doing some work on Windows, but am hitting a recurring problem when
 building via cygwin. The first time I build from a clean git checkout,
 things go fine. However, once I update and try another build I get a series
 of errors similar to:

 make[8]: Entering directory
 `/cygdrive/c/Users/Owner/Development/monogit/mono/mcs/tools/resgen'
 MCS [net_2_0] resgen.exe
 mv resgen.exe ./../../class/lib/net_2_0/resgen.exe
 mv: cannot stat `resgen.exe': No such file or directory
 make[8]: *** [../../class/lib/net_2_0/resgen.exe] Error 1
 make[8]: Leaving directory
 `/cygdrive/c/Users/Owner/Development/monogit/mono/mcs/tools/resgen'
 make[7]: *** [do-all] Error 2
 make[7]: Leaving directory
 `/cygdrive/c/Users/Owner/Development/monogit/mono/mcs/tools/resgen'
 make[6]: *** [all-recursive] Error 1
 make[6]: Leaving directory
 `/cygdrive/c/Users/Owner/Development/monogit/mono/mcs/class'
 make[5]: *** [all-recursive] Error 1
 make[5]: Leaving directory
 `/cygdrive/c/Users/Owner/Development/monogit/mono/mcs'
 make[4]: *** [profile-do--net_2_0--all] Error 2
 make[4]: Leaving directory
 `/cygdrive/c/Users/Owner/Development/monogit/mono/mcs'
 make[3]: *** [profiles-do--all] Error 2
 make[3]: Leaving directory
 `/cygdrive/c/Users/Owner/Development/monogit/mono/mcs'
 make[2]: *** [all-local] Error 2
 make[2]: Leaving directory
 `/cygdrive/c/Users/Owner/Development/monogit/mono/runtime'
 make[1]: *** [all-recursive] Error 1
 make[1]: Leaving directory
 `/cygdrive/c/Users/Owner/Development/monogit/mono'
 make: *** [all] Error 2

 resgen.exe does in fact exist
 at /cygdrive/c/Users/Owner/Development/monogit/mono/mcs/tools/resgen

 If I run 'make' again, it will get past this error and fail later on with
 similar errors. Any thoughts on what could be causing this?

 Thanks,
 Jonathan

 ___
 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] Patch for exceptions on 64 bit Windows

2011-03-18 Thread Zoltan Varga

Hi,

  Thanks for the patch. Applied it to HEAD/2.10.

Zoltan

On Mon, Feb 28, 2011 at 11:06 PM, Mark Sciabica msciab...@itracs.comwrote:

 Hi All,

 The attached patch fixes a crash when running a 64 bit build of Mono on
 windows. I simply modified the code to conform to the calling convention
 described here:
 http://msdn.microsoft.com/en-us/library/ms235286%28v=vs.80%29.aspx

 Regards,

 Mark

 This message and any attachments are solely for the intended recipient and
 may contain confidential or privileged information. If you are not the
 intended recipient, any disclosure, copying, use, or distribution of the
 information included in this message and any attachments is prohibited. If
 you have received this communication in error, please notify us by reply
 e-mail and immediately and permanently delete this message and any
 attachments. Thank you.

 ___
 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] Issue with inlining in the JIT

2011-03-08 Thread Zoltan Varga

Hi,

  Create a testcase and attach it to a bug report.

 Zoltan

On Wed, Mar 9, 2011 at 12:08 AM, Michael Mudge mich...@mudge.com wrote:

 I'm running into an access violation in Mono... I've traced the
 cause as far back as I can (mono_method_to_ir), but that function is
 so full of macros and switches that it's hard to figure out how it
 came to make the decision it did.  Here is the story of how the access
 violation occurs:

 ins-sreg1 is being set to 0xA365734 in method-to-ir.c, line 5928
 (call to EMIT_NEW_ARGLOAD call in the CEE_LDARG_3 case of
 mono_method_to_ir).

 The call stack at this point is:
 mono_method_to_ir  (working on Size::.ctor)
 .. called by inline_method()   (working on Size::.ctor)
 .. called by mono_method_to_ir()   (working on Rectangle::get_Size)
 .. called by inline_method()   (working on Rectangle::get_Size)
 .. called by mono_method_to_ir()   (working on
 TextRenderer::MeasureTextInternal)
 .. called by mini_method_compile() (working on
 TextRenderer::MeasureTextInternal)
 ..

 Later, in local-propagation.c, line 77 (at the call to
 mono_inst_get_src_registers in mono_local_cprop), the ins-sreg1 value
 is moved to sregs[0]:
  num_sregs = mono_inst_get_src_registers (ins, sregs);

 Two lines later, the value is moved to sreg:
  int sreg = sregs [i];

 Two lines later, that value (0xA365734) is used to index into an array:
  defs [sreg] = NULL;

 And boom, access violation.  I can follow values around all day, but I
 have no idea what this code is supposed to do or how it should work.
 Anyone have any insight the cause of this?  The next steps in terms of
 debugging?  I'm using Mono 2.8.2.

 - Kipp
 ___
 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] Unknown build error on Fedora x86_64

2011-03-07 Thread Zoltan Varga

Hi,

  Those files are created by our AOT compiler either directly using an ELF
writer, or by using as+ld. I assume rpm wants the Build ID added by gcc to
files it creates. You can
try removing the mscorlib.dll.so/mcs.exe.so files after the build, those
should not be part of the rpm package anyway.

On Mon, Mar 7, 2011 at 7:14 PM, Paul Johnson p...@all-the-johnsons.co.ukwrote:

 Hi,

 First, I'm getting further with the build for Mono on Fedora! However, I've
 hit this which I've never seen before. It seems to hit Fedora 14 as well as
 rawhide. Any ideas?

 *** ERROR: No build ID note found in
 /home/paul/rpmbuild/BUILDROOT/mono-2.10.1-1.fc16.x86_64/usr/lib64/mono/2.0/
 mcs.exe.so
 error: Bad exit status from /var/tmp/rpm-tmp.1YSSNm (%install)

 TTFN

 Paul

 ___
 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] mono 2.10.1 fails to build, Solaris 386

2011-03-04 Thread Zoltan Varga

Hi,

  Try removing -DFILE_OFFSET_BITS=64 from mono/profiler/Makefile.

 Zoltan

On Fri, Mar 4, 2011 at 5:44 PM, Francis A. Bausch fbau...@dracorp.comwrote:

 Mono 2.10.1 seems to have addressed our garbage collection problems on
 linux x86_64, though SGen is giving us problems on that platform. We'd like
 to transition all our platforms to 2.10.1, but Solaris builds are failing:

 building mono 2.10.1 with gcc 4.5.1 on Solaris 10u8:


 Making all in profiler
 make[3]: Entering directory
 `/export/home/dev/mono/mono-2.10.1/mono-2.10.1/mono/profiler'
 CC  mono-cov.lo
 LD  libmono-profiler-cov.la
 libtool: link: warning:
 `/STORM/2.1/opensource/i386-pc-solaris5.10/lib/gcc/i386-pc-solaris2.10/4.5.1/../../../libstdc++.la'
 seems to be moved
 CC  mono-profiler-aot.lo
 LD  libmono-profiler-aot.la
 libtool: link: warning:
 `/STORM/2.1/opensource/i386-pc-solaris5.10/lib/gcc/i386-pc-solaris2.10/4.5.1/../../../libstdc++.la'
 seems to be moved
 CC  mono-profiler-iomap.lo
 LD  libmono-profiler-iomap.la
 libtool: link: warning:
 `/STORM/2.1/opensource/i386-pc-solaris5.10/lib/gcc/i386-pc-solaris2.10/4.5.1/../../../libstdc++.la'
 seems to be moved
 CC  proflog.lo
 In file included from /usr/include/link.h:14:0,
 from proflog.c:37:
 /usr/include/libelf.h:24:2: error: #error large files are not supported by
 libelf
 proflog.c: In function 'mono_sample_hit':
 proflog.c:1195:3: warning: passing argument 1 of
 'InterlockedCompareExchangePointer' from incompatible pointer type
 ../../mono/io-layer/atomic.h:90:24: note: expected 'void * volatile*' but
 argument is of type 'volatile void **'
 proflog.c: At top level:
 proflog.c:1259:1: warning: 'dump_ubin' defined but not used
 proflog.c:1318:1: warning: 'read_elf_symbols' defined but not used
 make[3]: *** [proflog.lo] Error 1
 make[3]: Leaving directory
 `/export/home/dev/mono/mono-2.10.1/mono-2.10.1/mono/profiler'
 make[2]: *** [all-recursive] Error 1
 make[2]: Leaving directory
 `/export/home/dev/mono/mono-2.10.1/mono-2.10.1/mono'
 make[1]: *** [all-recursive] Error 1
 make[1]: Leaving directory `/export/home/dev/mono/mono-2.10.1/mono-2.10.1'
 make: *** [all] Error 2



 Francis A. Bausch | fbau...@dracorp.com | 703.299.0700 x213
 Data Research and Analysis Corp.  |  www.dracorp.com

 ___
 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] Mono-2.8.2 Cross Compiled for ARM processor (Interesting issue with Generics)

2011-03-01 Thread Zoltan Varga

Hi,

  Please attach a complete testcase which shows the problem.

Zoltan

On Tue, Mar 1, 2011 at 5:11 PM, Sean Hubbell sean.hubb...@gdc4s.com wrote:

 Why is that as it returns true on Windows?

 --
 View this message in context:
 http://mono.1490590.n4.nabble.com/Mono-2-8-2-Cross-Compiled-for-ARM-processor-Interesting-issue-with-Generics-tp3328883p3330068.html
 Sent from the Mono - Dev mailing list archive at Nabble.com.
 ___
 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] Mono Soft Debugger

2011-02-24 Thread Zoltan Varga

Hi,

   Our documentation is really quite incomplete, sorry about that. The
debugger is
modelled after the Java Debug Architecture:
http://java.sun.com/javase/technologies/core/toolsapis/jpda/

http://java.sun.com/javase/technologies/core/toolsapis/jpda/I.e. the
Mono.Debugger.Soft api is based on, an is very similar to the JDI API.

   Zoltan

On Thu, Feb 24, 2011 at 6:24 PM, Mikael Lyngvig mik...@lyngvig.org wrote:

  Hi,

 Anybody knows of good documentation for the Mono Soft Debugger?  I am
 hacking away on a hobby project that is a console mode debugger, but only
 have the Mono and MonoDevelop sources to guide me.  The documentation in
 Monodoc seems to very incomplete, which is understandable given the low
 number of people that are going to use this API.

 Especially, I'd like information on how to clean up after the debugging
 session is over.  I seem to get an unhandled exception (due to some Mono
 Soft Debugger code being blocked in a call to Socket.ReadBytes()) no matter
 what I do and it looks bad on the console.  I suspect that this exception
 has gone uncaught in other code, such as MonoDevelop, because it appears to
 occur in a separate thread and GUI apps don't output stuff to the console.
 Or, alternatively, I am simply not cleaning up and shutting down the debug
 session the way I should do.  That's definitely also a possibility.

 How do you terminate (prematurely or ultimately) a debug session up against
 Mono.Debugger.Soft.VirtualMachine?  I call vm.Exit(), vm.EndLaunch() and
 vm.CancelConnection(), but I still get an exception.

 I wouldn't mind a high-level description of how the soft debugger works
 (beyond that on the Mono website) and how one is supposed to code up against
 it.  I currently progress very slowly because everything is trial and error.


 Cheers,
 Mikael




 ___
 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] Trouble compiling tag 2.8.2

2011-02-18 Thread Zoltan Varga

Hi,

  You should try the recently released 2.10.

Zoltan

On Fri, Feb 18, 2011 at 4:24 PM, John Feminella jo...@bitsbuilder.comwrote:

 hello Mono-ers,

 I'm unable to compile the 2.8.2 tag, which I'm looking to do so I can
 get C# v4-level support and access to `dynamic`. My uname -a is:

 [/tmp/mono] uname -a
 Linux genesis 2.6.32-27-generic #49-Ubuntu SMP Thu Dec 2 00:51:09 UTC
 2010 x86_64 GNU/Linux

 I wanted BigArrays and parallel-mark, so I compiled with:

 ./autogen.sh --prefix=/opt --enable-big-arrays --enable-parallel-mark

 cc fails on libmono_2_0_la-mini-amd64.lo:

 [...]
 CClibmono_2_0_la-debug-debugger.lo
 CClibmono_2_0_la-xdebug.lo
 CClibmono_2_0_la-mini-amd64.lo
 make[4]: *** [libmono_2_0_la-mini-amd64.lo] Error 1
 make[4]: Leaving directory `/tmp/mono/mono/mini'
 make[3]: *** [all] Error 2
 make[3]: Leaving directory `/tmp/mono/mono/mini'
 make[2]: *** [all-recursive] Error 1
 make[2]: Leaving directory `/tmp/mono/mono'
 make[1]: *** [all-recursive] Error 1
 make[1]: Leaving directory `/tmp/mono'
 make: *** [all] Error 2

 This is on commit 84570ff in the git repo. Thoughts?

 ~ jf
 --
 John Feminella
 Principal Consultant, BitsBuilder
 LI: http://www.linkedin.com/in/johnxf
 SO: http://stackoverflow.com/users/75170/
 ___
 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] Trouble compiling tag 2.8.2

2011-02-18 Thread Zoltan Varga

You can try that, hopefully we will have a tag soon.

   Zoltan

On Fri, Feb 18, 2011 at 4:52 PM, John Feminella jo...@bitsbuilder.comwrote:

 Thanks, Zoltan. I don't see a 2.10 tag, though; is the tip of the 2.10
 branch the right place to be?

 ~ jf
 --
 John Feminella
 Principal Consultant, BitsBuilder
 LI: http://www.linkedin.com/in/johnxf
 SO: http://stackoverflow.com/users/75170/



 On Fri, Feb 18, 2011 at 10:46, Zoltan Varga var...@gmail.com wrote:
  Hi,
You should try the recently released 2.10.
  Zoltan
 
  On Fri, Feb 18, 2011 at 4:24 PM, John Feminella jo...@bitsbuilder.com
  wrote:
 
  hello Mono-ers,
 
  I'm unable to compile the 2.8.2 tag, which I'm looking to do so I can
  get C# v4-level support and access to `dynamic`. My uname -a is:
 
  [/tmp/mono] uname -a
  Linux genesis 2.6.32-27-generic #49-Ubuntu SMP Thu Dec 2 00:51:09 UTC
  2010 x86_64 GNU/Linux
 
  I wanted BigArrays and parallel-mark, so I compiled with:
 
  ./autogen.sh --prefix=/opt --enable-big-arrays --enable-parallel-mark
 
  cc fails on libmono_2_0_la-mini-amd64.lo:
 
  [...]
  CClibmono_2_0_la-debug-debugger.lo
  CClibmono_2_0_la-xdebug.lo
  CClibmono_2_0_la-mini-amd64.lo
  make[4]: *** [libmono_2_0_la-mini-amd64.lo] Error 1
  make[4]: Leaving directory `/tmp/mono/mono/mini'
  make[3]: *** [all] Error 2
  make[3]: Leaving directory `/tmp/mono/mono/mini'
  make[2]: *** [all-recursive] Error 1
  make[2]: Leaving directory `/tmp/mono/mono'
  make[1]: *** [all-recursive] Error 1
  make[1]: Leaving directory `/tmp/mono'
  make: *** [all] Error 2
 
  This is on commit 84570ff in the git repo. Thoughts?
 
  ~ jf
  --
  John Feminella
  Principal Consultant, BitsBuilder
  LI: http://www.linkedin.com/in/johnxf
  SO: http://stackoverflow.com/users/75170/
  ___
  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] Detect whether application is running on LLVM

2011-02-18 Thread Zoltan Varga

Hi,

  Not currently. You can add a wrapper shell script to your app and tell
people to use that
instead of using mono app.exe.

   Zoltan

On Fri, Feb 18, 2011 at 7:54 PM, no.human.being
qndre_encr...@hotmail.comwrote:


 Hello Mono-Devs!

 I am currently developing a long-running, computationally-intensive server
 application for distributed-computing. Now, obviously, this is an
 application which should be run using mono --llvm for performance reasons
 (application is performing computationally bound number-crunching tasks,
 startup delay is insignificant).

 Now I would like to detect, whether the application is running on LLVM or
 straight mono and display a nag message to remind the user that he will
 contribute more computing power by using the LLVM backend to execute his
 worker. Of course, this message should only be displayed when he the LLVM
 backend is not used.

 Is there any reliable way to detect whether LLVM or the default JIT
 backend is used?

 Thanks,
 Andre

 --
 View this message in context:
 http://mono.1490590.n4.nabble.com/Detect-whether-application-is-running-on-LLVM-tp3313342p3313342.html
 Sent from the Mono - Dev mailing list archive at Nabble.com.
 ___
 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] Porting to a other architecture

2011-02-17 Thread Zoltan Varga

Hi,

  A somewhat out-of-date document is here:

http://www.mono-project.com/Mono:Runtime:Documentation:MiniPorting

http://www.mono-project.com/Mono:Runtime:Documentation:MiniPorting
Zoltan

On Wed, Feb 16, 2011 at 8:13 PM, benjamin maes benjaminm...@gmail.comwrote:

 Hello, my name is benjamin maes,

 As thesis assignment I need to port mono too a blackfin DSP processer (on
 embedded linux (uclinux)). Although this thesis is just interested in how it
 is done in principe by writing a sort of tutorial.
 In this thesis I will only try to let work a hello world example. I am
 interested to people who have expierence in porting mono to a other
 architecture, what the best step plan is.
 (I know their are documents on mono-project, although sometimes it's a bit
 vague)

 When you know that I only need a hello world program too work, what would
 be the best way to find out what I would need to port of the existing code.

 I thought on looking at the IL of a hello world, and looking at the
 ecma-notes, would that be a correct way?

 I thank you for every response I would get from you,

 Regards, benjamin




 ___
 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] Patch for a bug when using sizeof with a generic

2011-02-13 Thread Zoltan Varga

Applied to HEAD/2.10/2.6. Thanks.

   Zoltan

On Sun, Feb 13, 2011 at 3:21 PM, Alexandre Mutel
alexandre_mu...@yahoo.frwrote:

Hi All,
 I would like to submit a patch for this bug:
 https://bugzilla.novell.com/show_bug.cgi?id=580189
 I’m using sizeof(T) in the SharpDX project (A fully managed .NET DirectX
 API http://code.google.com/p/sharpdx/) to be able to write efficiently
 structured data in memory. This instruction is not supported by C# but is a
 valid CLI (and can be in fact generated by C++/CLI). The impacted file is
 mono/mono/method-to-ir.c, in the mono_method_to_ir.

 Because some people are using SharpDX with Mono (and would like to use it
 with Unity), I found this bug (among some others) in Mono that is quite
 annoying to go further.

 Be indulgent for this patch, as I have just entered the mono source code
 this afternoon, and I’m not sure the patch is enough safe/correct, as the
 whole generic handling is still obscure to me.

 At least, this patch is solving my specific problem ,and I’m able to run
 SharpDX samples smoothly! :)

 Also, as a very new developer, I would like to make just a remark about the
 building process: I’m not hugely familiar with git, but It seems that
 default config for line termination is “autoclr”... which is breaking
 autogen.sh pre-build. This was annoying, as it is not stated in the
 mono-compiling for windows doc

 Thanks!

 ___
 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] 2.10~rc1 and dropped architectures

2011-01-31 Thread Zoltan Varga

Hi,


 === PowerPC ===

 On PowerPC, we fail to build fully - sn.exe keeps refusing to sign
 assemblies, which causes build failure. The only unusual thing in the
 build log is many CS8001 messages. On PowePC we must disable parallel
 mark, otherwise libgc does not build. Log:
 http://retro.apebox.org/mono210/buildlog.ppc

 PowerPC is one of the most popular minority architectures in Debian,
 and we would hate to lose it, especially when PowerPC is actively
 maintained in Mono for retro OSX machines, and PS3/Wii support.



This looks similar to something which has been fixed by
e6d990d8fadc5aafecd203c49f3b9.
That fix should be in 2.10 rc1, so I don't know what is happening here, our
build bots for
ppc work fine:
http://build.mono-project.com/ViewTable.aspx?host_id=14lane_id=112page=1limit=20

Zoltan


 ___
 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

1 2 3 4 5 6 7 8 >

1 - 100 of 718 matches

Mail list logo