Markus Beth | 4 May 13:22 2015
Picon

ReferenceSource of System.Text.UnicodeEncoding breaks System.Data.Odbc.OdbcDataReader.GetColumn(int)

Hi all,

System.Data.Odbc.OdbcDataReader.GetColumn(int) works fine for us 
(linux x86_64, unixODBC) in Mono 3.12.1, but it is broken in Mono 
4.0.1. The reason for this is that the ReferenceSource implementation 
of System.Text.UnicodeEncoding.GetString(byte[]) behaves differently 
when you call it with a byte[] of odd length.

mono 3.12.1:
csharp> System.Text.Encoding.Unicode.GetString(new byte[3]);
""
Which is a string of length 1 containing one '\x0' character.

mono 4.0.1:
csharp> System.Text.Encoding.Unicode.GetString(new byte[3]);
"?"
Which is a string of length 2 containing one '\x0' character followed
by a '?' (question mark)

We use the attached patch for Mono 4.0.1 which changes the
implementation of System.Data.Odbc.OdbcDataReader.GetColumn(int) to make
it work with either implementation of
System.Text.UnicodeEncoding.GetString.

Does it make sense to bring in patches like this or will
System.Data.Odbc be replaced by ReferenceSource in the (near) future?

Regards,
Markus
(Continue reading)

Neale Ferguson | 28 Apr 20:40 2015
Picon

Endian Question

