gmane.comp.gnome.mono.devel

Assertion not met when embedding mono

Marcelo Zabani — 2013-05-24T16:48:45

I'm trying to run a program that embeds mono and am receiving the following
error:

*TYPE: 32*
** Assertion at mini-amd64.c:487, condition `amd64_is_imm32 (disp)' not met*
*
*
*Stacktrace:*
*
*
*  at <unknown> <0xffffffff>*
*  at System.Console..cctor () <0x0001b>*
*  at (wrapper runtime-invoke) object.runtime_invoke_void
(object,intptr,intptr,intptr) <0xffffffff>*
*  at <unknown> <0xffffffff>*
*  at NamServer.RequestPipeline.Init () <0x0000b>*
*  at (wrapper runtime-invoke) object.runtime_invoke_void
(object,intptr,intptr,intptr) <0xffffffff>*

I tried running a regular .NET console program and it ran fine, so I have
no idea what this can be. I tried this with mono 3.0.10 and mono straight
from the github repository as of some time last night.
Also, this is not my "regular" mono installation. This is installed in a
separate directory, and thus I override some environment variables before
executing my program (LD_LIBRARY_PATH, MONO_PATH, MONO_GAC_PREFIX).

From the native stacktrace (which is rather large, s

Re: /mono/mini/main.c build error: depends on HAVE_SGEN_GC define, making it impossible to compile for sgen

Jeremy Bell — 2013-05-23T18:25:05

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

Re: /mono/mini/main.c build error: depends on HAVE_SGEN_GC define, making it impossible to compile for sgen

Zoltan Varga — 2013-05-23T17:39:34

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.jeremy< at >gmail.com> wrote:

_______________________________________________
Mono-devel-list mailing list
Mono-devel-list< at >lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: /mono/mini/main.c build error: depends on HAVE_SGEN_GC define, making it impossible to compile for sgen

Jeremy Bell — 2013-05-23T16:28:33

Thanks! I assumed I was moving to mono 3 by moving to the master branch on
git (I'm building from git). Is this not correct? Or am I missing some
configuration step? This issue is actually in the master branch (the
mono-2-10-9 branch builds just fine), which I assume is where the latest
development for mono 3.0 is being done.

Thanks,
Jeremy


On Thu, May 23, 2013 at 11:29 AM, Rodrigo Kumpera <kumpera< at >gmail.com> wrote:

_______________________________________________
Mono-devel-list mailing list
Mono-devel-list< at >lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: /mono/mini/main.c build error: depends on HAVE_SGEN_GC define, making it impossible to compile for sgen

Rodrigo Kumpera — 2013-05-23T15:29:32

mini.c should not have this. All files in mini should no longer depends on
either defines.

But please move to mono 3.0 as 2.10 is not longer been actively maintained.


On Thu, May 23, 2013 at 11:01 AM, Jeremy Bell <bell.jeremy< at >gmail.com> wrote:

_______________________________________________
Mono-devel-list mailing list
Mono-devel-list< at >lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

/mono/mini/main.c build error: depends on HAVE_SGEN_GC define, making it impossible to compile for sgen

Jeremy Bell — 2013-05-23T15:01:24

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

Fwd: Re: Mono on Solaris

Burkhard Linke — 2013-05-23T13:21:09

Forgot the CC to the list....

-------- Original Message --------
Subject: Re: [Mono-dev] Mono on Solaris
Date: Thu, 23 May 2013 15:16:46 +0200
From: Burkhard Linke <blinke< at >CeBiTec.Uni-Bielefeld.DE>
To: Matt Clay <Matt.Clay< at >earthclassmail.com>

Hi,

On 05/21/2013 07:56 PM, Matt Clay wrote:
I've built Mono 2.x releases for Solaris/x86. It's a major maintenance
nightmare, since Solaris has its own ideas about posix threads and
especially thread cancel handlers. If you do heavy threaded load, you
will likely run into deadlock within the garbage collection. At least
stock Boehm GC is affected by this problem. SGen does not work under
Solaris, too, with the binaries aborting and generating core dumps. I
didn't had the time to investigate this further. And since Solaris is a
dying operating system on our site, I'll probably not dig into this further.

If you want to try it, you'll definitely need a recent checkout of the
Boehm GC. And you should disable the dtrace support code, since it does
not compile.

Bu

Re: Mono on Solaris

Colin MacKenzie — 2013-05-21T18:26:23

Hi Matt,

I just tried 2 months ago to get it compiled on Solaris 10. I had a very difficult time even though I am pretty used to compiling my own packages. Testing new builds on Sol10 just doesn't seem a priority and I had to deal with mutually exclusive builds, a lot of out of date info on the net, etc. Dependencies were a big issue too. I ended up running out of time and building my project on CentOS but I feel like I was very close to getting it working. I had all dependencies compiled and down to only Mono errors.

I document everything I do in Evernote. Here is the link to my Solaris 10 Mono builds. It should help you out a lot.
http://www.evernote.com/shard/s29/sh/6e64d2e5-472e-4d60-abf4-6a7008a6c3d9/47dcbfe31074563a3d7980f0ebef9029

Good luck! And if you are successful definitely let me know.
Colin

-----Original Message-----
From: mono-devel-list-bounces< at >lists.ximian.com [mailto:mono-devel-list-bounces< at >lists.ximian.com] On Behalf Of Matt Clay
Sent: Tuesday, May 21, 2013 1:56 PM
To: mono-devel-list< at >l

Mono on Solaris

Matt Clay — 2013-05-21T17:56:26

Hi,

Does anyone still maintain support for Mono on Solaris, specifically for SPARC?

There are no Solaris packages on the download page for 3.x and the Solaris SPARC package for 2.10.5 is missing the .NET 4.0 class libraries.

- Matt

Processing XML atomic values in XML Schema

Tobias Kiertscher — 2013-05-21T11:52:10

Hi,

I tried to run code with XML schema based validation on mono 2.10.8 and
3.0.10 that works fine on mono 2.6.7. But the processing of atomic
datatypes like (unsignedInt, duration, gYear, hexBinary, anyURI, ...)
seems to be broken after 2.6.7. And the datatype gMonth seems to be
buggy in all versions.

The code to verify the behavior is:
http://github.com/mastersign/mono-xml-schema-bug/blob/master/Program.cs

The output for mono 2.6.7, 2.10.8, 3.0.10 and MS .NET 3.5 is:
http://github.com/mastersign/mono-xml-schema-bug/blob/master/results.txt

Please give me feedback if you can verify the bug. In my opinion this
issue renders the XML schema support unusable for now.

Best regards,
Tobias Kiertscher <dev< at >mastersign.de>

DateTime.ToBinary / TZ differences between windows andlinux

David Schmitt — 2013-05-21T09:27:34

Hi,

I've used DateTime.ToBinary() to serialize dates between linux (mono) 
and windows (ms.net). All dates are in CEST (central european standard 
time), but the timezone's definitions differs between mono and ms.net, 
causing the "wrong" time to be displayed.

On a recent mono 3.x:


ms.net on the other hand returns true for both calls. This in turn leads 
to ToUniversal() to return different times.

mono's implementation is arguably more correct with regards to reality, 
as 1979-06-30 really did *not* have DST and 1980-06-30 really *did* have 
DST.


Of course, the best way to work around this would be to convert the 
complete application and database to use UTC, except when displaying to 
the user. This is already on the roadmap for other reasons. ;-)


The questions for mono-devel are rather:

   * Is this behavior intentional?
   * Is there a quick workaround to match mono's and ms.net's behavior?


Regards, David

System.IO.IOException: The authentication or decryptionhas failed.

Eddy Zavaleta — 2013-05-21T07:56:10

Hi,

I'm trying to use a webservice using client certificate for authentication.
I created the C# proxies using svcutil.exe on windows and everything works
(MS .NET) but when I tested on Mono 3.0.10 / Mac OS X 10.8.3 I get this
error.

I've created a test for this and put it at
https://github.com/ezavaleta/web-request-test

I tried to made the test as simple as possible using HttpWebRequest and
posting xml data from a file to simulate the soap request, this also works
on MS .NET but not on mono.

I've discoverd that the POST request eventually works after some retries if
a GET request is made first which always works.

StackTrace:
System.Net.WebException: Error getting response stream (ReadDone1):
ReceiveFailure ---> System.IO.IOException: The authentication or decryption
has failed. ---> Mono.Security.Protocol.Tls.TlsException: The
authentication or decryption has failed.
  at Mono.Security.Protocol.Tls.RecordProtocol.ProcessAlert (AlertLevel
alertLevel, AlertDescription alertDesc) [0x00000] in <filename un

Re: AMD64 AOT code and bad IMT

Zoltan Varga — 2013-05-21T02:23:07

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 <gavin< at >wholesalealgorithms.com>wrote:

_______________________________________________
Mono-devel-list mailing list
Mono-devel-list< at >lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: AMD64 AOT code and bad IMT

Wholesale — 2013-05-21T02:13:14

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 <vargaz< at >gmail.com> wrote:

_______________________________________________
Mono-devel-list mailing list
Mono-devel-list< at >lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: AMD64 AOT code and bad IMT

Zoltan Varga — 2013-05-20T23:52:11

Hi,

On Tue, May 21, 2013 at 1:37 AM, Gavin Dodd
<gavin< at >wholesalealgorithms.com>wrote:


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


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



_______________________________________________
Mono-devel-list mailing list
Mono-devel-list< at >lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

AMD64 AOT code and bad IMT

Gavin Dodd — 2013-05-20T23:37:02

Hi,

I'm new to Mono so I'm not sure if this is the right list. Please point me in the right direction if this isn't the place to ask these questions.

I'm trying to get AOT compiled code to run on an embedded AMD 64 system. 


It is crashing the first time it hits a method call requiring an IMT because the pointer is incorrect

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,

The problem shows up in


common_call_trampoline(mgreg_t* regs, guint8* code, gpointer arg, guint8* tramp, MonoVTable* vt, gpointer* vtable_slot, gboolean need_rgctx_tramp) Line 320    C++

    if (m == MONO_FAKE_IMT_METHOD) {
        MonoMethod *impl_method;
        MonoObject *this_arg;

        /* we get the interface method because mono_convert_imt_slot_to_vtable_slot ()
         * needs the signature to be able to find the this argument
         */
        m = mono_arch_find_imt_method (re

Re: Mono 3.0.10: channel type IRequestSessionChannel isnot supported.

Andres G. Aragoneses — 2013-05-17T07:37:53

Line 85 of HttpChannelFactory?

Re: Mono 3.0.10: channel type IRequestSessionChannel is not supported.

ticapix — 2013-05-17T06:16:48

I don't understand how to apply the proposed fix
(http://permalink.gmane.org/gmane.comp.gnome.mono.devel/40283) in my case 
:(

Which of the 6 frames of the stacktrace should be modified ?



--
View this message in context: http://mono.1490590.n4.nabble.com/Mono-3-0-10-channel-type-IRequestSessionChannel-is-not-supported-tp4659668p4659681.html
Sent from the Mono - Dev mailing list archive at Nabble.com.

Re: Building source fails: gmcs command not found

Marek Safar — 2013-05-16T13:46:17

Hi,

I'm trying to build Mono from the git source under a brand-new installation


You need working mono installation to build mono. You can install it from
available sources or you can try to do make get-monolite-latest.

Marek


_______________________________________________
Mono-devel-list mailing list
Mono-devel-list< at >lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: Building source fails: gmcs command not found

Chris Tacke — 2013-05-16T13:36:16

Tried the same thing under OpenSUSE 12.3 and I get the same failure, so I'm thinking it's not an environment problem, but a source code problem.

-Chris

Building source fails: gmcs command not found

Chris Tacke — 2013-05-15T19:43:15

I'm trying to build Mono from the git source under a brand-new installation of Fedora 18.

I'm following the instructions here:

http://www.mono-project.com/Compiling_Mono_From_Git

When I run make, I'm getting a failure after a while while it's attempting to make the runtime folder:

if test -w /rootmono/mcs; then :; else chmod -R +w /root/mono/mcs; fi
cd /root/mono/mcs && make --no-print-director -s NO_DIR_CHECK=1 PROFILES=' net_2_0 net_3_5 net_4_0 net_4_5 ' CC='gcc' all-profiles
make[6] gmcs: Command not found

Now I'm pretty new to Mono - very, very new to trying to build it (first time) so I've got a steep learning curve to climb, but my reading of this:

http://www.mono-project.com/CSharp_Compiler

 is that gmcs is the old compiler for 2.0 and mcs should be what's being used for newer stuff.

So I have a few questions.

First, and most obviously, is how do I get Mono to build in this environment.
Second, though, is I'd like to understand why this is failing.  Why is it trying to use gmcs in the first p