[Mono-bugs] [Bug 685215] Odd SurfaceView Touch Exception

bugzilla_noreply at novell.com bugzilla_noreply at novell.com
Thu Apr 14 22:15:46 EDT 2011


https://bugzilla.novell.com/show_bug.cgi?id=685215

https://bugzilla.novell.com/show_bug.cgi?id=685215#c2


Jonathan Pryor <jpryor at novell.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jpryor at novell.com

--- Comment #2 from Jonathan Pryor <jpryor at novell.com> 2011-04-15 02:15:45 UTC ---
I really must remember that "bizarro NullReferenceExceptions" usually mean
"GREF overflow".

Case in point, run in the emulator (which has a GREF limit of 2000), and we
get:


    D/dalvikvm(  602): GREF has increased to 401
    ...
    W/dalvikvm(  602): JNI global reference table summary (2001 entries):
    W/dalvikvm(  602):    51 of Ljava/lang/Class; 164B (41 unique)
    ...
    W/dalvikvm(  602):  1553 of Landroid/graphics/Point; 20B (1553 unique)

So the odd behavior is due to GREF overflow because you're creating an
Android.Graphics.Point object for every touch interaction, and these don't get
collected fast enough.

There are three theoretical solutions, only one of which works for now:

1. Don't create so many Android.Graphics.Point instances. The simple way to do
this is to change DrawingView.cs from:

    m_pt = new Point((int)e.GetX(), (int)e.GetY());

to:

    m_pt.Set((int)e.GetX(), (int)e.GetY());

Alternatively, use System.Drawing.Point (or some other type that doesn't have a
Java-side type that needs to be constructed). Either of these removes the GREF
overflow problem, and the app works as expected.

2. Dispose m_pt before creating a new instance. Unfortunately this breaks for
me, largely due to the multithreaded nature of the app as the RenderThread will
access the point between disposal and new Point creation. This could probably
work if locking were introduced.

Frankly, locking should probably be done even with (1), as you're sharing data
between threads...

3. Call GC.Collect(0) in RenderThread.Run() at the end of the 'while' loop.
Unfortunately this breaks in different ways...

Part of the problem is that the GREF limit is so low on the emulator that
Mono's GC doesn't really feel the need to collect before the global refs are
exhausted...

-- 
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.


More information about the mono-bugs mailing list