<div>F.Y.I.<br><br>OpenSim 0.6.4.9332<br>Debian Lenny 5.0.1 <br>Mono JIT compiler version 20090414 <br>(tarball Mon Apr 27 13:11:24 CEST 2009)<br><br>Compiled and installed Mono from source recently. One thing I noticed<br>during the 'make install', albeit it in a flash on screen, is that there <br>were compilation warnings during the use of mini-trampoline.cs ( don't <br>remember specific names ) where ".... type was declared but it's value is never used".<br><br>The mini-trampoline error/crash while starting opensim always happens when<br> the section of scripts starts. Never happens earlier. I mean , the crash , in my case <br>with XEngine , always occurs at [XEngine] NameScriptLoading . After these crashes I<br>also noticed shutting down all of UGAIM and restarting them, made the crash 'stay away'.<br><br>As I type I am starting and shutting down to reproduce the crash. I will check Mantis if <br>I can add debug info , if any at all.<br><br>My efforts till now to backtrace with gdb have been unsuccesful. There are no debugging symbols for opensim,<br>or better, I do not know how to create/obtain them. Tried to hook gdb to the opensim' pid-id, but that stalls the running <br>opensim instance completely. <br>
<br>Maybe I should reinstall Mono and catch the warnings of the types of mini-trampolines.cs .. :S<br><br>
<blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;">----- Original Message -----<br>
From: "Mic Bowman" <cmickeyb@gmail.com><br>
To: opensim-users@lists.berlios.de<br>
Subject: Re: [Opensim-users] Ubuntu and magic mini-trampolines (crash problem)<br>
Date: Tue, 28 Apr 2009 08:16:10 -0700<br>
<br>
<br>
in general we see crashes, not freezes. the apparent freeze is usually<br>
caused by the gdb process that gets started when the crash occurs<br>
(kill the gdb process and the simulator crashes "gracefully").<br>
<br>
given that the problem seems to happen when log4net attempts to get a<br>
logger associated with a particular script class, my guess is that one<br>
of a couple problems is happening... 1) mono is somehow messing up the<br>
class that is passed in (there are nulls in the argument stack that<br>
look suspicious), 2) log4net isn't as thread-safe as it claims (though<br>
the routine that creates the wrapper object looks fine at first<br>
glance), 3) somehow mono is screwing up the assembly binding when<br>
log4net creates the wrapper. I've looked at the mono code that is<br>
throwing the exception... but it wasn't very helpful without a LOT<br>
more investigation.<br>
<br>
at this point, i'm building a custom log4net dll with some additional<br>
debugging in it. which, given that this certainly appears to be a<br>
timing issue, will almost certainly hide the problem. :-(<br>
<br>
--mic<br>
<br>
<br>
On Tue, Apr 28, 2009 at 5:04 AM, Dr Scofield <drscofield@xyzzyxyzzy.net> <br>
wrote:<br>
> Mic Bowman wrote:<br>
>> we've seen the problem with mono_threads_per_cpu set across a range of<br>
>> values (i think we've tried a number of values from 100 to 1000).<br>
>> there doesn't appear to be any correlation.<br>
><br>
> ok. we had freezes that got cured by increasing MONO_THREADS_PER_CPU, hence <br>
> my<br>
> asking...<br>
><br>
> a real deadlock is nasty... :-( sigh.<br>
><br>
> DrS/dirk<br>
>><br>
>> --mic<br>
>><br>
>><br>
>> On Mon, Apr 27, 2009 at 10:38 PM, dr scofield <drscofield@xyzzyxyzzy.net> <br>
>> wrote:<br>
>>> Justin Clark-Casey wrote:<br>
>>><br>
>>> Mic Bowman wrote:<br>
>>><br>
>>><br>
>>> I have the same freeze at times. In my case there's a gdb process<br>
>>> running that I can kill off to terminate the simulator.<br>
>>><br>
>>><br>
>>><br>
>>> I presume there's no revealing deadlock information in the thread dump<br>
>>> (perhaps that's too much to hope for :) ?<br>
>>><br>
>>><br>
>>> what is your value of the MONO_THREADS_PER_CPU environment variable?<br>
>>><br>
>>> --<br>
>>> dr dirk husemann ---- math & computer science ---- ibm zurich research lab<br>
>>> RL: hud@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/<br>
>>> SL: drscofield@xyzzyxyzzy.net --------------------- http://xyzzyxyzzy.net/<br>
>>><br>
>>> _______________________________________________<br>
>>> Opensim-users mailing list<br>
>>> Opensim-users@lists.berlios.de<br>
>>> https://lists.berlios.de/mailman/listinfo/opensim-users<br>
>>><br>
>>><br>
>> _______________________________________________<br>
>> Opensim-users mailing list<br>
>> Opensim-users@lists.berlios.de<br>
>> https://lists.berlios.de/mailman/listinfo/opensim-users<br>
>><br>
><br>
><br>
> --<br>
> dr dirk husemann ---- virtual worlds research ---- ibm zurich research lab<br>
> SL: dr scofield ---- drscofield@xyzzyxyzzy.net ---- http://xyzzyxyzzy.net/<br>
> RL: hud@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/<br>
> _______________________________________________<br>
> Opensim-users mailing list<br>
> Opensim-users@lists.berlios.de<br>
> https://lists.berlios.de/mailman/listinfo/opensim-users<br>
><br>
_______________________________________________<br>
Opensim-users mailing list<br>
Opensim-users@lists.berlios.de<br>
https://lists.berlios.de/mailman/listinfo/opensim-users<br>
</drscofield@xyzzyxyzzy.net></drscofield@xyzzyxyzzy.net></cmickeyb@gmail.com></blockquote>
<p>
<br>
<br>
</p><pre>__________
WiLLuMPJuH
</pre>
</div>
<BR>
--
<div> It's News. It's Reviews. It's Interviews. It's Free. What Are You Waiting For?<br>
<a href="http://www.movieline.com " target="_blank">www.movieline.com</a>!</div>