The following test fails on s390x as the string that is encoded from the
decrypted block ends is in little endian order:

                public void FullRoundtripRead ()
                {
                        byte[] encrypted;
                        using (DebugStream mem1 = new DebugStream ()) {
                                byte[] toEncrypt =
Encoding.Unicode.GetBytes ("Please encode me!");
                                using (CryptoStream crypt = new
CryptoStream (mem1, aes.CreateEncryptor (), CryptoStreamMode.Write)) {
                                        crypt.Write (toEncrypt, 0,
toEncrypt.Length);
                                        crypt.FlushFinalBlock ();
                                }
                                encrypted = mem1.ToArray ();
                        }

                        using (DebugStream mem2 = new DebugStream
(encrypted)) {
                                byte[] buffer = new byte [1024];
                                CryptoStream cr = new CryptoStream (mem2,
aes.CreateDecryptor (), CryptoStreamMode.Read);
                                int len = cr.Read (buffer, 0,
buffer.Length);
                                cr.Close ();
                                Assert.AreEqual (34, len, "Full Length
Read");
                                Assert.AreEqual ("Please encode me!",
Encoding.Unicode.GetString (buffer, 0, len), "Full Block Read");
(Continue reading)

techi eth | 28 Apr 06:05 2015
Picon

WebSocket Support in Mono

Hi,

Is mono is supporting Websocket ?

When I look Web socket handling in HttpListnerRequest in .Net4.5 implementation in mono it is always returning False.(Flag : IsWebSocketRequest)

Thanks
_______________________________________________
Mono-devel-list mailing list
Mono-devel-list <at> lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
discofire | 27 Apr 23:42 2015
Picon

ODBC GetSchema failing

I have a very simple application that connects to an ODBC data source (MySQL
at the moment, but I plan on connecting to data sources without ADO.NET
drivers, and thus need ODBC support).  I am able to query the database
without any problems, and I can run GetSchema() in order to get a list of
valid collection names, however, when I attempt to run GetSchema("Tables")
or any other collection, I get what appears to be a recursive call from
GetSchema(string, string[]) and the program eventually crashes with a
StackOverflowException.

*Here is my code:*

 using System;
 using System.Data;
 using System.Data.Odbc;
 using System.Data.Common;

 public class Test
 {
    public static void Main(string[] args)
    {
       string connectionString =
"DRIVER={MySQL};SERVER=exagos01;PORT=3306;DATABASE=Northwind_Training;UID=root;PASSWORD=dba;OPTION=3";
       DbConnection dbcon;
       dbcon = new OdbcConnection(connectionString);
       dbcon.Open();

       DataTable dt = dbcon.GetSchema("Tables");
       //DataTable dt = dbcon.GetSchema();
       foreach(DataRow dr in dt.Rows) {
         for(int i=0; i<dt.Columns.Count; i++) {
           Console.Write(dr[dt.Columns[i].ColumnName]+&quot;\t&quot;);
         }
         Console.WriteLine();
       }

       DbCommand dbcmd = dbcon.CreateCommand();
       string sql = &quot;SELECT firstname, lastname FROM employees&quot;;
       dbcmd.CommandText = sql;
       IDataReader reader = dbcmd.ExecuteReader();
       while(reader.Read()) {
            string FirstName = (string) reader[&quot;firstname&quot;];
            string LastName = (string) reader[&quot;lastname&quot;];
            Console.WriteLine(&quot;Name: &quot; +
                FirstName + &quot; &quot; + LastName);
       }
    }
 }

&lt;b>And a small sample of the output (The actual output is thousands of
lines of the same error):*

  at System.Data.Odbc.OdbcConnection.GetSchema (string,string[]) <0x00033>
  at System.Data.Odbc.OdbcConnection.GetSchema (string,string[]) <0x00033>
  at System.Data.Odbc.OdbcConnection.GetSchema (string,string[]) <0x00033>
  at System.Data.Odbc.OdbcConnection.GetSchema (string,string[]) <0x00033>
  at System.Data.Odbc.OdbcConnection.GetSchema (string,string[]) <0x00033>
  at System.Data.Odbc.OdbcConnection.GetSchema (string,string[]) <0x00033>
  at System.Data.Odbc.OdbcConnection.GetSchema (string,string[]) <0x00033>
  at System.Data.Odbc.OdbcConnection.GetSchema (string,string[]) <0x00033>
  at System.Data.Odbc.OdbcConnection.GetSchema (string,string[]) <0x00033>
  at System.Data.Odbc.OdbcConnection.GetSchema (string,string[]) <0x00033>
  at System.Data.Odbc.OdbcConnection.GetSchema (string,string[]) <0x00033>
  at System.Data.Odbc.OdbcConnection.GetSchema (string,string[]) <0x00033>
  at System.Data.Odbc.OdbcConnection.GetSchema (string,string[]) <0x00033>
  at System.Data.Odbc.OdbcConnection.GetSchema (string,string[]) <0x00033>
  at System.Data.Odbc.OdbcConnection.GetSchema (string,string[]) <0x00033>
  at System.Data.Odbc.OdbcConnection.GetSchema (string,string[]) <0x00033>
  at System.Data.Odbc.OdbcConnection.GetSchema (string,string[]) <0x00033>
  at System.Data.Odbc.OdbcConnection.GetSchema (string,string[]) <0x00033>
  at System.Data.Odbc.OdbcConnection.GetSchema (string) <0x0001a>
  at Test.Main (string[]) <0x00089>
  at (wrapper runtime-invoke) <Module>.runtime_invoke_void_object
(object,intptr,intptr,intptr) <0xffffffff>

Any thoughts?  I haven't been successful in finding even a mention of this
problem online, and I haven't been able to come up with a reasonable
workaround... GetSchema is required (can't rely on PRAGMA statements since
the syntax can be different from one database to the next)

--
View this message in context: http://mono.1490590.n4.nabble.com/ODBC-GetSchema-failing-tp4665832.html
Sent from the Mono - Dev mailing list archive at Nabble.com.
Greg Young | 24 Apr 18:29 2015
Picon

HttpListener

I have been going through a bunch of this code lately after seeing
many ... interesting behaviours. I understand that much of the derp in
this code is due to not having IIS and MS having an IIS centric API
but wow. Some gems I have found...

1) synchronous dns calls being made...
2) I want to listen on 192.168.0.1:1234 but I want to support a host
header of whateverdomain can't resolve whatever domain then bind
listeners to all ips on machine.
3) Same as above but dns entry has multiple ips it resovles to [0]
doesnt match see #2
4) Anything at all to do with elastic ips
5) Exceptions thrown to calling code with http status codes in them (I
think this is ms legacy but is a pretty biog wtf)
6) failure parsing ip address says bind all interfaces on machine (huh?)

Perhaps it makes sense to expose a "Microsoft Http Compatibility
Layer" and then have a "Sane API if you want to use it"

I dont mind putting some time in on these but is this even worthwhile
or is the plan to just burn this code with fire and move to something
sane in general?

Cheers,

Greg
--

-- 
Studying for the Turing test
Neale Ferguson | 21 Apr 16:49 2015
Picon

mono-core.spec.in

Why was mono-core.spec.in dropped from the source? What is/will be used to
generate RPMS?

Neale
Greg Young | 16 Apr 14:35 2015
Picon

LLVM + mac deploys

I was looking through an issue from a mac user today.

