Re: [Mono-dev] Assert in mini-arm.c

[Bassam Tabbara]

Folks,

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

Thanks!
Bassam

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

Hello,

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

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

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

Any tips on how to debug this further?

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

Re: [Mono-dev] NancyFX self hosting (HttpListener) locking up on linux

[Nikita Tsukanov]

I've filled a bug report:
https://bugzilla.xamarin.com/show_bug.cgi?id=13933(also increased
thread count from 2 to 10 to make it easier to reproduce
the issue).


2013/8/12 Nikita Tsukanov 

>
> Oh, great. I've got lockup and segfault (on different runs) with this code:
>  static INancyEngine _engine;
>
> public static void Main(string[] args)
> {
> var pool = new SmartThreadPool ();
>
>
> var bt = new DefaultNancyBootstrapper ();
> bt.Initialise ();
> _engine = bt.GetEngine ();
> for (int c=0; c<2; c++)
> new Thread (ThreadProc).Start ();
> Thread.Sleep (-1);
> }
>
> static void ThreadProc ()
> {
> int crid = 0;
> while (true) {
> crid ++;
> var resp = _engine.HandleRequest (
>
> new Request ("GET", "/",
>  new Dictionary IEnumerable> (),
>  RequestStream.FromStream (new
>  MemoryStream (), 0, 0), "http", "", "127.0.0.1"));
> resp.Response.Contents (new MemoryStream
> ());
> Console.WriteLine ("Request #{0} done",
> crid);
> }
> }
>
> It just uses nancyfx engine from 2 threads.
>
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] NancyFX self hosting (HttpListener) locking up on linux

[Nikita Tsukanov]

Oh, great. I've got lockup and segfault (on different runs) with this code:
 static INancyEngine _engine;
public static void Main(string[] args)
{
var pool = new SmartThreadPool ();

var bt = new DefaultNancyBootstrapper ();
bt.Initialise ();
_engine = bt.GetEngine ();
for (int c=0; c<2; c++)
new Thread (ThreadProc).Start ();
Thread.Sleep (-1);
}

static void ThreadProc ()
{
int crid = 0;
while (true) {
crid ++;
var resp = _engine.HandleRequest (
new Request ("GET", "/",
 new Dictionary> (),
 RequestStream.FromStream (new
MemoryStream (), 0, 0), "http", "", "127.0.0.1"));
resp.Response.Contents (new MemoryStream ())
;
Console.WriteLine ("Request #{0} done", crid
);
}
}

It just uses nancyfx engine from 2 threads.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] NancyFX self hosting (HttpListener) locking up on linux

[Nikita Tsukanov]

Hello.
I've reproduced the problem without ANY I/O only with NancyFx.

