In doing some testing it looks like TCP_CORK is not being set by
default on ubuntu when dealing with async APIs for TCP.
I realized this by not seeing a perf difference when sending 20 byte
packets when setting NODELAY.
1) Is this by design for some reason?
2) Can this be bypassed? I didn't see
We have some code we are running in various environments.
It is stable for memory usage in MS CLR
It seems to be leaking in boehm (pretty quickly)
It is stable for memory usage in sgen
My first thought was to start taking memory dumps to see whats going
on but maybe someone knows some kinds of
We are getting core dumps trying to run sgen on openbsd, I am not sure
who the right people might be to get the core dumps to or if they were
expecting it to work at all. Please advise.
--
Le doute n'est pas une condition agréable, mais la certitude est absurde.
:
sgen the garbage collector: http://mono-project.com/Working_With_SGen
I'm new to this stuff and the naming collision is confusing to me.
-Rob
On Tue, Jun 26, 2012 at 3:10 PM, Greg Young gregoryyou...@gmail.com wrote:
We are getting core dumps trying to run sgen on openbsd, I am not sure
who
Update http://forums.freebsd.org/showthread.php?t=32516
On Wednesday, June 27, 2012, Greg Young wrote:
the garbage collector. code works fine with boehm and with sgen on
other platforms. We installed from package, I will try building from
source on it.
On Tue, Jun 26, 2012 at 3:27 PM, Rob
We are experiencing an issue with async behaviours in sockets (with
SendAsync/callback not Begin/End).
Our visible issue is that when in a send loop we will fail on our
heartbeats. After debugging and counting calls into/out of
SendAsync/callback we see that we are inside of a call to SendAsync
kump...@gmail.com wrote:
We've been aware of such issues, could you file a bug and attach a test case
with it please?
This would really really help us fix it.
On Wed, Jun 27, 2012 at 4:08 AM, Greg Young gregoryyou...@gmail.com wrote:
We are experiencing an issue with async behaviours
Chatted with the guys and issues persist on trunk. I will try to get a test
app
On Thursday, June 28, 2012, Gonzalo Paniagua Javier wrote:
On Wed, Jun 27, 2012 at 9:23 AM, Greg Young
gregoryyou...@gmail.comjavascript:;
wrote:
Trying to get it into a testcase has been very difficult
?
This would really really help us fix it.
On Wed, Jun 27, 2012 at 4:08 AM, Greg Young gregoryyoung1 at gmail.com
wrote:
We are experiencing an issue with async behaviours in sockets (with
SendAsync/callback not Begin/End).
Our visible issue is that when in a send loop we will fail on our
Btw to avoid confusion and duplicated work if someone starts could we just
sync a bit in this thread?
On Tuesday, July 17, 2012, Greg Young wrote:
Hey all.
As this is a big issue for us and I feel a huge problem for mono in
general at this point as it means sockets basically dont work which
We have had some moving forward in our mono stability issues. I
figured I would start up a chat here about one place that seems to be
causing many problems.
https://github.com/mono/mono/blob/master/mcs/class/corlib/System.Collections.Concurrent/ObjectPool.cs
I am not really sure the code here
Yuriy will reply with more details but by just making Take return
Creator() and nooping release many of our issues have gone away
(including visible issues with concurrentstack). From what I have seen
we also saw massive performance gains.
On Wed, Jul 25, 2012 at 6:54 AM, Greg Young gregoryyou
Yes we are using sgen.
Good to know the history there as well.
Cheers,
Greg
On Wed, Jul 25, 2012 at 7:22 AM, Konrad Kruczyński
konrad.kruczyn...@gmail.com wrote:
On Wed, 2012-07-25 at 07:17 -0400, Greg Young wrote:
Yuriy will reply with more details but by just making Take return
Creator
Does anyone already have/know of a socket lib on top of EV for eventing?
Cheers,
Greg
--
Le doute n'est pas une condition agréable, mais la certitude est absurde.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
Laval
http://neteril.org
2012/7/25 Greg Young gregoryyou...@gmail.com
Does anyone already have/know of a socket lib on top of EV for eventing?
Cheers,
Greg
--
Le doute n'est pas une condition agréable, mais la certitude est absurde
action jackson to the rescue as always!
If anyone is looking for similar check out
https://github.com/kersny/libuv-csharp from google summer of code
student last year
On Wed, Jul 25, 2012 at 8:01 AM, Greg Young gregoryyou...@gmail.com wrote:
Yeah I figured someone might have already built one
Thanks!
On Wed, Jul 25, 2012 at 8:19 AM, Alfred Hall ah...@ahall.org wrote:
I think https://github.com/txdv/LibuvSharp is more up to date, Bentkus seems
to be working on this actively..
On 25 Jul 2012, at 12:17, Greg Young wrote:
action jackson to the rescue as always!
If anyone
We have some data we will be caching. It is fixed size.
I was wondering which will be better. Storing in in unmanaged memory
or dropping things in the LOH and letting the GC deal with them? On
the MS CLR LOH seems to be the better option.
Thoughts?
Greg
--
Le doute n'est pas une condition
, Jul 22, 2012 at 7:20 AM, Gonzalo Paniagua Javier
gonzalo.m...@gmail.com wrote:
On Tue, Jul 17, 2012 at 7:49 AM, Greg Young gregoryyou...@gmail.com wrote:
Hey all.
As this is a big issue for us and I feel a huge problem for mono in general
at this point as it means sockets basically dont work
wrote:
On Thu, Aug 9, 2012 at 1:47 PM, Greg Young gregoryyou...@gmail.com wrote:
An update to this. Some of the failures have been taken away (also
with our patch mentioned). However simple test apps using sockets (or
it appears any callbacks) in mono are not stable.
This I would imagine
parallel stack is
stable.
You can attach a test case as private if you can't disclosure it.
On Thu, Aug 9, 2012 at 2:01 AM, Greg Young gregoryyou...@gmail.com wrote:
Actually its worse than that. We have found that *anything that uses
callbacks* suffers from the same problems (eg any async API
This would be a good one to get into trunk
https://github.com/ysw/mono-socket-problem/blob/master/Patches/cb_fix.patch
On Thu, Aug 9, 2012 at 5:51 PM, Greg Young gregoryyou...@gmail.com wrote:
We already have put it here with some associated fixes.
On Thu, Aug 9, 2012 at 7:48 AM, Rodrigo
We regularly can cause problems with ConcurrentQueue such as
System.NullReferenceException: Object reference not set to an instance
of an object
at
System.Collections.Concurrent.ConcurrentQueue`1[System.IO.FileStream].TryDequeue
(System.IO.FileStream result) [0x0] in filename unknown:0
trunk.
On Fri, Aug 10, 2012 at 2:53 AM, Alan alan.mcgov...@gmail.com wrote:
Hey,
What version of Mono are you testing against?
Alan
On 10 August 2012 09:52, Greg Young gregoryyou...@gmail.com wrote:
We regularly can cause problems with ConcurrentQueue
happen?
--
Jérémie Laval
http://neteril.org
On Fri, Aug 10, 2012 at 10:53 AM, Greg Young gregoryyou...@gmail.com
wrote:
trunk.
On Fri, Aug 10, 2012 at 2:53 AM, Alan alan.mcgov...@gmail.com wrote:
Hey,
What version of Mono are you testing against?
Alan
On 10 August 2012 09:52
[Test]
public void does_not_throw_exception_on_non_existing_file() {
Assert.DoesNotThrow(() = File.SetAttributes(DOESNOTEXIST,
FileAttributes.ReadOnly));
}
Cheers,
Greg
--
Le doute n'est pas une condition agréable, mais la certitude est absurde.
bizarre, their docs say it should throw but they don't.
http://msdn.microsoft.com/en-us/library/system.io.file.setattributes.aspx
Not sure which is better, what they say they do or what they do?
On Fri, Aug 10, 2012 at 10:01 AM, Greg Young gregoryyou...@gmail.com wrote:
[Test]
public void
I'm fine by that. Is there a list of these incompatibilities that is
being maintained?
On Fri, Aug 10, 2012 at 8:09 PM, Jonathan Chambers jonc...@gmail.com wrote:
Historically, mono has done what .Net does rather than what it says.
- Jonathan
On Fri, Aug 10, 2012 at 1:07 PM, Greg Young
javascript:_e({}, 'cvml',
'gonzalo.m...@gmail.com'); wrote:
On Thu, Aug 9, 2012 at 11:57 AM, Greg Young
gregoryyou...@gmail.comjavascript:_e({}, 'cvml',
'gregoryyou...@gmail.com');
wrote:
This would be a good one to get into trunk
https://github.com/ysw/mono-socket-problem/blob/master
We are allocating and releasing unmanaged memory with marshal.allochglobal.
In mono we are getting the following failure (no failures under clr).
Any ideas?
part from team city logs:
[20:55:52][Step 2/2] mono: malloc.c:2451: sYSMALLOc: Assertion `(old_top ==
(((mbinptr) (((char *)
or linux's malloc is. Mono does nothing special
but call malloc/free.
One issue might be if you're allocating more than 2Gb of memory at once.
This will probably break on mono.
On Thu, Aug 23, 2012 at 3:35 AM, Greg Young
gregoryyou...@gmail.comjavascript:_e({}, 'cvml',
'gregoryyou...@gmail.com
Will take a look. Not sure what it may not be liking. Code is very basic.
Literally allocates 16mb chunk then frees it (each object has one) code
works fine in windows with same calls. Will debug it on Sunday.
On Friday, August 24, 2012, Jonathan Pryor wrote:
On Aug 23, 2012, at 2:35 AM, Greg
We have been experiencing crashes as well on large heaps. What can we do to
help with this issue?
On Thursday, August 30, 2012, Jonathan Shore wrote:
Ok, thanks. sgen fails for me for non-trivial programs (the VM crashes in
2.10.9 and 2.11.3 in different ways on both OSX and Linux). I'll
I have to admit I am a bit surprised how buggy concurrentqueue is.
If you are reading this and building software that needs to run in a
stable fashion just say no to concurrent queue. I have placed a few
issues here before but we have seen it infinite loop internally, throw
null reference
We have had a patch for a while related to a problem we ran into with TCP
https://github.com/ysw/mono-socket-problem/blob/master/Patches/cb_fix.patch
Its still not in trunk. We have provided tests of TCP not calling back
async (breaks async loop) under load without this fix. As of now our
doing now.
On Wed, Sep 19, 2012 at 3:46 PM, Alan alan.mcgov...@gmail.com wrote:
Have you submitted the change as a pull request on github?
Alan
On 19 September 2012 13:43, Greg Young gregoryyou...@gmail.com wrote:
We have had a patch for a while related to a problem we ran into with TCP
reviewing commits
object pool is DEAD! and I don't mean 57005 :)
OK will go faster home to check it now.
Greg
On Tue, Sep 25, 2012 at 4:56 PM, Greg Young gregoryyou...@gmail.com wrote:
I will pull in a few minutes and give it a try.
Cheers,
Greg
On Tue, Sep 25, 2012 at 4:44 PM, Jérémie
/
On Tue, Sep 25, 2012 at 5:00 PM, Konrad M. kkruczyn...@antmicro.com wrote:
On Tue, 2012-09-25 at 16:57 +0300, Greg Young wrote:
reviewing commits
object pool is DEAD! and I don't mean 57005 :)
Btw, some tests I did with and without object pool (by reverting
introducing commit) showed
Related to another post. Best way to optimize mono on a server product.
Tcp/heavy io...
--
Le doute n'est pas une condition agréable, mais la certitude est absurde.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
Just tried writing some code using spinlock and it was having many
issues in mono. Tried same code in windows on CLR and no issues. Is
SpinLock expected to be in a working state?
Cheers,
Greg
--
Le doute n'est pas une condition agréable, mais la certitude est absurde.
Ok I'll try to isolate the issue tomorrow
On Thursday, November 1, 2012, Rodrigo Kumpera wrote:
What issues? The code is meant to be ready
On Thu, Nov 1, 2012 at 8:38 AM, Greg Young
gregoryyou...@gmail.comjavascript:_e({}, 'cvml',
'gregoryyou...@gmail.com');
wrote:
Just tried writing
Its more your app that would be scalable/not scalable.
Right now over http we can consistently do up to a few thousand requests/second
It have with .Net (of course watching out for
the differences with IIS and apache/mod_mono though)
On Sat, Nov 17, 2012 at 5:58 PM, Frank Cohen
It looks like some of the patches we had pushed to 2.x never made it
to 3.0.1? We are seeing some of the same kinds of issues with TCP as
previously (eg call beginsend never get an endsend). There is
discussion in the history of the list. I can go figure out which
relevant patches might be missing
...@gmail.com wrote:
It depends on what patches. One I did merge had to be reverted due to
causing deadlocks.
On Tue, Nov 27, 2012 at 1:45 PM, Greg Young gregoryyou...@gmail.com wrote:
3.0.1? We are seeing some of the same kinds of issues with TCP as
previously (eg call beginsend never get
, held by a thread waiting on new_sem.
This reverts commit 11286da0ac2e2bab7b2d8ab04b9f6a4da4e12131, reversing
On Wed, Nov 28, 2012 at 1:23 AM, Greg Young gregoryyou...@gmail.com wrote:
I would be curious in talking a bit more about this because without it
TCP does not work reliably
except for the tests we put as well
On Thu, Nov 29, 2012 at 11:33 PM, Rodrigo Kumpera kump...@gmail.com wrote:
The original patch did not say what it did fix, so there was not much to
discuss.
On Thu, Nov 29, 2012 at 3:56 PM, james ja...@mansionfamily.plus.com wrote:
Seems bizarre that
Thats already been provided (though its not hard to do). I will
reupload a test that shows beahviour.
On Fri, Nov 30, 2012 at 12:56 AM, NokNok Developer develo...@noknok.net wrote:
Caqn you provide a test case/code which demonstrates the deadlock? That
would be beneficial, otherwise i do not
I was in looking at some code today in httplistener and didn't understand
some of the stuff going on (was hitting a performance penalty due to it).
In particular I was a bit confused when looking at Begin and EndGetContext
(included below).. It would seem harmful to call ares.Complete below while
relevant.
On Wed, Dec 5, 2012 at 8:52 AM, Greg Young gregoryyou...@gmail.comwrote:
CheckDisposed ();
if (!listening)
throw new InvalidOperationException (Please, call Start before using
this method.);
ListenerAsyn
--
Le doute n'est pas une condition agréable, mais la certitude est absurde
.
On 05/12/12 14:05, Rodrigo Kumpera wrote:
Did you look at the git history for those changes to see why those
changes have been made?
04c641a21c2ba92c3262948ed1b68e**b22c643b11 seens relevant.
On Wed, Dec 5, 2012 at 8:52 AM, Greg Young gregoryyou...@gmail.com
mailto:gregoryyoung1@gmail
.
On Fri, Nov 30, 2012 at 12:29 AM, Greg Young gregoryyou...@gmail.comwrote:
Thats already been provided (though its not hard to do). I will
reupload a test that shows beahviour.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http
30, 2012 at 12:29 AM, Greg Young gregoryyou...@gmail.comwrote:
Thats already been provided (though its not hard to do). I will
reupload a test that shows beahviour.
--
Le doute n'est pas une condition agréable, mais la certitude est absurde
Its not reproducible even in our code base. Sometimes we get a sigfault
sometimes not. It may happen 20 times in a row and not happen 20 times on
an identical box.
On Thu, Dec 6, 2012 at 6:13 PM, Rodrigo Kumpera kump...@gmail.com wrote:
Please file a bug report with a reproducible test case.
Using mono on a raspberry pi. Not sure if it has been reported before.
The date part of DateTime is off and TimeSpan is a bit quirky eg
var span = TimeSpan.FromMilliseconds(1);
Console.WriteLine(span.TotalSeconds);
Prints 0
--
Le doute n'est pas une condition agréable,
4. It's .NET code, really, so you should be able to use most .NET code that
doesn't call native code (otherwise it's a bug or unimplemented feature).
You can use MSDN as a reference.
Let's not forget about the implemented un-features.
Happy new year!
Greg
On Mon, Dec 31, 2012 at 4:42 PM,
The .NET dictionary implementation is thread safe on reads/updates so
long as the internal collection does not grow and size is of reference
type or smaller. eg: if you set size to 1m items and had 100k with a
fill factor that did not cause an internal growth it would be
threadsafe. This assurance
it!) but 'That's funny ...'
Isaac Asimov
US science fiction novelist scholar (1920 - 1992)
On Sun, Feb 3, 2013 at 5:15 PM, Greg Young gregoryyou...@gmail.com wrote:
The .NET dictionary implementation is thread safe on reads/updates so
long as the internal collection does not grow and size is of reference
it sounds like an unintentional implementation detail that
shouldn't be relied on?
You could probably look at the SSCLI and see if there's any comments around
it (but I think that if you look at that code, you will be unable to
contribute to Mono).
On Mon, Feb 4, 2013 at 9:46 PM, Greg Young
tess covers race condition here
http://blogs.msdn.com/b/tess/archive/2009/12/21/high-cpu-in-net-app-using-a-static-generic-dictionary.aspx
i figured it was only for items ref size.
On Mon, Feb 4, 2013 at 1:07 PM, Greg Young gregoryyou...@gmail.com wrote:
from reading it appears
ASP.NET has stagnated in Microsoft since the Novell era.
I would try porting MVC3 but you don't really have to port it as its all managed
look at kayak or nancy lately or the others like it?
On Fri, Apr 12, 2013 at 6:10 PM, Message Box msgbox...@gmail.com wrote:
ASP.NET support in
We still have this patch that we use with mono.
diff --git a/mono/metadata/threadpool.c b/mono/metadata/threadpool.c
index e8a2f1a..f83e473 100644
--- a/mono/metadata/threadpool.c
+++ b/mono/metadata/threadpool.c
@@ -555,8 +555,8 @@ socket_io_add (MonoAsyncResult *ares,
MonoSocketAsyncResult
?
Thanks for bringing awareness for the problem, :)
Rafael Teixeira
O..:.)
On Wed, May 29, 2013 at 1:09 PM, Greg Young
gregoryyou...@gmail.comjavascript:;
wrote:
So we have reproduced bugs even with suggestions given (and documented)
How do we move forward from this point? We have
I would expect this to look at http caching headers in response when
caching such as expiration, whether something is cachable (public/private) etc
but don't see any of that code (or maybe I missed it). Can you point to
where it is in your implementation?
On Tuesday, June 4, 2013, Mark Lintner
@My Holiday
On Thursday, June 6, 2013, Ian Norton wrote:
Hiya, I'm aware that I can use Process.Start() but I'd really really like
to be able to directly pass a list of strings to my child process as
arguments rather than having to escape shell characters and spaces etc.
Ie, In perl or C
Anyone know if aptgets will be updated with 3.2?
--
Le doute n'est pas une condition agréable, mais la certitude est absurde.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
There are many cases the patch we provided does not affect eg no overlap in
io between send/receive
On Tuesday, August 6, 2013, Nikita Tsukanov wrote:
Interesting... I've written a simple server using only Socket.BeginRecieve
and Socket.BeginSend. It just reads 100 bytes and then sends
and write simultaneously
on the same socket.
2013/8/6 Greg Young gregoryyou...@gmail.com javascript:_e({}, 'cvml',
'gregoryyou...@gmail.com');
There are many cases the patch we provided does not affect eg no overlap
in io between send/receive
On Tuesday, August 6, 2013, Nikita Tsukanov wrote
. Not sure that it's the same
issue, because in my case it never tries to read and write simultaneously
on the same socket.
2013/8/6 Greg Young gregoryyou...@gmail.com javascript:_e({}, 'cvml',
'gregoryyou...@gmail.com');
There are many cases the patch we provided does not affect eg no overlap
We will see your test then as it will probably affect us as well
On Tuesday, August 6, 2013, Nikita Tsukanov wrote:
Greg, I've tried running my server with mono compiled from master (with
pull request #703 merged in), still freezes after a while.
2013/8/7 Greg Young gregoryyou...@gmail.com
running under it. I also unable to grab thread stack traces, it prints
Full thread dump: and nothing else.
2013/8/7 Greg Young gregoryyou...@gmail.com
We will see your test then as it will probably affect us as well
On Tuesday, August 6, 2013, Nikita Tsukanov wrote:
Greg, I've tried
As a thought, it might be a good idea to have a simplified system for being
able to do development on things like class libraries where people can get
up and running within 2-3 minutes. As of now it seems getting an
environment setup is a major impediment that prevents a lot of people from
We have an application with a fairly common usage pattern. We send many
messages in memory between a series of components (often with queues in the
middle). In looking through sgen and defaults etc it would seem that by
default there is a 4kb nursery. In this case we would have many of these
small
sorry for type meant 4mb not 4kb (that would be a really small nursery!)
On Mon, Oct 28, 2013 at 3:38 PM, Greg Young gregoryyou...@gmail.com wrote:
We have an application with a fairly common usage pattern. We send many
messages in memory between a series of components (often with queues
Search for ilmerge it can do this after the compilation.
On Mon, Nov 25, 2013 at 5:27 PM, Vassil Vassilev v.g.vassi...@gmail.comwrote:
Hi,
Thanks for the answer. This seemed not to be the case with the M$
compiler. I will double check today.
Is there any way to build 'fat libraries'
Mono appears to be missing a constructor that takes a secure string for
network credentials. We figured it could therefore be set by using the
setter for it. When setting in this way it does not appear to work properly
with HttpWebRequest. Did not have time to debug it. To reproduce just use a
Interesting issue came up today. All code works fine when run with mono
regularly. However when we statically link mono and put the system under
pressure we end up getting a SIGABRT on a fairly innocuous call (not right
away). We cannot reproduce this with mono not statically linked. Anyone
have
in master branch. Try master.
On 10/01/14 11:34, Andrés G. Aragoneses wrote:
What version of mono, and what architecture are you running this on?
On 07/01/14 16:20, Greg Young wrote:
Interesting issue came up today. All code works fine when run with
mono
regularly. However when we statically
[Conditional(DEBUG)]
public void Enqueued()
{
Interlocked.Increment(ref _length);
}
in Debug build results in:
/opt/mono/lib/mono/4.5/Microsoft.CSharp.targets (CoreCompile target) -
Bus/QueueStatsCollector.cs(275,39): error CS0103: The name `_length'
preprocessor symbol. The code is still semantically checked.
On Fri, Feb 28, 2014 at 3:37 PM, Greg Young gregoryyou...@gmail.com
wrote:
[Conditional(DEBUG)]
public void Enqueued()
{
Interlocked.Increment(ref _length);
}
in Debug build
http://server.com/ -X POST
Cheers,
Greg
On Fri, Feb 28, 2014 at 3:48 PM, Sebastien Pouliot
sebastien.poul...@gmail.com wrote:
Hello Greg,
Use the contact form found at
http://www.mono-project.com/Vulnerabilities
Thanks
Sebastien
On Fri, Feb 28, 2014 at 8:40 AM, Greg Young gregoryyou
Thanks not sure how we missed it on the .net side.
On Fri, Feb 28, 2014 at 4:42 PM, Greg Young gregoryyou...@gmail.com wrote:
hmm I will have to check with msbuild I am pretty sure that code was
compiling in .net
On Fri, Feb 28, 2014 at 4:40 PM, Alex Rønne Petersen a...@alexrp.comwrote
.
Obviously this is relatively old.
Sent from a computer
On Feb 28, 2014, at 9:22 AM, Greg Young gregoryyou...@gmail.com wrote:
After some reproduction work we found it was an API difference in mono
httplistener vs .net http listener that caused us to mangle something.
In particular
We can reproduce this reasonably easily under load.
from gdb.
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffed7f2700 (LWP 3886)]
copy_object_no_checks (obj=obj@entry=0x76683150,
queue=queue@entry=0x9831c0 gray_queue) at sgen-copy-object.h:110
110
I should add that this is on trunk.
greg@goblin:~/src/EventStore/bin/eventstore/release/anycpu$ mono --version
Mono JIT compiler version 3.4.0 (master/9c4c295 Pn Vas 28 17:26:05 EET 2014)
Vas=Feb
On Sat, Mar 1, 2014 at 2:03 PM, Greg Young gregoryyou...@gmail.com wrote:
We can reproduce
Doesn't happen every time I build from source but occasionally get this.
ubuntu
MCS [build] mscorlib.dll
Stacktrace:
at unknown 0x
at (wrapper managed-to-native) System.Environment.Exit (int) 0x
at Mono.CSharp.Driver.Main (string[]) 0x001f7
at (wrapper
Actually this build fails always.
3.2.7
3.2.8 or any other builds just dandy here.
On Sat, Mar 1, 2014 at 2:28 PM, Greg Young gregoryyou...@gmail.com wrote:
Doesn't happen every time I build from source but occasionally get this.
ubuntu
MCS [build] mscorlib.dll
Stacktrace
=0xa1ec28, size=size@entry=48) at sgen-alloc.c:288
#10 0x005f4d44 in mono_gc_alloc_vector (vtable=0xa1ec28, size=48,
max_length=16) at sgen-alloc.c:491
#11 0x400141c9 in ?? ()
On Sat, Mar 1, 2014 at 2:12 PM, Greg Young gregoryyou...@gmail.com wrote:
I should add
Just off the top of my head... maybe a summer of code would be better spent
on these kinds of issues and improving the throughput of donations as
opposed to the next interesting technical topic.
Greg
On Wed, Mar 19, 2014 at 2:39 AM, Konaju Games (Dev) d...@konaju.com wrote:
I spent 4 days
Before go searching for what happening and whether its something odd here
can anyone build trunk right now? I can build 3.2.8 no problem
--
Le doute n'est pas une condition agréable, mais la certitude est absurde.
___
Mono-devel-list mailing list
Didn't get one until the end and it was unable to stat mcs I thought I
saw a SIGABORT somewhere along the way but it kept running.
On Thu, Mar 20, 2014 at 7:14 PM, Andrés G. Aragoneses kno...@gmail.comwrote:
On 20/03/14 18:08, Greg Young wrote:
Before go searching for what happening
dumped)
On Thu, Mar 20, 2014 at 7:17 PM, Greg Young gregoryyou...@gmail.com wrote:
Didn't get one until the end and it was unable to stat mcs I thought I
saw a SIGABORT somewhere along the way but it kept running.
On Thu, Mar 20, 2014 at 7:14 PM, Andrés G. Aragoneses
kno...@gmail.comwrote
successfully on
Mar 19.
Regards, David
On 20.03.2014 18:08, Greg Young wrote:
Before go searching for what happening and whether its something odd
here can anyone build trunk right now? I can build 3.2.8 no problem
--
Le doute n'est pas une condition agréable, mais la certitude est
.
=
Aborted
I've attached the full log.
Regards, David
On 21.03.2014 11:31, Greg Young wrote:
What version of mono did you use to build mono?
I was running 3.2.8-master 3.4.1. The whole runtime builds no problem
its just the AOT of mcs for 4 and 45 that breaks.
On Thu, Mar 20, 2014 at 8:00
I was looking through some of the mcs warnings on mono build today and some
seem to be off from looking at the code
System.Collections.Concurrent/BlockingCollection.cs(387,4): warning CS0162:
Unreachable code detected
System.Collections.Concurrent/BlockingCollection.cs(375,9): warning CS0219:
The
Is this worth reporting as a bug or do you think the people working on mcs
already know about it since its happening in the mono sources? :)
On Fri, Mar 21, 2014 at 5:35 PM, Marek Safar marek.sa...@gmail.com wrote:
Hello,
Also should the line number be pointing to the actual line in the
wrote:
Thanks to guidance from Greg Young, I've been able to isolate a proper
backtrace from nunit-console:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffef97a700 (LWP 26908)]
slow_object_get_size (o=0x7fffea860010, vtable=optimized out) at
../../mono/metadata
We get 5000 just using httplistener.
On Mon, Apr 7, 2014 at 5:35 PM, Alfred Hall ah...@ahall.org wrote:
I've been experimenting with hello world requests running under
self-hosted Nancy and I'm getting about 2000 requests/second and sometimes
locks up after a long period of time. When
Nice I will pull and check it out.
Good work.
Greg
On Sat, Apr 12, 2014 at 7:50 PM, Nikita Tsukanov kek...@gmail.com wrote:
Hello there. Today I spent some time messing up with libevent and managed
to implement multiworker mode (multiple threads accepting connections from
the same socket)
Could it be a cached console? right below it would appear to be calling
into an event handler.
On Mon, Apr 21, 2014 at 11:43 PM, Edward Ned Harvey (mono)
edward.harvey.m...@clevertrove.com wrote:
This is what's displayed on terminal:
The only explanation I can come up with is that a
So the one issue I have seen with the libevent implementation is that it
seems to perform very poorly in windows (+-5k hello worlds/second where as
its closer to 100k/second in linux). From researching libevent they
supposedly now use IOCP in windows and should be better but I have not been
able
1 - 100 of 217 matches
Mail list logo