Apparently when they brought down mono from home brew there were two
odds things.

1) It was 32bit. That's not really for this list though
2) It was using LLVM by default. Is LLVM ready for being the default
at this point? I haven't been following it much.

What is the current "best practice" for a mac user to be installing? I
run builds myself but figure there is a better way

Cheers,

Greg

--

-- 
Studying for the Turing test
Matthias Dittrich | 16 Apr 12:08 2015

Assemblies in the CLR system directory and F# scripting.

Hi all,

TL;DR: We should remove System.Web.Razor.dll, EntityFramework.dll (and
possibly more) from "/usr/lib/mono/4.5"

I noticed that some assemblies (namely "EntityFramework" and
"System.Web.Razor" and possibly more) lead to problems when used within
a F# script file. The problem is the following:

Assume you use NuGet to download the latest Razor-3 package and then do
the following (in an F# script file):

#I "packages/Microsoft.AspNet.Razor/lib/net45"
#r "System.Web.Razor.dll"

Note that this is the usual way of loading assemblies in F# scripting
and it works fine on Windows/.NET.

However because this is the same as using
"/lib:packages/Microsoft.AspNet.Razor/lib/net45
/reference:System.Web.Razor.dll" on the C# compiler and because mono has
a "System.Web.Razor.dll" in its CLR system directory (/usr/lib/mono/4.5)
it will redirect the reference (CLR system directory is always
preferred, see https://msdn.microsoft.com/en-us/library/s5bac5fx.aspx).

This already hit me several times:
 - https://github.com/fsharp/FSharp.Compiler.Service/issues/313
 - https://github.com/tpetricek/FSharp.Formatting/pull/279

I'm not really sure why mono actually needs those file to live there.
For referencing the NuGet package should be fine. To load the correct
(mono compatible) version on runtime the GAC should do it.
IMHO we can just remove the System.Web.Razor.dll (and possibly others?)
from the runtime directory.
 <at> akoeplinger noted the following in the gitter chat: It would be a
breaking change for people depending on "/reference:System.Web.Razor" to
just work.
But I'm not sure how common that is with the NuGet package in place.
IIRC xbuild and msbuild always use fully qualified references, so it
shouldn't be a problem for them.

So... Is removing those file something we can do? I just wanted to bring
attention to this issue as it can be *really* hard to debug. The
workarounds in place for this are required anyway to work with older
mono versions. The workaround in itself is simple you just need to use
the fully qualified reference instead:

#r "packages/Microsoft.AspNet.Razor/lib/net45/System.Web.Razor.dll"

However this can be a problem if you don't know in advance in which of
the included directories ("#I") the file is living. (Because F# will
stop executing if the fully qualified reference doesn't exists).

Thanks,
 Matthias
Fabian Pietsch | 15 Apr 15:21 2015
Picon

Build failure on ARMv6/Raspberry Pi with Raspbian/armhf

Hi,

I'm trying to compile Mono GIT mono-3.12.0-branch on the Raspberry
Pi (ARMv6), on Raspbian/armhf (Mono 3.2.8), with monolite-111-latest
3.6.1.0 as bootstrap compiler.

I'm building like this:

mono $ ./autogen.sh --prefix=/usr/local EXTERNAL_MCS="/home/pi/build/mono/mono/mcs/class/lib/monolite/gmcs.exe"
[...]
mono $ SKIP_AOT=true make
EXTERNAL_MCS="/home/pi/build/mono/mono/mcs/class/lib/monolite/gmcs.exe" V=1
[...]
make[8]: Entering directory '/home/pi/build/mono/mono/mcs/class/corlib'
/bin/sh ./../../mkinstalldirs ../../class/lib/build/
touch ../../class/lib/build//.stamp
MONO_PATH="./../../class/lib/basic:$MONO_PATH"
/home/pi/build/mono/mono/runtime/mono-wrapper  ./../../class/lib/basic/basic.exe
/codepage:65001 -unsafe -nostdlib -nowarn:612,618 -d:INSIDE_CORLIB -d:LIBC  -d:NET_1_1 -d:NET_2_0
-d:NET_3_0 -d:NET_3_5 -d:NET_4_0 -nowarn:1699 -nostdlib -lib:./../../class/lib/build  -optimize 
/noconfig -resource:resources/collation.core.bin
-resource:resources/collation.tailoring.bin -resource:resources/collation.cjkCHS.bin
-resource:resources/collation.cjkCHT.bin -resource:resources/collation.cjkJA.bin
-resource:resources/collation.cjkKO.bin -resource:resources/collation.cjkKOlv2.bin
--runtime:v4 -target:library -out:../../class/lib/build/mscorlib.dll   <at> corlib.dll.sources

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

This can be reproduced simply by this:

mono $ cd mcs/class/corlib
mono/mcs/class/corlib $ MONO_PATH="./../../class/lib/basic:$MONO_PATH"
/home/pi/build/mono/mono/runtime/mono-wrapper  ./../../class/lib/basic/basic.exe /help

Unhandled Exception:
System.TypeLoadException: Could not load type 'Mono.CSharp.CommandLineParser' from assembly
'basic, Version=3.12.1.0, Culture=neutral, PublicKeyToken=null'.
[ERROR] FATAL UNHANDLED EXCEPTION: System.TypeLoadException: Could not load type
'Mono.CSharp.CommandLineParser' from assembly 'basic, Version=3.12.1.0, Culture=neutral, PublicKeyToken=null'.

However, this is working fine:

mono/mcs/class/corlib $ ./../../class/lib/basic/basic.exe /help
Mono C# compiler, Copyright 2001-2011 Novell, Inc., Copyright 2011-2012 Xamarin, Inc
mcs [options] source-files
   --about              About the Mono C# compiler
   -addmodule:M1[,Mn]   Adds the module to the generated assembly
[...]

So the bootstrapped compiler itself can be run (on existing Mono), but the
newly built Mono or mscorlib.dll or something else is broken?

I already tried this from [1], but it did not help:
[1] http://lists.ximian.com/pipermail/mono-devel-list/2014-March/041222.html

$ git diff
diff --git a/mcs/build/profiles/basic.make b/mcs/build/profiles/basic.make
index 12f6c82..f93afab 100644
--- a/mcs/build/profiles/basic.make
+++ b/mcs/build/profiles/basic.make
 <at>  <at>  -12,7 +12,7  <at>  <at>  ifdef use_monolite
 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

Please advise at what else I can try.

Regards, Fabian
Fabian Nagel | 13 Apr 20:44 2015
Picon

Possible bug when using array of unsafe pointers

Dear Devs,

I tried to port my .NET C# application to run on Linux (Fedora21) through Mono, but it crashes somewhere in the runtime's garbage collector code with segmentation fault. The minimal code to reproduce the problem is as follows:
SomeStruct*[] ptrs = new SomeStruct*[1];
ptrs[0] = (SomeStruct*)Marshal.AllocHGlobal(4);
GC.Collect();

Here some further information:

[fabian <at> localhost Debug]$ mono --version
Mono JIT compiler version 3.12.1 (tarball Fri Mar  6 18:53:33 GMT 2015)
Copyright (C) 2002-2014 Novell, Inc, Xamarin Inc and Contributors. www.mono-project.com
TLS:           __thread
SIGSEGV:       altstack
Notifications: epoll
Architecture:  amd64
Disabled:      none
Misc:          softdebug 
LLVM:          supported, not enabled.
GC:            sgen

Stacktrace:

  at <unknown> <0xffffffff>
  at (wrapper managed-to-native) System.GC.InternalCollect (int) <IL 0x0000d, 0xffffffff>
  at System.GC.Collect () [0x00000] in /builddir/build/BUILD/mono-3.12.1/mcs/class/corlib/System/GC.cs:51
  at MMC.Benchmarks.MOT.TestTable (int,bool) [0x00010] in /home/fabian/Documents/New folder/MemoryContext/Benchmarks/MemoryOperationsTest.cs:227
  at MMC.Program.Main (string[]) [0x0050d] in /home/fabian/Documents/New folder/MemoryContext/Program.cs:379
  at (wrapper runtime-invoke) <Module>.runtime_invoke_void_object (object,intptr,intptr,intptr) <IL 0x00050, 0xffffffff>

Native stacktrace:

mono() [0x4b46c2]
mono() [0x50c893]
mono() [0x42ab73]
/lib64/libpthread.so.0(+0x100d0) [0x7f9bba5050d0]
/lib64/libc.so.6(+0x145e42) [0x7f9bba066e42]
mono() [0x5dd2f3]
mono() [0x5dd581]
mono() [0x5ddd98]
mono() [0x5d2d08]
mono() [0x5d2f0f]
mono() [0x5d4715]
mono() [0x5d5212]
mono() [0x5d87d0]
mono(mono_gc_collect+0x28) [0x5d9078]
[0x40337eb2]

Debug info from gdb:

warning: File "/usr/bin/mono-sgen-gdb.py" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load".
To enable execution of this file add
add-auto-load-safe-path /usr/bin/mono-sgen-gdb.py
line to your configuration file "/home/fabian/.gdbinit".
To completely disable this security protection add
set auto-load safe-path /
line to your configuration file "/home/fabian/.gdbinit".
For more information about this security protection see the
"Auto-loading safe path" section in the GDB manual.  E.g., run from the shell:
info "(gdb)Auto-loading safe path"
[New LWP 27513]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
0x00007f9bba504c6b in waitpid () from /lib64/libpthread.so.0
  Id   Target Id         Frame 
  2    Thread 0x7f9bb18ec700 (LWP 27513) "Finalizer" 0x00007f9bb9f55cc7 in sigsuspend () from /lib64/libc.so.6
* 1    Thread 0x7f9bbb021780 (LWP 27512) "mono" 0x00007f9bba504c6b in waitpid () from /lib64/libpthread.so.0

Thread 2 (Thread 0x7f9bb18ec700 (LWP 27513)):
#0  0x00007f9bb9f55cc7 in sigsuspend () from /lib64/libc.so.6
#1  0x00000000005cf99c in suspend_handler ()
#2  <signal handler called>
#3  0x00007f9bba50370e in sem_wait () from /lib64/libpthread.so.0
#4  0x0000000000625587 in mono_sem_wait ()
#5  0x00000000005a7fcd in finalizer_thread ()
#6  0x000000000058c370 in start_wrapper ()
#7  0x000000000062a466 in inner_start_thread ()
#8  0x00007f9bba4fc52a in start_thread () from /lib64/libpthread.so.0
#9  0x00007f9bba02122d in clone () from /lib64/libc.so.6

Thread 1 (Thread 0x7f9bbb021780 (LWP 27512)):
#0  0x00007f9bba504c6b in waitpid () from /lib64/libpthread.so.0
#1  0x00000000004b474f in mono_handle_native_sigsegv ()
#2  0x000000000050c893 in mono_arch_handle_altstack_exception ()
#3  0x000000000042ab73 in mono_sigsegv_signal_handler ()
#4  <signal handler called>
#5  0x00007f9bba066e42 in __memcpy_avx_unaligned () from /lib64/libc.so.6
#6  0x00000000005dd2f3 in copy_object_no_checks ()
#7  0x00000000005dd581 in major_copy_or_mark_object ()
#8  0x00000000005ddd98 in major_scan_object ()
#9  0x00000000005d2d08 in sgen_drain_gray_stack ()
#10 0x00000000005d2f0f in job_scan_from_registered_roots ()
#11 0x00000000005d4715 in major_copy_or_mark_from_roots ()
#12 0x00000000005d5212 in major_do_collection ()
#13 0x00000000005d87d0 in sgen_perform_collection ()
#14 0x00000000005d9078 in mono_gc_collect ()
#15 0x0000000040337eb2 in ?? ()
#16 0x00000000014ad120 in ?? ()
#17 0x00007ffd488929e0 in ?? ()
#18 0x0000000000000000 in ?? ()

=================================================================
Got a SIGSEGV 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 (core dumped)


Thanks,
Fabi
_______________________________________________
Mono-devel-list mailing list
Mono-devel-list <at> lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Neale Ferguson | 10 Apr 02:55 2015
Picon

Endianess in resource reading

I have tracked down the failure of the Windows.Forms tests and have found
it is due to the values that are extracted from the resource data. In
AllocateStringForNameIndex()
(external/referencesource/mscorlib/system/resources/resourcereader.cs) we
convert a char array to a string on the assumption the endianness is
correct. As s390x is big endian there needs to be a swap. This fragment of
code does the job but is it optimal?

                    if (!BitConverter.IsLittleEndian) {
                        byte* bytePtr = (byte*) charPtr;
                        var dest = new byte[byteLen];
                        for (int i = 0; i < byteLen; i += 2) {
                                dest[i] = *(bytePtr+i+1);
                                dest[i+1] = *(bytePtr+i);
                        }
                        fixed(byte *pDest = dest) {
                            s = new String((char *)pDest, 0, byteLen/2);
                        }
                    } else {
                        s = new String(charPtr, 0, byteLen/2);
                    }

Neale

Gmane