Following code leads to lock up:

 class MainClass
{
public static void Main(string[] args)
{
var bt = new DefaultNancyBootstrapper ();
bt.Initialise ();
var engine = bt.GetEngine ();
int rid = 0;
while (true)
{
var crid = rid++;

ThreadPool.QueueUserWorkItem (_ =>
{
var resp = engine.HandleRequest (
new Request ("GET", "/",
  new Dictionary> (),
  RequestStream.
FromStream (new MemoryStream (), 0, 0), "http", "", "127.0.0.1"));
resp.Response.Contents (new
MemoryStream ());
Console.WriteLine("Request #{0} done
", crid);
});
Console.WriteLine("Request #{0} added", crid
);

}
}


}

public class TestController : NancyModule
{
public TestController ()
{
Get ["/"] = _ => "test";
}
}


It works fine with mono 2.10.8 from Ubuntu repos.




2013/8/8 Nikita Tsukanov 

> I'm unable to reproduce the issue with HttpListener/Sockets alone. It
> needs INancyEngine.ProcessReqiest() somewhere in request processing
> pipeline. So I'm still investigating, what conditions are needed to
> repoduce the bug (and I suspect that it doesn't have to do with I/O at all,
> since it reproduces even with my hand-made send/recv sockets backend).
>
>
> 2013/8/7 "Andrés G. Aragoneses" 
>
>> If you're able to reproduce it with 3.3 and not with 2.10.x, you should
>> definitely open a bug report for it in http://bugzilla.xamarin.com/stating 
>> "[regression]" in the bug summary.
>>
>> Also, I would open a separate bug report for the segfault you're getting
>> when running with MONO_DISABLE_AIO (pasting the backtrace of the segfault,
>> with debug symbols installed).
>>
>>
>> On 07/08/13 14:02, Alfred Hall wrote:
>>
>>> Tried running it with sgen or boehm on 2.10? Worth trying both I think.
>>> Also how about 3.3 (master) ?
>>>
>>> -Original message-
>>> *From:* Nikita Tsukanov 
>>> *Sent:* Wednesday 7th August 2013 12:54
>>> *To:* 
>>> mono-devel-list@lists.ximian.**com
>>> *Subject:* Re: [Mono-dev] NancyFX self hosting (HttpListener)
>>>
>>> locking up on linux
>>>
>>> I've rewritten my SCGI server to work with TPL directly instead of
>>> using async/await to make it run on mono 2.10. Then I've tried to
>>> run it with mono 2.10.8.1 and mono 3.2 with System.Net.Sockets
>>> backend and to hammer it with jmeter. 500K requests without any
>>> lockups on Mono 2.10, lockup at 22164th request on mono 3.2.
>>>
>>> Server source code is still on GitHub -
>>> 
>>> https://github.com/kekekeks/**scgi-sharp
>>>
>>>
>>> 2013/8/7 Greg Young >> >
>>>
>>>
>>> I believe attaching a debugger changes things like optimizations
>>> from occurring (not positive but it does in clr)
>>>
>>>
>>> On Wednesday, August 7, 2013, Nikita Tsukanov wrote:
>>>
>>> Huh, it doesn't require debugger to be _attched_, just
>>> debugging subsystem initialized i. e. if I launch this
>>> program as a "debugger" it doesn't lock up.
>>>
>>> publicstaticvoidMain(string[]**args)
>>> {
>>> intport=27042;
>>> if(args.Length !=0)
>>> port=int.Parse(args[0]);
>>> while(true)
>>> {
>>> varvm= Mono.Debugger.Soft.**VirtualMachineManager.Listen(**
>>> newIPEndPoint(IPAddress.**Loopback,port));
>>> vm.Resume();
>>> vm.Detach();
>>> }
>>> }
>>>
>>> I'll use running with
>>> --debugger-agent=transport=dt_**socket,address=
>>> 127.0.0.1:27042
>>>  as a temporary workaround since
>>>
>>> performance doesn't degrade a lot.
>>>
>>>
>>> 2013/8/7 Nikita Tsukanov 
>>>
>>> I suspect that the problem is actually with thread pool
>>> itself. I've created socket layer implementation using
>>> libevent (wrapped with Oars) and send/recv that utilizes
>>> thread pool for cases when it's unable to complete
>>> operation synchronously. It survives longer, but still
>>> lo

Re: [Mono-dev] Random deadlocks when spawning via new Process

[Rodrigo Kumpera]

I filed https://bugzilla.xamarin.com/show_bug.cgi?id=13920 to track this.



On Mon, Aug 12, 2013 at 10:40 AM, Rodrigo Kumpera  wrote:

> I have no idea.  I'd need to reproduce it first
>
>
> On Sun, Aug 11, 2013 at 7:01 PM, gerber.matthew 
> wrote:
>
>> Rodrigo Kumpera wrote
>> > Can you produce a test case that shows this hang? This it will be much
>> > easier for the moonteam to debug and fix it.
>>
>> Rodrigo (and others),
>>
>> Do you have any insight into the deadlock situation I described above?
>>
>> Cheers,
>> Matt
>>
>>
>>
>>
>> --
>> View this message in context:
>> http://mono.1490590.n4.nabble.com/Random-deadlocks-when-spawning-via-new-Process-tp4660495p4660511.html
>> Sent from the Mono - Dev mailing list archive at Nabble.com.
>> ___
>> Mono-devel-list mailing list
>> Mono-devel-list@lists.ximian.com
>> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>>
>
>
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Random deadlocks when spawning via new Process

[gerber.matthew]

Rodrigo Kumpera wrote
> I have no idea.  I'd need to reproduce it first

Rodrigo,

>From your message, I can't tell whether or not you saw my previous post with
an example program that will reproduce the deadlock. Or maybe you saw the
post but the program didn't deadlock for you? Please let me know if I can
help in any way.

Best,

Matt





--
View this message in context: 
http://mono.1490590.n4.nabble.com/Random-deadlocks-when-spawning-via-new-Process-tp4660495p4660514.html
Sent from the Mono - Dev mailing list archive at Nabble.com.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Random deadlocks when spawning via new Process

[Rodrigo Kumpera]

I have no idea.  I'd need to reproduce it first


On Sun, Aug 11, 2013 at 7:01 PM, gerber.matthew wrote:

> Rodrigo Kumpera wrote
> > Can you produce a test case that shows this hang? This it will be much
> > easier for the moonteam to debug and fix it.
>
> Rodrigo (and others),
>
> Do you have any insight into the deadlock situation I described above?
>
> Cheers,
> Matt
>
>
>
>
> --
> View this message in context:
> http://mono.1490590.n4.nabble.com/Random-deadlocks-when-spawning-via-new-Process-tp4660495p4660511.html
> Sent from the Mono - Dev mailing list archive at Nabble.com.
> ___
> Mono-devel-list mailing list
> Mono-devel-list@lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list