[prev in list] [next in list] [prev in thread] [next in thread] 

List:       opensim-users
Subject:    [Opensim-users] Ubuntu and magic mini-trampolines (crash problem)
From:       aerowolf () gmail ! com (Kyle Hamilton)
Date:       2009-04-28 18:44:55
Message-ID: 6b9359640904281144v6d3417b1qae7a7d65f9c50432 () mail ! gmail ! com
[Download RAW message or body]

When you attach gdb to a running process, you need to use the 'cont'
command to have gdb continue the process.

-Kyle H

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


[prev in list] [next in list] [prev in thread] [next in thread]