Re: [Mono-dev] System.Messaging, a (just) working implementation
Oops, sorrry, I was dead for couple of days and after that it has dropped from my mind for a while. Here's my quick survey: - You cannot add any public extra stuff (such as Mono.Messaging.* classes) in System.Messaging.dll. You have to create another assembly (such as Mono.Messaging.dll) and use it together with System.Messaging.dll. It is sort of mess, as either - System.Messaging.dll depends on your extra assembly and hence yours cannot use any types in System.Messaging.dll (e.g. you cannot define IQueue.Deliver), or - your extra assembly depends on System.Messaging.dll and hence any types in yours inside System.Messaging.dll must be used through some reflection foo, or - you have to run cyclic build between those two assemblies (we do it for System.dll, System.Configuration.dll and System.Xml.dll, which is a mess). - At least MessageQueue.Create() should be implemented (otherwise it is not practically functional as System.Messaging.dll). It would have to be done by some configuration support to indicate one IMessagingProvider, and it must not be dependent on System.Configuration.dll which is 2.0-only. - It would provide only simple part of Sys.Messaging functionality (it would apply to any JMS/AMQP based solution). We could still go with your bridge implementation for a while as a compromised solution though. And as Miguel pointed out, we would have to avoid your GPLv3-based component as run-time dependency. I have some comments on the patch details, but I'd put my general survey first :) Atsushi Eno Michael Barker wrote: > Hi, > > As I mentioned a couple of days ago I have a 0.0.1 version of a bridge > between Mono and QPid. I have placed the code and a patch that adds an > SPI to Mono on google code. http://code.google.com/p/mono-qpid/ > > There is quite a bit missing from the implementation, but basic sending > and receiving with XML and Binary formatting works. > > Regards, > Michael Barker. > ___ > 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] Add mixed-mode assembly support on Windows (now build with cygwin as well)
Hi,
Previously I forgot to try _CorDllMain to load the runtime when it hasn't
been loaded yet. As a result I found that thread_started_event in
mono/mono/metadata/gc.c causes a deadlock in this situation because
_CorDllMain is callled while the OS loader lock is held by the current
thread and no new threads are started while OS loader lock is held. After
examining the purpose of thread_started_event I found that unlike the
comment states it is not required at all so I removed it completely. This
will make startup faster as well. I also checked that finalizer_thread is
called and reaches SetEvent (shutdown_event) at the end.
My test confirmed that Mono even supports mixed-mode assemblies with
exported symbols if they were native DLLs just like MS.NET does.
Kornél
- Original Message -
From: Kornél Pál
To: mono-devel
Sent: Friday, April 25, 2008 12:31 AM
Subject: Re: [Mono-dev] [PATCH] Add mixed-mode assembly support on Windows
(now build with cygwin as well)
Hi,
I also modified Makefile to export __stdcall functions without mangling
and
create-windef.pl to include MonoFixupCorEE. Other than these there are no
modifications.
Kornél
- Original Message -
From: Kornél Pál
To: mono-devel; Robert Jordan
Sent: Wednesday, April 23, 2008 2:40 PM
Subject: Re: [Mono-dev] [PATCH] Add mixed-mode assembly support on Windows
(now build with cygwin as well)
From: Robert Jordan
I think the following code is from another patch set (the cmd line
encoding issue you sent a patch for). Is it complete?
Index: mono/mono/mini/main.c
Yes, it is. I included it in this patch to be consistent with _CorExeMain
implementation. Also note that command line arguments are parsed as UTF-8
without MONO_EXTERNAL_ENCODINGS. MONO_EXTERNAL_ENCODINGS should not be
supported on Windows, Unicode API should be used instead. Patching main
will
make Mono support non-ASCII command line arguments on Windows. Also note
that because images are loaded using LoadLibrary file names are expected
to
be in UTF-8 that is supported by this main function patch. I still would
vote for removing MONO_EXTERNAL_ENCODINGS support on Windows but that is
out
of the scope of this patch.
If this is solved, I will try to fix the cygwin build.
I managed to fix the build. #include had to be moved out of
#ifdef PLATFORM_WIN32 because PLATFORM_WIN32 is defined in config.h in
the
cygwin build.
Please review the patch. Please try it on Linux as well to make sure that
it
doesn't break Linux. And if you like it, please approve the patch.
Kornél
Index: mono/libgc/win32_threads.c
===
--- mono/libgc/win32_threads.c (revision 101236)
+++ mono/libgc/win32_threads.c (working copy)
@@ -782,7 +782,7 @@
* Pontus Rydin suggests wrapping the thread start routine instead.
*/
#if defined(GC_DLL) || defined(GC_INSIDE_DLL)
-BOOL WINAPI DllMain(HINSTANCE inst, ULONG reason, LPVOID reserved)
+BOOL WINAPI GC_DllMain(HINSTANCE inst, ULONG reason, LPVOID reserved)
{
switch (reason) {
case DLL_PROCESS_ATTACH:
Index: mono/libgc/include/gc.h
===
--- mono/libgc/include/gc.h (revision 101236)
+++ mono/libgc/include/gc.h (working copy)
@@ -922,6 +922,8 @@
#if defined(GC_WIN32_THREADS) && !defined(__CYGWIN32__) && !defined(__CYGWIN__)
# include
+ BOOL WINAPI GC_DllMain(HINSTANCE inst, ULONG reason, LPVOID reserved);
+
/*
* All threads must be created using GC_CreateThread, so that they will be
* recorded in the thread table. For backwards compatibility, this is not
Index: mono/mono/metadata/loader.c
===
--- mono/mono/metadata/loader.c (revision 101236)
+++ mono/mono/metadata/loader.c (working copy)
@@ -1394,12 +1394,20 @@
if (cols [1] & METHOD_IMPL_ATTRIBUTE_INTERNAL_CALL) {
if (result->klass == mono_defaults.string_class && !strcmp (result->name,
".ctor"))
result->string_ctor = 1;
- } else if ((cols [2] & METHOD_ATTRIBUTE_PINVOKE_IMPL) && (!(cols [1] &
METHOD_IMPL_ATTRIBUTE_NATIVE))) {
+ } else if (cols [2] & METHOD_ATTRIBUTE_PINVOKE_IMPL) {
MonoMethodPInvoke *piinfo = (MonoMethodPInvoke *)result;
- MonoTableInfo *im = &tables [MONO_TABLE_IMPLMAP];
+#ifdef PLATFORM_WIN32
+ /* IJW is P/Invoke with a predefined function pointer */
+ if (image->is_module_handle && (cols [1] &
METHOD_IMPL_ATTRIBUTE_NATIVE)) {
+ piinfo->addr = mono_image_rva_map (image, cols [0]);
+ g_assert (piinfo->addr);
+ }
+#endif
piinfo->implmap_idx = mono_metadata_implmap_from_method (image,
idx - 1);
- piinfo->piflags = mono_metadata_decode_row_col (im,
piinfo->implmap_idx - 1, MONO_IMPLMAP_FLAGS);
+ /* native methods can have no map */
+
Re: [Mono-dev] Win64 Stack Arguments Patch
Hi,
This is ok to check in.
Zoltan
2008/4/25 Jonathan Chambers <[EMAIL PROTECTED]>:
> Hello,
> After getting some help on IRC I rewrote these changes. With this new
> patch, most of the regressions in mono/mono/mini run successfully (exception
> handling is not working).
>
>
> Code contributed under MIT/X11 license.
>
> Thanks,
> Jonathan
>
>
>
> On Wed, Apr 23, 2008 at 9:07 AM, Jonathan Chambers <[EMAIL PROTECTED]>
> wrote:
> > Sorry, forgot to attach patch.
> >
> > Thanks,
> > Jonathan
> >
> >
> >
> >
> >
> > On Wed, Apr 23, 2008 at 8:15 AM, Jonathan Chambers <[EMAIL PROTECTED]>
> wrote:
> >
> > > Hello,
> > > This patch attempts to fix arguments passed on the stack for
> Winx64. Please let me know if the approach is acceptable, or if there is a
> better way.
> > >
> > > The next roadblack has to do with arrays. I am getting a type load
> exception when initializing the System.String class because it tries to
> initialize a static array in the class (WhiteChars I believe), and the call
> to ves_icall_System_Runtime_CompilerServices_RuntimeHelpers_InitializeArray
> fails because the
> > >
> > > if (!(field_handle->type->attrs & FIELD_ATTRIBUTE_HAS_FIELD_RVA)) {
> > >
> > > check fails. Any thoughts on the cause of this would be appreciated.
> > >
> > > Code contributed under MIT/X11 license.
> > >
> > > 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] System.Messaging, a (just) working implementation
On Fri, Apr 25, 2008 at 10:30 AM, Atsushi Eno <[EMAIL PROTECTED]> wrote: > Oops, sorrry, I was dead for couple of days and after that it has dropped > from my mind for a while. No problem, thanks for responding. > Here's my quick survey: > > - You cannot add any public extra stuff (such as Mono.Messaging.* classes) > in System.Messaging.dll. You have to create another assembly (such as > Mono.Messaging.dll) and use it together with System.Messaging.dll. That's interesting, I looked at System.Data initially, which included Mainsoft namespace classes, so I thought adding a different namespace into the same namespace would be okay. I am happy to change that. > It is sort of mess, as either > > - System.Messaging.dll depends on your extra assembly and hence yours > cannot use any types in System.Messaging.dll (e.g. you cannot define > IQueue.Deliver), or This is probably the easiest, but is adding a compile time dependency for System.Messaging.dll on another assembly acceptable? I assume we shouldn't be adding additional public classes to the System.* namespaces. - your extra assembly depends on System.Messaging.dll and hence any > types in yours inside System.Messaging.dll must be used through some > reflection foo, or > - you have to run cyclic build between those two assemblies (we do it > for System.dll, System.Configuration.dll and System.Xml.dll, which is > a mess). > > - At least MessageQueue.Create() should be implemented (otherwise it is not > practically functional as System.Messaging.dll). It would have to be done > by some configuration support to indicate one IMessagingProvider, and it > must not be dependent on System.Configuration.dll which is 2.0-only. > > - It would provide only simple part of Sys.Messaging functionality (it > would > apply to any JMS/AMQP based solution). We could still go with your > bridge implementation for a while as a compromised solution though. That's true, however the AMQP spec is not yet finished. I believe that there will be browsing and selector support in some of the later revisions. This will mean that the majority of the System.Messaging functionality is covered (including MessageQueue.Peek and MessageQueue.ReceiveById). The parts that probably won't be covered would be some of the specifics around the additional system queues (e.g. journal queues). Although AMQP does support sophisticated routing rules so it may be possible to emulate some of those features. I was hoping by adding a provider layer, other implementations could be added later, e.g. OpenWire for ActiveMQ or something Mono specific. > > > And as Miguel pointed out, we would have to avoid your GPLv3-based > component > as run-time dependency. I didn't see Miguel's message, but that is my mistake, it shouldn't of been v3. Is LGPL okay or would MIT be easiest for Mono? I have some comments on the patch details, but I'd put my general survey > first :) > > Atsushi Eno Unfortunately my timing here is not the best. I am about to head off travelling for about 4 months, so I won't be able to make any major changes until September. I'll fix the license and add MessageQueue.Create support before I go. I still want to help build a System.Messaging implemenation so I would be happy to receive any feedback you have in order to build something that will be useful for Mono. System.Messaging hasn't been touched a few years, so a few more months shouldn't hurt :-). Regards, Michael Barker. > > > Michael Barker wrote: > >> Hi, >> >> As I mentioned a couple of days ago I have a 0.0.1 version of a bridge >> between Mono and QPid. I have placed the code and a patch that adds an SPI >> to Mono on google code. http://code.google.com/p/mono-qpid/ >> >> There is quite a bit missing from the implementation, but basic sending >> and receiving with XML and Binary formatting works. >> >> Regards, >> Michael Barker. >> ___ >> 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] SIGILL in finally clause without catch
Hi,
Mono throws that exception when it receives a SIGILL signal while
executing some
code. If it receives it while executing native code, it appears that
it is thrown by
the (managed-to-native) wrapper. So the problem is usually in the native code.
What platform/os is this ?
Zoltan
2008/4/23 Christian Stümpel <[EMAIL PROTECTED]>:
> In code I have to port from MS .NET to mono I observed several SIGILL
> crashes at points in code, where calls to external code are made within a
> try block followed by a finally but *without* a catch statement.
>
>
> try {
> unrar.dosomething();
> throw new Exception("test");
> }
>
> // no catch here
>
> finally
> {
> unrar.close(); // calls unmanaged code
>
> }
>
> The unmanaged code called in unrar.dosomething() is C++ code compiled with
> exceptions enabled but it does not throw the exception, but the managed code
> that follows. The call to unrar.close() (which does not throw any exception)
> in the finally clause crashes with:
>
> System.ExecutionEngineException: SIGILL at (wrapper managed-to-native)
> NntpApp.nntp.rar.Unrar:RARCloseArchive (intptr) at
> NntpApp.nntp.rar.Unrar.Close () [0x0] at
> usenextapp.FilegroupPreview.ExtractFileFromRar (System.String path)
> [0x0]
>
> The SIGILL does not appear if I catch the exception and rethrow it in the
> finally clause
>
> Exception e=null;
>
> try {
> unmanaged1();
> throw new Exception("test");
> }
>
> catch(Exception ex)
> {
> e= ex;
> }
>
> finally
> {
> cleanup();
> if (e!=null)
> throw e;
> }
>
> Any thoughts on that?
>
> Christian Stümpel
>
>
>
> ___
> 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-dev] mono SEGFAULT problem
Hi, everibody Since about a week, my SMTP Server (which is in C#/mono) crashes about 1 time /day... It's a multithreaded program that work on an RHEL4 server with 3 double-core processor and 16Gio RAM. The segfaults appears randomly... and i cannot reproduce the bug on my devs and beta machine. My program doesn't call any C library, so the crash seems to be on mono itself I'm running mono 1.9.1 (it crashes too with mono 1.2.6) without gdb it crashes with: Stacktrace: Native stacktrace: mono [0x8152f80] mono [0x807819a] /lib/tls/libpthread.so.0 [0x6b2890] mono [0x813bc94] mono [0x80bd5c1] mono [0x80bdd0a] mono [0x8102656] mono [0x8116769] /lib/tls/libpthread.so.0 [0x6ac371] /lib/tls/libc.so.6(__clone+0x5e) [0x535ffe] Debug info from gdb: = 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 I've run my program with Gdb [New Thread 66501552 (LWP 7705)] [Thread 117857200 (LWP 7700) exited] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 19356592 (LWP 4481)] mono_debugger_thread_cleanup (jit_tls=0x85ba670) at debug-mini.c:802 802 if (info->jit_tls != jit_tls) (gdb) bt #0 mono_debugger_thread_cleanup (jit_tls=0x85ba670) at debug-mini.c:802 #1 0x08148794 in mini_thread_cleanup (thread=0xb6f5ce70) at mini.c:9670 #2 0x080c4860 in thread_cleanup (thread=0xb6f5ce70) at threads.c:509 #3 0x080c4fc1 in start_wrapper (data=0xb66a7fa0) at threads.c:605 #4 0x0810d09e in thread_start_routine (args=0xb78a4938) at threads.c:282 #5 0x08121b19 in GC_start_routine (arg=0xb65aa9a0) at pthread_support.c:1369 #6 0x006ac371 in start_thread () from /lib/tls/libpthread.so.0 #7 0x00535ffe in clone () from /lib/tls/libc.so.6 (gdb) q The program is running. Exit anyway? (y or n) y [EMAIL PROTECTED] Server]# Could someone help me please It seems this is a GC issue _ Ce message et les éventuels documents joints peuvent contenir des informations confidentielles. Au cas où il ne vous serait pas destiné, nous vous remercions de bien vouloir le supprimer et en aviser immédiatement l'expéditeur. Toute utilisation de ce message non conforme à sa destination, toute diffusion ou publication, totale ou partielle et quel qu'en soit le moyen est formellement interdite. Les communications sur internet n'étant pas sécurisées, l'intégrité de ce message n'est pas assurée et la société émettrice ne peut être tenue pour responsable de son contenu. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] WebMethod attribute
** High Priority **
Hi,
I'm using a WebMethod attribute in my app. The transaction is failing with
version mono-1.2.6 however it is successful
with version 1.2.5.
Here is the snippet that I'm using..
[WebMethod, Privilege ("view")]
public string Ping () {
log.Info("Got ping request from client") ;
return String.Format ("pong");
}
The same code run on mono-1.2.5 runtime goes fine and I get pong as response..
But not on 1.2.6.
Any idea whats wrong with 1.2.6.
Thanks,
Vadiraj
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] SIGILL in finally clause without catch
Hi Zoltan,
> the (managed-to-native) wrapper. So the problem is usually in the
> native code.
>
But then why does introducing the "catch" and rethrowing resolve the
matter?
platform is Mac OS X i386.
Christian
Am 25.04.2008 um 12:01 schrieb Zoltan Varga:
> Hi,
>
> Mono throws that exception when it receives a SIGILL signal while
> executing some
> code. If it receives it while executing native code, it appears that
> it is thrown by
> the (managed-to-native) wrapper. So the problem is usually in the
> native code.
>
> What platform/os is this ?
>
>Zoltan
>
> 2008/4/23 Christian Stümpel <[EMAIL PROTECTED]>:
>> In code I have to port from MS .NET to mono I observed several SIGILL
>> crashes at points in code, where calls to external code are made
>> within a
>> try block followed by a finally but *without* a catch statement.
>>
>>
>> try {
>> unrar.dosomething();
>> throw new Exception("test");
>> }
>>
>> // no catch here
>>
>> finally
>> {
>> unrar.close(); // calls unmanaged code
>>
>> }
>>
>> The unmanaged code called in unrar.dosomething() is C++ code
>> compiled with
>> exceptions enabled but it does not throw the exception, but the
>> managed code
>> that follows. The call to unrar.close() (which does not throw any
>> exception)
>> in the finally clause crashes with:
>>
>> System.ExecutionEngineException: SIGILL at (wrapper managed-to-
>> native)
>> NntpApp.nntp.rar.Unrar:RARCloseArchive (intptr) at
>> NntpApp.nntp.rar.Unrar.Close () [0x0] at
>> usenextapp.FilegroupPreview.ExtractFileFromRar (System.String path)
>> [0x0]
>>
>> The SIGILL does not appear if I catch the exception and rethrow it
>> in the
>> finally clause
>>
>> Exception e=null;
>>
>> try {
>> unmanaged1();
>> throw new Exception("test");
>> }
>>
>> catch(Exception ex)
>> {
>> e= ex;
>> }
>>
>> finally
>> {
>> cleanup();
>> if (e!=null)
>> throw e;
>> }
>>
>> Any thoughts on that?
>>
>> Christian Stümpel
>>
>>
>>
>> ___
>> 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] SIGILL in finally clause without catch
Hi,
SIGILL means invalid instruction encountered by the cpu. Currently,
mono converts
this to an exception which can be caught and ignored. This behaviour
might change
in the future, cause we already handle SIGSEGV and SIGABRT by aborting the
process.
Zoltan
On Fri, Apr 25, 2008 at 1:51 PM, Christian Stümpel
<[EMAIL PROTECTED]> wrote:
> Hi Zoltan,
>
>
>
> > the (managed-to-native) wrapper. So the problem is usually in the native
> code.
> >
> >
> But then why does introducing the "catch" and rethrowing resolve the
> matter?
>
> platform is Mac OS X i386.
>
> Christian
>
>
> Am 25.04.2008 um 12:01 schrieb Zoltan Varga:
>
>
>
>
> > Hi,
> >
> > Mono throws that exception when it receives a SIGILL signal while
> > executing some
> > code. If it receives it while executing native code, it appears that
> > it is thrown by
> > the (managed-to-native) wrapper. So the problem is usually in the native
> code.
> >
> > What platform/os is this ?
> >
> > Zoltan
> >
> > 2008/4/23 Christian Stümpel <[EMAIL PROTECTED]>:
> >
> > > In code I have to port from MS .NET to mono I observed several SIGILL
> > > crashes at points in code, where calls to external code are made within
> a
> > > try block followed by a finally but *without* a catch statement.
> > >
> > >
> > > try {
> > > unrar.dosomething();
> > > throw new Exception("test");
> > > }
> > >
> > > // no catch here
> > >
> > > finally
> > > {
> > > unrar.close(); // calls unmanaged code
> > >
> > > }
> > >
> > > The unmanaged code called in unrar.dosomething() is C++ code compiled
> with
> > > exceptions enabled but it does not throw the exception, but the managed
> code
> > > that follows. The call to unrar.close() (which does not throw any
> exception)
> > > in the finally clause crashes with:
> > >
> > > System.ExecutionEngineException: SIGILL at (wrapper managed-to-native)
> > > NntpApp.nntp.rar.Unrar:RARCloseArchive (intptr) at
> > > NntpApp.nntp.rar.Unrar.Close () [0x0] at
> > > usenextapp.FilegroupPreview.ExtractFileFromRar (System.String path)
> > > [0x0]
> > >
> > > The SIGILL does not appear if I catch the exception and rethrow it in
> the
> > > finally clause
> > >
> > > Exception e=null;
> > >
> > > try {
> > > unmanaged1();
> > > throw new Exception("test");
> > > }
> > >
> > > catch(Exception ex)
> > > {
> > > e= ex;
> > > }
> > >
> > > finally
> > > {
> > > cleanup();
> > > if (e!=null)
> > > throw e;
> > > }
> > >
> > > Any thoughts on that?
> > >
> > > Christian Stümpel
> > >
> > >
> > >
> > > ___
> > > 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 SEGFAULT problem
Hi, This is now tracked as: https://bugzilla.novell.com/show_bug.cgi?id=383749 Zoltan 2008/4/25 Hubert FONGARNAND <[EMAIL PROTECTED]>: > > Hi, everibody > > Since about a week, my SMTP Server (which is in C#/mono) crashes about > 1 time /day... > It's a multithreaded program that work on an RHEL4 server with 3 > double-core processor and 16Gio RAM. > The segfaults appears randomly... and i cannot reproduce the bug on my devs > and beta machine. My program doesn't call any C library, so the crash seems > to be on mono itself > > I'm running mono 1.9.1 (it crashes too with mono 1.2.6) > > without gdb it crashes with: > > Stacktrace: > > > Native stacktrace: > > mono [0x8152f80] > mono [0x807819a] > /lib/tls/libpthread.so.0 [0x6b2890] > mono [0x813bc94] > mono [0x80bd5c1] > mono [0x80bdd0a] > mono [0x8102656] > mono [0x8116769] > /lib/tls/libpthread.so.0 [0x6ac371] > /lib/tls/libc.so.6(__clone+0x5e) [0x535ffe] > > Debug info from gdb: > > > > = > 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 > > I've run my program with Gdb [New Thread 66501552 (LWP 7705)] > [Thread 117857200 (LWP 7700) exited] > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 19356592 (LWP 4481)] > mono_debugger_thread_cleanup (jit_tls=0x85ba670) at debug-mini.c:802 > 802 if (info->jit_tls != jit_tls) > (gdb) bt > #0 mono_debugger_thread_cleanup (jit_tls=0x85ba670) at debug-mini.c:802 > #1 0x08148794 in mini_thread_cleanup (thread=0xb6f5ce70) at mini.c:9670 > #2 0x080c4860 in thread_cleanup (thread=0xb6f5ce70) at threads.c:509 > #3 0x080c4fc1 in start_wrapper (data=0xb66a7fa0) at threads.c:605 > #4 0x0810d09e in thread_start_routine (args=0xb78a4938) at threads.c:282 > #5 0x08121b19 in GC_start_routine (arg=0xb65aa9a0) at > pthread_support.c:1369 > #6 0x006ac371 in start_thread () from /lib/tls/libpthread.so.0 > #7 0x00535ffe in clone () from /lib/tls/libc.so.6 > (gdb) q > The program is running. Exit anyway? (y or n) y > [EMAIL PROTECTED] Server]# > > > > Could someone help me please > > It seems this is a GC issue > > > > > > > _ > > Ce message et les éventuels documents joints peuvent contenir des > informations confidentielles. > Au cas où il ne vous serait pas destiné, nous vous remercions de bien > vouloir le supprimer et en aviser immédiatement l'expéditeur. Toute > utilisation de ce message non conforme à sa destination, toute diffusion ou > publication, totale ou partielle et quel qu'en soit le moyen est > formellement interdite. > Les communications sur internet n'étant pas sécurisées, l'intégrité de ce > message n'est pas assurée et la société émettrice ne peut être tenue pour > responsable de son contenu. > ___ > 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-dev] [Patch] Mono.Security.StrongName.Verify: added a stream overload
Hi, I have added an overload to Mono.Security.StrongName.Verify which takes a Stream rather than a file name. This allows me to verify byte code I have already loaded in memory, saving an unnecessary write to disc. I have preserved the old interface and refactored the code so they both use the same path. I have attached the patch which contains the changes to StrongName.cs and StrongNameTest.cs Cheers, Dave StrongNameVerifyStream.patch Description: Binary data ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [Patch] Mono.Security.StrongName.Verify: added a stream overload
Hello Dave, It looks ok, except maybe for the ?line endings? on the last few lines of the diff. Do you have commit rights ? If so check the last part issue before committing. Otherwise tell me and I'll check that before committing. Thanks! Sebastien On Fri, 2008-04-25 at 14:27 +0100, Dave Hillier wrote: > Hi, > > I have added an overload to Mono.Security.StrongName.Verify which > takes a Stream rather than a file name. This allows me to verify byte > code I have already loaded in memory, saving an unnecessary write to > disc. I have preserved the old interface and refactored the code so > they both use the same path. > > I have attached the patch which contains the changes to StrongName.cs > and StrongNameTest.cs > > > Cheers, > > Dave > > > > ___ > 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] Mono.Security.StrongName.Verify: added a stream overload
Hi there, I've never asked for commit rights, so I presume I don't have them. For future reference, what's wrong with the line endings? If you can commit it for me that would be great. Thanks for your help, Dave On 25 Apr 2008, at 15:08, Sebastien Pouliot wrote: > Hello Dave, > > It looks ok, except maybe for the ?line endings? on the last few lines > of the diff. > > Do you have commit rights ? If so check the last part issue before > committing. Otherwise tell me and I'll check that before committing. > > Thanks! > Sebastien > > On Fri, 2008-04-25 at 14:27 +0100, Dave Hillier wrote: >> Hi, >> >> I have added an overload to Mono.Security.StrongName.Verify which >> takes a Stream rather than a file name. This allows me to verify byte >> code I have already loaded in memory, saving an unnecessary write to >> disc. I have preserved the old interface and refactored the code so >> they both use the same path. >> >> I have attached the patch which contains the changes to StrongName.cs >> and StrongNameTest.cs >> >> >> Cheers, >> >> Dave >> >> >> >> ___ >> 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] Mono.Security.StrongName.Verify: added a stream overload
Hey,
On Fri, 2008-04-25 at 15:08 +0100, Dave Hillier wrote:
> Hi there,
>
> I've never asked for commit rights, so I presume I don't have them.
right :)
> For future reference, what's wrong with the line endings?
- AssemblyHashAlgorithm algorithm =
AssemblyHashAlgorithm.SHA1;
- if (tokenAlgorithm == "MD5")
- algorithm = AssemblyHashAlgorithm.MD5;
- return Verify (rsa, algorithm, sn.Hash,
sn.Signature);
- }
- catch (CryptographicException) {
- // no exception allowed
- return false;
- }
+AssemblyHashAlgorithm algorithm =
AssemblyHashAlgorithm.SHA1;
+if (tokenAlgorithm == "MD5")
+algorithm = AssemblyHashAlgorithm.MD5;
+return Verify (rsa, algorithm, sn.Hash,
sn.Signature);
+}
+catch (CryptographicException) {
+// no exception allowed
+return false;
+}
+
Same code but it's part of the diff. So your editor either changed the
line endings (which could be non-consistent in the file) or it could be
a space-versus-tab issue too (since the alignment looks strange).
If the original file is bad (e.g. non-consistent line endings) then I'll
fix it in a separate commit (it makes reviewing SVN history easier).
> If you can commit it for me that would be great.
will do
> Thanks for your help,
you did the hard part (but it actually looks like it was easier than I
expected ;-)
Sebastien
> Dave
>
>
> On 25 Apr 2008, at 15:08, Sebastien Pouliot wrote:
>
> > Hello Dave,
> >
> > It looks ok, except maybe for the ?line endings? on the last few lines
> > of the diff.
> >
> > Do you have commit rights ? If so check the last part issue before
> > committing. Otherwise tell me and I'll check that before committing.
> >
> > Thanks!
> > Sebastien
> >
> > On Fri, 2008-04-25 at 14:27 +0100, Dave Hillier wrote:
> >> Hi,
> >>
> >> I have added an overload to Mono.Security.StrongName.Verify which
> >> takes a Stream rather than a file name. This allows me to verify byte
> >> code I have already loaded in memory, saving an unnecessary write to
> >> disc. I have preserved the old interface and refactored the code so
> >> they both use the same path.
> >>
> >> I have attached the patch which contains the changes to StrongName.cs
> >> and StrongNameTest.cs
> >>
> >>
> >> Cheers,
> >>
> >> Dave
> >>
> >>
> >>
> >> ___
> >> 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] Mono.Security.StrongName.Verify: added a stream overload
Hi Dave, Am 25.04.2008 um 16:08 schrieb Dave Hillier: > For future reference, what's wrong with the line endings? I don't spot any line ending issues either on first sight, however you appear to replace some tabs with 8 spaces in StrongName.cs. Andreas > On 25 Apr 2008, at 15:08, Sebastien Pouliot wrote: > >> Hello Dave, >> >> It looks ok, except maybe for the ?line endings? on the last few >> lines >> of the diff. >> >> Do you have commit rights ? If so check the last part issue before >> committing. Otherwise tell me and I'll check that before committing. >> >> Thanks! >> Sebastien >> >> On Fri, 2008-04-25 at 14:27 +0100, Dave Hillier wrote: >>> Hi, >>> >>> I have added an overload to Mono.Security.StrongName.Verify which >>> takes a Stream rather than a file name. This allows me to verify >>> byte >>> code I have already loaded in memory, saving an unnecessary write to >>> disc. I have preserved the old interface and refactored the code so >>> they both use the same path. >>> >>> I have attached the patch which contains the changes to >>> StrongName.cs >>> and StrongNameTest.cs >>> >>> >>> Cheers, >>> >>> Dave >>> >>> >>> >>> ___ >>> 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] [PATCH] Add mixed-mode assembly support on Windows (now build with cygwin as well)
Hi, Some comments to the patch: - appdomain.h: This is a public header file, so the new functions should go somewhere else, like domain-internals.h - domain.c: The code here could be put into a function in corree.c. - corree.h: Please include , since that contains the definition of PLATFORM_WIN32. - Put mono_module_handle and coree_handle into some header file like coree.h, and there definitons into corree.c for example. - image.c: mono_cli_rva_image_map is part of our public api, so its signature cannot be changed, you can rename it to mono_cli_rva_image_map_internal, and change the signature of that. - The usage of 'raw_data' is a bit confusing: sometimes it is used as an address (like in mono_cli_rva_image_map), sometimes it is used as a handle (everywhere else). Which is correct ? - cil-coff.h: Please don't declare constants in the middle of a a structure definition. - gc.c: The comment about mono_thread_attach () might be incorrect, but the thread_started_event stuff is definitely needed to avoid races when the runtime is shut down before the finalizer thread can start. So I don't think we can remove this. Zoltan 2008/4/25 Kornél Pál <[EMAIL PROTECTED]>: > Hi, > > Previously I forgot to try _CorDllMain to load the runtime when it hasn't > been loaded yet. As a result I found that thread_started_event in > mono/mono/metadata/gc.c causes a deadlock in this situation because > _CorDllMain is callled while the OS loader lock is held by the current > thread and no new threads are started while OS loader lock is held. After > examining the purpose of thread_started_event I found that unlike the > comment states it is not required at all so I removed it completely. This > will make startup faster as well. I also checked that finalizer_thread is > called and reaches SetEvent (shutdown_event) at the end. > > My test confirmed that Mono even supports mixed-mode assemblies with > exported symbols if they were native DLLs just like MS.NET does. > > > Kornél > > - Original Message - From: Kornél Pál > To: mono-devel > Sent: Friday, April 25, 2008 12:31 AM > > > Subject: Re: [Mono-dev] [PATCH] Add mixed-mode assembly support on Windows > (now build with cygwin as well) > > > > > Hi, > > > > I also modified Makefile to export __stdcall functions without mangling > and > > create-windef.pl to include MonoFixupCorEE. Other than these there are no > > modifications. > > > > Kornél > > > > - Original Message - From: Kornél Pál > > To: mono-devel; Robert Jordan > > Sent: Wednesday, April 23, 2008 2:40 PM > > Subject: Re: [Mono-dev] [PATCH] Add mixed-mode assembly support on Windows > > (now build with cygwin as well) > > > > > > > > > > > > > From: Robert Jordan > > > > I think the following code is from another patch set (the cmd line > > > > encoding issue you sent a patch for). Is it complete? > > > > Index: mono/mono/mini/main.c > > > > > > > > > > Yes, it is. I included it in this patch to be consistent with > _CorExeMain > > > implementation. Also note that command line arguments are parsed as > UTF-8 > > > without MONO_EXTERNAL_ENCODINGS. MONO_EXTERNAL_ENCODINGS should not be > > > supported on Windows, Unicode API should be used instead. Patching main > > > will > > > make Mono support non-ASCII command line arguments on Windows. Also note > > > that because images are loaded using LoadLibrary file names are expected > > > to > > > be in UTF-8 that is supported by this main function patch. I still > would > > > vote for removing MONO_EXTERNAL_ENCODINGS support on Windows but that is > > > out > > > of the scope of this patch. > > > > > > > > > > If this is solved, I will try to fix the cygwin build. > > > > > > > > > > I managed to fix the build. #include had to be moved out of > > > #ifdef PLATFORM_WIN32 because PLATFORM_WIN32 is defined in config.h in > the > > > cygwin build. > > > > > > Please review the patch. Please try it on Linux as well to make sure > that > > > it > > > doesn't break Linux. And if you like it, please approve the patch. > > > > > > Kornél > > > > > > > > > > > > ___ > 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.Messaging, a (just) working implementation
Hello, (You might want to read it from bottom to top :p) Michael Barker wrote: > > - You cannot add any public extra stuff (such as Mono.Messaging.* > classes) > in System.Messaging.dll. You have to create another assembly (such as > Mono.Messaging.dll) and use it together with System.Messaging.dll. > > > That's interesting, I looked at System.Data initially, which included > Mainsoft namespace classes, so I thought adding a different namespace > into the same namespace would be okay. I am happy to change that. That's simple: we can add extra namespaces. We cannot add public types in an extra namespace. > > It is sort of mess, as either > > - System.Messaging.dll depends on your extra assembly and hence yours > cannot use any types in System.Messaging.dll (e.g. you cannot define > IQueue.Deliver), or > > > This is probably the easiest, but is adding a compile time dependency > for System.Messaging.dll on another assembly acceptable? I assume we > shouldn't be adding additional public classes to the System.* namespaces. Adding a compile-time dependency for Sys.Messaging.dll is acceptable (we already do that, such as Mono.Security.dll for System.dll and System.Security.dll). Note that assemblies, namespaces and types are all different here. It may look the easiest before you write code, but other choices may be still easier in reality. You should feel free to switch between those ideas at anytime :) > - your extra assembly depends on System.Messaging.dll and hence any > types in yours inside System.Messaging.dll must be used through some > reflection foo, or > - you have to run cyclic build between those two assemblies (we do it > for System.dll, System.Configuration.dll and System.Xml.dll, > which is > a mess). > > - At least MessageQueue.Create() should be implemented (otherwise > it is not > practically functional as System.Messaging.dll). It would have to > be done > by some configuration support to indicate one IMessagingProvider, > and it > must not be dependent on System.Configuration.dll which is 2.0-only. > > - It would provide only simple part of Sys.Messaging functionality > (it would > apply to any JMS/AMQP based solution). We could still go with your > bridge implementation for a while as a compromised solution though. > > > That's true, however the AMQP spec is not yet finished. I believe > that there will be browsing and selector support in some of the later > revisions. This will mean that the majority of the System.Messaging > functionality is covered (including MessageQueue.Peek and > MessageQueue.ReceiveById). The parts that probably won't be covered > would be some of the specifics around the additional system queues > (e.g. journal queues). Although AMQP does support sophisticated > routing rules so it may be possible to emulate some of those features. Oh, that's great news to me :) I was indeed wondering how Peek() could be supported by those JMS-based messaging systems (even with AMQP, as most of AMQP services are implemented in Java). I also guess that some of those special queues can be implemented by some supporting queues or databases. > I was hoping by adding a provider layer, other implementations could > be added later, e.g. OpenWire for ActiveMQ or something Mono specific. > > > > > And as Miguel pointed out, we would have to avoid your GPLv3-based > component > as run-time dependency. > > > I didn't see Miguel's message, but that is my mistake, it shouldn't of > been v3. Is LGPL okay or would MIT be easiest for Mono? > LGPLv2 is at least still valid, but MIT/X11 is the least problematic. To summarize the situation, there are three assemblies that play certain roles: - System.Messaging.dll - Mono.Messaging.dll or whatever, that contains IMessagingProvider and so on. - The actual implementation of IMessagingProvider. No functionality in System.Messaging would work without the last item, and when it is loaded by the runtime, it should not conflict with LGPL2-licensed runtime. Actually we cannot distribute your IMessagingProvider implementation (the one hosted at code.google.com) inside our mono source tarball because it contains pre-compiled dependency libraries and hence does not match current build design of mono/mcs tree. It is sort of mess and basically I would like to avoid this implementation strategy. When we provide working System.Messaging functionality we will have to provide another package and source tarball just for this bridge implementation. Unlike NMS in ActiveMQ or AMQP implementation in RabbitMQ, this Qpid stuff is too rich and has a lot of external dependencies, which do not look suitable here. > I have some comments on the patch details, but I'd put my general > survey first :) > > Atsushi Eno > > > Unfortunately my timing here is not the
Re: [Mono-dev] Compiling Mono on SPARC
Any thoughts on what's going on? - Steve -- Steve G. Bjorg http://wiki.mindtouch.com http://wiki.opengarden.org On Apr 18, 2008, at 12:11 PM, PCM Reddy wrote: > Andreas Färber wrote: >> >> Am 18.04.2008 um 20:53 schrieb PCM Reddy: >> >>> I am using gtar. also renamed the original solaris "mcs" command >>> too. >>> Now I downloaded latest mono-1.9 and tried to compile. >>> >>> Compilation failed at "mcs" and When I ran gmake from mcs folder >>> this >>> is what I got. >>> >>> mkdir -p -- ../class/lib/default/ >>> touch ../class/lib/default//.stamp >>> MONO_PATH="../class/lib/net_1_1_bootstrap:$MONO_PATH" >>> /tmp/mono-1.9/runtime/mono-wrapper >>> ../class/lib/net_1_1_bootstrap/mcs.exe /codepage:65001 -d:NET_1_1 >>> -d:ONLY_1_1 -debug -target:exe -out:mcs.exe cs-parser.cs >>> @mcs.exe.sources >>> Segmentation Fault - core dumped >>> gmake[2]: *** [../class/lib/default/mcs.exe] Error 139 >>> gmake[2]: Leaving directory `/tmp/mono-1.9/mcs/mcs' >>> gmake[1]: *** [do-all] Error 2 >> >> Looks bad ... does `mono/mini/mono -V` work? > [EMAIL PROTECTED] # ./mono/mini/mono -V > Mono JIT compiler version 1.9 (tarball) > Copyright (C) 2002-2007 Novell, Inc and Contributors. www.mono-project.com >TLS: normal >GC:Included Boehm (with typed GC) >SIGSEGV: normal >Notification: Thread + polling >Architecture: sparc >Disabled: none > >> >> Andreas > > ___ > 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 Mono on SPARC
Thanks for the follow up. Finally with latest 1.9 sources I am able to compile it on Solaris 10 SPARC. By the way latest Dekiwiki is also running now. Thanks, -PCM Steve Bjorg wrote: > Any thoughts on what's going on? > > - Steve > > -- > Steve G. Bjorg > http://wiki.mindtouch.com > http://wiki.opengarden.org > > > On Apr 18, 2008, at 12:11 PM, PCM Reddy wrote: > >> Andreas Färber wrote: >>> >>> Am 18.04.2008 um 20:53 schrieb PCM Reddy: >>> I am using gtar. also renamed the original solaris "mcs" command too. Now I downloaded latest mono-1.9 and tried to compile. Compilation failed at "mcs" and When I ran gmake from mcs folder this is what I got. mkdir -p -- ../class/lib/default/ touch ../class/lib/default//.stamp MONO_PATH="../class/lib/net_1_1_bootstrap:$MONO_PATH" /tmp/mono-1.9/runtime/mono-wrapper ../class/lib/net_1_1_bootstrap/mcs.exe /codepage:65001 -d:NET_1_1 -d:ONLY_1_1 -debug -target:exe -out:mcs.exe cs-parser.cs @mcs.exe.sources Segmentation Fault - core dumped gmake[2]: *** [../class/lib/default/mcs.exe] Error 139 gmake[2]: Leaving directory `/tmp/mono-1.9/mcs/mcs' gmake[1]: *** [do-all] Error 2 >>> >>> Looks bad ... does `mono/mini/mono -V` work? >> [EMAIL PROTECTED] # ./mono/mini/mono -V >> Mono JIT compiler version 1.9 (tarball) >> Copyright (C) 2002-2007 Novell, Inc and Contributors. >> www.mono-project.com >>TLS: normal >>GC:Included Boehm (with typed GC) >>SIGSEGV: normal >>Notification: Thread + polling >>Architecture: sparc >>Disabled: none >> >>> >>> Andreas >> >> ___ >> 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 Mono on SPARC
Am 25.04.2008 um 19:15 schrieb Steve Bjorg: > Any thoughts on what's going on? Not really. Obviously mono segfaults, but not for the version info. So I'd suspect either the GC or the JIT. * Have you tried compiling without GC (--with-gc=none) or with a more recent, external Boehm GC? * Since mono itself is there, you could try compiling without mcs (-- disable-mcs-build) and copy the assemblies over from another machine. Then you can try running a Hello World and (more easily) look at it with gdb if necessary (or run the test suite). * In December, Zoltan mentioned the 64-bit ABI were not supported. Maybe you need to use CC="gcc -m32" or similar flags. * I remember someone contributing sparc JIT fixes sometime last year - search the list archives and check (i.e., revert) those latest patches. Most likely that contributor will have run Solaris, so you may want to inquire whether they have any issues now. Andreas > - Steve > > -- > Steve G. Bjorg > http://wiki.mindtouch.com > http://wiki.opengarden.org > > > On Apr 18, 2008, at 12:11 PM, PCM Reddy wrote: > >> Andreas Färber wrote: >>> >>> Am 18.04.2008 um 20:53 schrieb PCM Reddy: >>> I am using gtar. also renamed the original solaris "mcs" command too. Now I downloaded latest mono-1.9 and tried to compile. Compilation failed at "mcs" and When I ran gmake from mcs folder this is what I got. mkdir -p -- ../class/lib/default/ touch ../class/lib/default//.stamp MONO_PATH="../class/lib/net_1_1_bootstrap:$MONO_PATH" /tmp/mono-1.9/runtime/mono-wrapper ../class/lib/net_1_1_bootstrap/mcs.exe /codepage:65001 -d:NET_1_1 -d:ONLY_1_1 -debug -target:exe -out:mcs.exe cs-parser.cs @mcs.exe.sources Segmentation Fault - core dumped gmake[2]: *** [../class/lib/default/mcs.exe] Error 139 gmake[2]: Leaving directory `/tmp/mono-1.9/mcs/mcs' gmake[1]: *** [do-all] Error 2 >>> >>> Looks bad ... does `mono/mini/mono -V` work? >> [EMAIL PROTECTED] # ./mono/mini/mono -V >> Mono JIT compiler version 1.9 (tarball) >> Copyright (C) 2002-2007 Novell, Inc and Contributors. www.mono-project.com >> TLS: normal >> GC:Included Boehm (with typed GC) >> SIGSEGV: normal >> Notification: Thread + polling >> Architecture: sparc >> Disabled: none >> >>> >>> Andreas >> >> ___ >> 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] Compiling Mono on SPARC
Am 25.04.2008 um 20:13 schrieb PCM Reddy: > Thanks for the follow up. Finally with latest 1.9 sources I am able to > compile it on Solaris 10 SPARC. Great. If you needed anything in particular to make it work (flags, vars etc.), please let us know so that it can be documented in Mono's Wiki. Have fun, Andreas ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] UI Developer Needed
Hello All, First of all I apologize to those of you who may view this as spam. I work for ANSYS Inc. and we have full time positions available that may be of interest to some of you in this group. The particular position that I list below works closely with my group and we are hoping to fill it as soon as possible. If interested you can apply directly at our website. http://careers.vurvexpress.com/jobprofile.cfm?szWID=10336&szCID=46514&szSiteID=1467&szOrderID=494232&szStart=1 If that link does not work properly you can access it and others through http://www.ansys.com/corporate/careers.asp It is listed under North America and the Job ID is 1653 Although the job is listed a Canonsbrug there may be an opportunity to work at some of our other sites. Feel free to send me any questions. Thanks -bill Senior Software Developer Job Description Summary The Senior Software Developer will work on the UI framework for the Next Generation Platform. The primary technologies the candidate would be working with are C#, C++, Qt, Windows Forms, targeting Windows and Linux. Primary responsibilities would include defining and implementing the core subsystems and architecture in a new, cross-platform application framework. The ideal candidate would have significant experience with an established GUI toolkit such as Qt, Java Swing, Windows Forms, etc., and experience in the design of large object oriented interactive software systems. Minimum Requirements: BS in Computer Science / Software Engineering or the equivalent Significant experience in object oriented design, and implementation in C++ / C# The ability to work with a geographically distributed team Excellent written and verbal communication skills The ability to mentor less experienced developers ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Compiling Mono on SPARC
Andreas Färber wrote: > Am 25.04.2008 um 20:13 schrieb PCM Reddy: > > >> Thanks for the follow up. Finally with latest 1.9 sources I am able to >> compile it on Solaris 10 SPARC. >> > > Great. If you needed anything in particular to make it work (flags, > vars etc.), please let us know so that it can be documented in Mono's > Wiki. > Couple of points to be documented. I observed lot of warnings during compilation. It may be good idea to add appropriate compiler flags. * User must use "gtar" instead of "tar" * User must remove "mcs" command from path this conflicts during compilation. * init scripts created are not suited for solaris users need to edit them. ex: there is no start-stop-service command in solaris. Thanks, -PCM > Have fun, > > Andreas > > ___ > 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] Add mixed-mode assembly support on Windows (now build with cygwin as well)
Hi, Thank you very much for the review and your comments. > From: Zoltan Varga > To: Kornél Pál > Cc: mono-devel > Sent: Friday, April 25, 2008 4:45 PM > Subject: Re: [Mono-dev] [PATCH] Add mixed-mode assembly support on Windows > (now build with cygwin as well) > - appdomain.h: This is a public header file, so the new functions > should go somewhere > else, like domain-internals.h > - domain.c: The code here could be put into a function in corree.c. > - Put mono_module_handle and coree_handle into some header file like > coree.h, and > there definitons into corree.c for example. > - corree.h: Please include , since that contains the > definition of PLATFORM_WIN32. OK. > - image.c: mono_cli_rva_image_map is part of our public api, so its > signature > cannot be changed, you can rename it to mono_cli_rva_image_map_internal, > and > change the signature of that. I had a look at "C:\Program Files\Mono\include" and it doesn't contain any declaration. Is this public for sure? If it is I'll do what you suggested. > - The usage of 'raw_data' is a bit confusing: sometimes it is used as an > address > (like in mono_cli_rva_image_map), sometimes it is used as a handle > (everywhere > else). Which is correct ? HMODULE is the actual pointer to the base address (position of the DOS header) of the module. Also note that there is no such thing as HINSTANCE it is a heritage of the Win16 shared address space and HMODULE and HINSTANCE are the same in Win32. In Win32s (Win32 API on Win16 that is not really Win32 compatible) HMODULE is definitely not the base address but someting else that may be a handle. So raw_data is actually the raw_data but unlike the current implementation sections are mapped to the actual virtual addresses. Even checks in map functions could be omitted but I didn't remove them to ensure that the image is correct. > - cil-coff.h: Please don't declare constants in the middle of a a > structure definition. OK. I actually tried to follow what seemed to me being the coding convention of that file. > - gc.c: The comment about mono_thread_attach () might be incorrect, but > the > thread_started_event stuff is definitely needed to avoid races when > the runtime is > shut down before the finalizer thread can start. So I don't think we > can remove this. As I see there can be no race because there only are "mono_thread_current () == gc_thread" checks. Even if "mono_thread_current ()" returns NULL (that is unlikely I think) nothing will happen on the thread if the finalizer thread in not initialized yet. Actual work is only done by "finalizer_thread" that is being executed only in the finalizer thread. If for some reason "mono_gc_cleanup ()" is called before the finalizer thread is initialized "WaitForSingleObjectEx" will wait for two seconds for the finalizers and thus for the finalizer thread being initialized. If it fails to initialize within two seconds finalizers won't run of course but the same is true for finalizers that werent processed in two seconds so I see no big difference. If really need "WaitForSingleObjectEx (thread_started_event, INFINITE, FALSE);" can be moved just before "WaitForSingleObjectEx (shutdown_event, 2000, FALSE)" but I don't see any reason to do so. If I'm wrong please let me know. Kornél ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] System.Messaging, a (just) working implementation
> > > I was hoping by adding a provider layer, other implementations could be >> added later, e.g. OpenWire for ActiveMQ or something Mono specific. >> >> >> >>And as Miguel pointed out, we would have to avoid your GPLv3-based >>component >>as run-time dependency. >> >> I didn't see Miguel's message, but that is my mistake, it shouldn't of >> been v3. Is LGPL okay or would MIT be easiest for Mono? >> >> LGPLv2 is at least still valid, but MIT/X11 is the least problematic. > > To summarize the situation, there are three assemblies that play certain > roles: > > - System.Messaging.dll > - Mono.Messaging.dll or whatever, that contains IMessagingProvider and so > on. > - The actual implementation of IMessagingProvider. > > No functionality in System.Messaging would work without the last item, and > when > it is loaded by the runtime, it should not conflict with LGPL2-licensed > runtime. > > Actually we cannot distribute your IMessagingProvider implementation (the > one > hosted at code.google.com) inside our mono source tarball because it > contains > pre-compiled dependency libraries and hence does not match current build > design > of mono/mcs tree. > > It is sort of mess and basically I would like to avoid this implementation > strategy. When we provide working System.Messaging functionality we will > have > to provide another package and source tarball just for this bridge > implementation. > > Unlike NMS in ActiveMQ or AMQP implementation in RabbitMQ, this Qpid stuff > is > too rich and has a lot of external dependencies, which do not look suitable > here. Yes, the QPid client libraries are very dependency heavy (around 8 dlls). I was keen to get something working as quickly as possible and it was CLR based AMQP client library I could find. I am reasonably familiar with AMQP protocol format so a producing a clean client implementation to include in the mono distribution (as a final solution) won't be too difficult. However, I think getting the System.Messaging and Mono.Messaging (or whatever name is appropriate) assemblies in place first is probably best, so I would probably use the QPid libraries as a means to have a working implementation as early as possible. My next step, likely in September, would be to separate Mono.Messaging into a separate assembly and remove references to the System.Messaging namespace. Once that works, build a AMQP client library that does drag in so many dependencies. > > > I have some comments on the patch details, but I'd put my general >>survey first :) >> >>Atsushi Eno >> >> Unfortunately my timing here is not the best. I am about to head off >> travelling for about 4 months, so I won't be able to make any major changes >> until September. I'll fix the license and add MessageQueue.Create support >> before I go. I still want to help build a System.Messaging implemenation so >> I would be happy to receive any feedback you have in order to build >> something that will be useful for Mono. System.Messaging hasn't been >> touched a few years, so a few more months shouldn't hurt :-). >> >> Oh. Okay. Though it has not been touched for years, I once tried to > implement some basic functionality using OpenWire.net, and there was an > attempt to implement it using AMQ as Summer of Code project. A few more > months wouldn't hurt but someone may start it instead of you ;-) I'm okay with that. If someone makes better progress in the meantime, I would be happy to contribute to their efforts. > > > Atsushi Eno > > Regards, Michael Barker. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] mono_method_get_unmanaged_thunk
The Embedding Mono page mentions possible future work on mono_method_get_unmanaged_thunk. We are using the embedding (reflection) API quite happily, writing our own marshaling for basic types (strings, arrays, enums, etc.) but would like to avoid the overhead of going through the generic invoke. When our wrappers initialize, it would be nice to simply JIT all the necessary methods and then call them directly via a C function pointer, as I think was imagined before. Exceptions are interesting; it would be quite acceptable to generate a thunk which took a MonoObject** to return the results of any exception. (On our wrappers we marshal the message and re-throw it as a C++ runtime_exception but I suspect this isn't what everyone would want to do.) Is this a feature on the radar for anyone soon? Many thanks, and looking forward to Mono 2.0! - Sebastian ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] System.Messaging, a (just) working implementation
I've updated the code on googlecode to support MessageQueue.CreateQueue and changed the license to LGPL 2.1. Regards, Michael Barker. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] Add mixed-mode assembly support on Windows (now build with cygwin as well)
Hi,
Attached the updated patch.
I realized that mono_marshal_get_vtfixup_ftnptr was broken and I
reimplemented it without using mono_marshal_get_managed_wrapper.
I also have done some modifications to gc.c.
There is a comment in the patch /* FIXME: do we need this? (image is
disposed anyway) */ about some code I think should be removed because it's
unneeded. Is that code required?
Kornél
Thank you very much for the review and your comments.
From: Zoltan Varga
To: Kornél Pál
Cc: mono-devel
Sent: Friday, April 25, 2008 4:45 PM
Subject: Re: [Mono-dev] [PATCH] Add mixed-mode assembly support on
Windows (now build with cygwin as well)
- appdomain.h: This is a public header file, so the new functions
should go somewhere
else, like domain-internals.h
- domain.c: The code here could be put into a function in corree.c.
- Put mono_module_handle and coree_handle into some header file like
coree.h, and
there definitons into corree.c for example.
- corree.h: Please include , since that contains the
definition of PLATFORM_WIN32.
OK.
- image.c: mono_cli_rva_image_map is part of our public api, so its
signature
cannot be changed, you can rename it to
mono_cli_rva_image_map_internal, and
change the signature of that.
I had a look at "C:\Program Files\Mono\include" and it doesn't contain any
declaration. Is this public for sure? If it is I'll do what you suggested.
- The usage of 'raw_data' is a bit confusing: sometimes it is used as an
address
(like in mono_cli_rva_image_map), sometimes it is used as a handle
(everywhere
else). Which is correct ?
HMODULE is the actual pointer to the base address (position of the DOS
header) of the module. Also note that there is no such thing as HINSTANCE
it is a heritage of the Win16 shared address space and HMODULE and
HINSTANCE are the same in Win32. In Win32s (Win32 API on Win16 that is not
really Win32 compatible) HMODULE is definitely not the base address but
someting else that may be a handle. So raw_data is actually the raw_data
but unlike the current implementation sections are mapped to the actual
virtual addresses. Even checks in map functions could be omitted but I
didn't remove them to ensure that the image is correct.
- cil-coff.h: Please don't declare constants in the middle of a a
structure definition.
OK. I actually tried to follow what seemed to me being the coding
convention of that file.
- gc.c: The comment about mono_thread_attach () might be incorrect, but
the
thread_started_event stuff is definitely needed to avoid races when
the runtime is
shut down before the finalizer thread can start. So I don't think we
can remove this.
As I see there can be no race because there only are "mono_thread_current
() == gc_thread" checks. Even if "mono_thread_current ()" returns NULL
(that is unlikely I think) nothing will happen on the thread if the
finalizer thread in not initialized yet. Actual work is only done by
"finalizer_thread" that is being executed only in the finalizer thread. If
for some reason "mono_gc_cleanup ()" is called before the finalizer thread
is initialized "WaitForSingleObjectEx" will wait for two seconds for the
finalizers and thus for the finalizer thread being initialized. If it
fails to initialize within two seconds finalizers won't run of course but
the same is true for finalizers that werent processed in two seconds so I
see no big difference. If really need "WaitForSingleObjectEx
(thread_started_event, INFINITE, FALSE);" can be moved just before
"WaitForSingleObjectEx (shutdown_event, 2000, FALSE)" but I don't see any
reason to do so. If I'm wrong please let me know.
Kornél
Index: mono/libgc/win32_threads.c
===
--- mono/libgc/win32_threads.c (revision 101236)
+++ mono/libgc/win32_threads.c (working copy)
@@ -782,7 +782,7 @@
* Pontus Rydin suggests wrapping the thread start routine instead.
*/
#if defined(GC_DLL) || defined(GC_INSIDE_DLL)
-BOOL WINAPI DllMain(HINSTANCE inst, ULONG reason, LPVOID reserved)
+BOOL WINAPI GC_DllMain(HINSTANCE inst, ULONG reason, LPVOID reserved)
{
switch (reason) {
case DLL_PROCESS_ATTACH:
Index: mono/libgc/include/gc.h
===
--- mono/libgc/include/gc.h (revision 101236)
+++ mono/libgc/include/gc.h (working copy)
@@ -922,6 +922,8 @@
#if defined(GC_WIN32_THREADS) && !defined(__CYGWIN32__) && !defined(__CYGWIN__)
# include
+ BOOL WINAPI GC_DllMain(HINSTANCE inst, ULONG reason, LPVOID reserved);
+
/*
* All threads must be created using GC_CreateThread, so that they will be
* recorded in the thread table. For backwards compatibility, this is not
Index: mono/mono/metadata/loader.c
===
--- mono/mono/metadata/loader.c (revision 101236)
+++ mono/mono/metadata/loader.c (working copy)
@@ -1394,12 +1394,20 @@
i
Re: [Mono-dev] System.Messaging, a (just) working implementation
[Resending, email server not working again ] On Thu, 2008-04-24 at 18:37 -0400, Miguel de Icaza wrote: > Hello Michael, > > > As I mentioned a couple of days ago I have a 0.0.1 version of a bridge > > between Mono and QPid. I have placed the code and a patch that adds an > > SPI to Mono on google code. http://code.google.com/p/mono-qpid/ > > > > There is quite a bit missing from the implementation, but basic sending > > and receiving with XML and Binary formatting works. > > This looks interesting; For us to be able to merge that code into our > repository, we would need the code to be licensed under the same license > that our class libraries use (MIT X11). ___ 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 + SWIG string return values leads to bad free
[resending, email server not working] On Thu, 2008-04-24 at 18:33 -0400, Miguel de Icaza wrote: > Hello, > > > The returned string is passed back to the SWIG C# class and used > > (successfully) and then later the GC tries to collect it and fails. > > The C# delegate is just something like > > The GC does not collect strings returned from P/Invoke, but it will free > return values. > > If you are returning strings that are now malloc()ed (and ownership is > transferred to the caller), you may want to change the P/Invoke > signature to return an IntPtr, and then use Marshal.PtrToStringAuto > ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Where is the mono_string_chars macro?
I'm doing a bit of research. I have searched and grepped, but have not been able to find the mono_string_chars() macro? Where is it? Thanks in advance, Phil ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Compiling Mono on SPARC
> Couple of points to be documented. > I observed lot of warnings during compilation. It may be good idea to > add appropriate compiler flags. > * User must use "gtar" instead of "tar" I have added a check now to configure, it should catch future problems like this. > * User must remove "mcs" command from path this conflicts during > compilation. What kind of errors do you get, and when do you get them? I would like to catch this error as well. > * init scripts created are not suited for solaris users need to edit them. > ex: there is no start-stop-service command in solaris. Which ones are these init scripts, and can you provide equivalents? ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
