OK, I have two clues:

1. My last crash included a few snippets of stack trace with
GetUninitializedOBject in it. See below:


2011-12-18 21:56:27.458 I 23015/mono: Stacktrace:
2011-12-18 21:56:27.458 I 23015/mono:   at
System.Runtime.Serialization.FormatterServices.GetUninitializedObject
(System.Type) <0x00033>
2011-12-18 21:56:27.458 I 23015/mono:   at (wrapper dynamic-method)
object.88e467bd-07c4-4843-868b-f497dc3a2cac (intptr,object[]) <0x0002b>
2011-12-18 21:56:27.488 E 23015/mono:
Unhandled Exception: System.NullReferenceException: Object reference not
set to an instance of an object
at System.Runtime.Serialization.FormatterServices.GetUninitializedObject
(System.Type) <0x00033>
at (wrapper dynamic-method) object.88e467bd-07c4-4843-868b-f497dc3a2cac
(intptr,object[]) <0x0002b>

2. I have a database class that is not thread safe.

It has a method like this:

public void Connect()
{
        EnsureConfigured ();
                                                        
        if (IsConnected)
        {               
                _log.Info (Tag, "Connection already open.");
                return;
        }
                
        _log.Info (Tag, string.Format ("Opening connection to {0}...",
ConnectionString));
        _connection = new SqliteConnection (ConnectionString);
        _connection.Open ();
        _log.Info (Tag, "Connection opened successfully.");
}

The last two log lines (below) suggest it's getting called by two threads
at the same time. Eyeballing the code, I don't think it can happen. It
gets called synchronously in OnResume, and after it finishes, it may be
called on other threads. However, the logs would suggest it's being called
before the OnResume code actually completes.

This is the code that always runs before the stack-traceless exception.
I'll try turn this into a repro.


2011-12-18 22:12:55.718 I 23357/Database: Checking connection state...
2011-12-18 22:12:55.718 I 23357/Database: Not connected. Connecting now...
2011-12-18 22:12:55.718 I 23357/Database: Opening connection to Data
Source=/mnt/sdcard/xxxDictionary/essential_v12.db...
2011-12-18 22:12:56.068 I 23357/pthread: ## thread 23357 is creating
thread @external/sqlite/dist/sqlite3.c:22379
2011-12-18 22:12:56.068 I 23357/pthread: ## thread 23366 is created success
2011-12-18 22:12:56.328 I 23357/Database: Connection opened successfully.
2011-12-18 22:12:56.328 I 23357/Database: Connection opened successfully.

Steve


--------------

From:  Aaron Knabb <akn...@mobileepiphany.com>
Reply-To:  Discussions related to Mono for Android
<monodroid@lists.ximian.com>
Date:  Thu, 15 Dec 2011 16:34:07 -0700
To:  Discussions related to Mono for Android <monodroid@lists.ximian.com>
Subject:  Re: [mono-android] Thread Exceptions Without Stacktrace


We are still trying to create a test application that demonstrates this
problem, and we are burning a lot of man hours doing so. The only clue
we've come up with so far is that the crash is more likely when the "GC
cleanup summary" numbers get very high (over 200). In our test apps, we
can't get that number over ~10. No matter what we do, we can't seem to get
that number to go up in the test application.
We aren't absolutely sure that is the root of the problem, but it seems
the only real clue we've found so far. What's the best way to get those
cleanup numbers to climb?

It's starting to turn into a pretty desperate circumstance with this
issue. It's completely killing our application, and we've no way of
perusing a solution because of the complete lack of call stack or any
useful logging.

-Aaron


On Tue, Dec 13, 2011 at 3:00 PM, chris@Terrago <cdr...@terragotech.com>
wrote:

Same for me, 4.0.1 did not fix the issue. I have a sample application that
I
am hoping to expand to show the problem. If it does I'll let you know.

--
View this message in context:
http://mono-for-android.1047100.n5.nabble.com/Thread-Exceptions-Without-Sta
cktrace-tp5069711p5072922.html
Sent from the Mono for Android mailing list archive at Nabble.com.
_______________________________________________
Monodroid mailing list
Monodroid@lists.ximian.com

UNSUBSCRIBE INFORMATION:
http://lists.ximian.com/mailman/listinfo/monodroid









_______________________________________________
Monodroid mailing list
Monodroid@lists.ximian.com

UNSUBSCRIBE INFORMATION:
http://lists.ximian.com/mailman/listinfo/monodroid

Reply via email to