I'm having problem to find the cause of random crashes in my app. The crashes only occurs when I build in release mode and run on a device like iPhone or iPad. Running in debug on simulator no crashes occurs. My guess is that the problem has something to do with these two lines in the crash log,
6 UIKit 0x34a193d0 -[UISearchDisplayController _destroyManagedTableView] + 68
7 UIKit 0x34a2195a -[UISearchDisplayController dealloc] + 94
I've uploaded the source code of my UITableViewController and the full crash log here, https://gist.github.com/Nordis/6128735
All help to track the cause of the crashes is much appreciated!
Update
I've now crated a bug report, I looked and the thread Rolf suggested in the comments. So I downloaded the test case, applied the fix. But still exactly the same crash and the stack trace is very similar to what mine looks like.
https://bugzilla.xamarin.com/show_bug.cgi?id=13703
The solution provided by Rolf at Xamarin was fairly simple, all I had to do was to move the code from Dispose() to ViewDidDisappear() in my UITableViewController,
public override void ViewDidDisappear (bool animated)
{
searchController.SearchResultsSource = null;
searchController.Delegate = null;
base.ViewDidDisappear (animated);
}
Related
I have eclipse 3.7 indigo; I installed gwt plugin and its designer; The problem is (time after time) when I add new widget X to composite the
palette (keeps widget selected)
components (doesn't show the new widget in the tree)
properties (doesn't show the new widget properties)
...so I cannot select another widget unless I resize the whole eclipse application to force its GUI repaint :(
It seems like palette and other managers don't get report "widget was added from windowbuilder" or similar :(
Moreover, I cannot edit widget's text if I have input method as "System" which is the default on btw so the only one input method which works is "X Input Method" but anyways it doesn't solve the mentioned focus regain problem;
That makes eclipse indigo really hard to use; So my question is... how to fix that?
p.s.
eclipse 3.7 (indigo)
gwt plugin - https://dl.google.com/eclipse/plugin/archive/3.6.0/3.7
gwt designer - http://dl.google.com/eclipse/inst/d2gwt/latest/3.7
gwt sdk 2.2
jdk 1.7
jre 1.7
OS Linux x64
Thanks
I had to do my own research concerning the issue; I noticed there is some kind of "jobs order conflict" or similar with the default constructor based code style as :
public class MyTestUI extends Composite {
private FlowPanel flowPanel;
public MyTestUI() {
flowPanel = new FlowPanel();
initWidget(flowPanel);
}
}
...so, as a workaround, I had to play with code generator as;
window -> preferences -> windowbuilder -> gwt
(combobox) method name for new statements : initComponents
variable generation : field
statement generation : flat
just to avoid having in-constructor init as a result I have code generated as :
public class MyTestUI extends Composite {
private FlowPanel flowPanel;
public MyTestUI() {
initComponents();
}
private void initComponents() {
flowPanel = new FlowPanel();
initWidget(flowPanel);
}
}
...btw there is a problem with focus regain if input method is "System" and initComponents() method generated first time; so before starting adding widgets I had to select "X input method" to avoid synch-ed jobs; So "X input method" needs to be the default one, as I can get it :)
EDIT :
The effect I faced very looks like bug 388170; So I tried to modify eclipse.ini argument as
-Djava.awt.headless=true
It seems like the headless helps a bit but anyways eclipse sometimes does hang when using windowbuilder especially DnD :P
Anyways I want to point I faced the mentioned issue first time cause similar windows x32 eclipse indigo version works pretty fine with gwt;
p.s.
The solution is not final (the hang problem still occurs on DnD evens) and I am still looking for a more optimal one; So do comment if you have some helpful tips or ideas;
I've started developing a Leap Motion app and this is driving me nuts. Whenever I exit the application, the code responsible for cleaning up the Leap Motion controller hangs on me.
public void CleanUp()
{
_lmController.RemoveListener(_lmListener);
_lmController.Dispose();
}
I create both the controller and the listener in my Main Thread in a presenter class:
public MainViewPresenter(IMainView view, IApplicationController applicationController)
{
_view = view;
_applicationController = applicationController;
_view.Presenter = this;
_lmListener.Frame += _lmListener_Frame;
_lmController.AddListener(_lmListener);
}
The Cleanup() method is also a presenter method called on the view's FormClosing event. The weird thing is that it works perfectly fine when I call it from _listener_Frame(), which runs on a separate, Leap Motion-created no-name thread!
_lmListener_Frame() itself resides in the presenter. It just gets data from _lmController, creates a view model and sends it to the view, which in turn uses Invoke to update the display data.
I've tried calling the CleanUp stuff in Dispose() (both the view and the presenter (not redundant of course)) and that also doesn't work.
I admit that I'm not an expert in threading, but I can't see how there's any conflict going on here, and why RemoveListener works from controller thread, but not from the Main Thread, where the listener was actually added. Any help is appreciated!
SOLUTION
Completely by chance, I've found the solution today! It turns out that the "Invoke" call was the culprit, and it should've been BeginInvoke all this time, although this isn't mentioned anywhere in the WinForms setup guide. I'm guessing it was causing a deadlock with the controller thread and after the first GUI update it was bound to crash.
In a Windows forms Application, the following worked for me:
protected override void Dispose(bool disposing)
{
try
{
if (disposing)
{
if (components != null)
{
components.Dispose();
}
this.controller.RemoveListener(this.listener);
this.controller.Dispose();
}
}
finally
{
base.Dispose(disposing);
}
}
}
I wrote it awhile ago, though, and don't remember why it needed to be more complicated than what you tried. (Full example here: https://developer.leapmotion.com/documentation/csharp/devguide/Project_Setup_WinForms.html)
after almost 2 week trying to solve this strange problem, I give up!
Basically a get the java.lang.VerifyError every time I try to run my app
only in devices with Android 2.x.x. From 3.x.x all are going well.
In the project I'm using this two external library:
Action Bar Sherlock - http://actionbarsherlock.com/ - updated at the v4.4.0
Sliding Menu - https://github.com/jfeinstein10/SlidingMenu
This is what the LogCat return every time:
FATAL EXCEPTION: main
java.lang.VerifyError: me.xxx.menu.MenuListFragment
at me.xxx.menu.BaseSlidingMenuActivity.onCreate(BaseSlidingMenuActivity.java:46)
at me.xxx.menu.SlidingMenuCustomAnimation.onCreate(SlidingMenuCustomAnimation.java:28)
at me.xxx.XXXActivity.onCreate(XXXActivity.java:130)
at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1047)
at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:1611)
at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:1663)
at android.app.ActivityThread.access$1500(ActivityThread.java:117)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:931)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loop(Looper.java:130)
at android.app.ActivityThread.main(ActivityThread.java:3683)
at java.lang.reflect.Method.invokeNative(Native Method)
at java.lang.reflect.Method.invoke(Method.java:507)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:839)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:597)
at dalvik.system.NativeStart.main(Native Method)
and this is how the BaseSlidingMenuActivity.java looks like around the line 46:
#Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setTitle(mTitleRes);
// set the Behind View
setBehindContentView(R.layout.frame_content);
if (savedInstanceState == null) {
FragmentTransaction t = this.getSupportFragmentManager().beginTransaction();
mFrag = new MenuListFragment(); <--- ERROR HERE!
t.replace(R.id.frame_content, mFrag);
t.commit();
} else {
mFrag =(SherlockListFragment)this.getSupportFragmentManager()
.findFragmentById(R.id.frame_content);
}
...
...
}
Where MenuListFragment() is a SlidingFragmentActivity that extend a SherlockFragmentActivity
and implements SlidingActivityBase.
Of course I googled the problem, and seems that a lot of people are getting this
issue with the last version of the Android SDK tool, i.e. v22.x.x , in fact a have
the v22.6.3.
Some people resolved the VerifyError just putting the Check on the "Private Libraries"
box, inside "BuildPath->Configure BuildPath->Order and Export" menù, as explained
in other conversation about the VerifyError, but for me doesn't work, even because the "Private Libraries" was already checked. So the libraries/imports situation seems to be ok!
Hoping that someone already fund a solution for that! I'm getting crazy! :D
Thank you!
I finally found the solution!
Recap! Basically the are two main reason in which you can get this error:
(In my case) I was getting the VerifyError all the time that I tried to run my app on devices with API Level under 10 , because I was trying to catch an SQLiteDatabaseLockedException that are supported from the Android API Level 11. So to solve it check that every Exception or possible method (i.e. String.isEmpty() is supported from API Level 9) is supported form your minimum API Level.
While I was searching for a solution I found a lot of people that got the VerifyError because there was some problem with Libraries Imports, as explained in this post: http://commonsware.com/blog/2013/05/23/do-not-manually-modify-eclipse-build-path-except-now-r22.html
Hope that will help someone beyond me! :D
Bye Bye! Caterpillar.
To stop my application from flickering, I tried to activate DoubleBuffering for all of my controls and subcontrols.
To achieve this, I added the follwoing codesnippet in my mainform:
protected override CreateParams CreateParams
{
get
{
CreateParams cp = base.CreateParams;
cp.ExStyle |= 0x02000000; //WS_EX_COMPOS
return cp;
}
}
The problem is, that with WindowsXP the cpu-load becomes almost 100% and keeps up. No problem on Windows7.
It looks for me, as it is the very same problem as in this question. Is there a "easy" solution in C#? Or asked in a different way -> What usually causes this behaviour? So I can find out the problem in my application.
UPDATE: Maybe some more information to help you folks help me. What I am trying to do is showing a semi-transparent form ontop of the mainform with an progressbar. This "progressBarForm" is in a second thread to have this progressbar running. On Win7 everything works fine, as mentioned above with WinXP (.net4, activated desktoptheme) there is 100% cpu-load after the progressbar was shown once - also the acutal payload-function needs much longer to complete - maybe because of the high-cpu-load done by the progressbar. Where and what should I check again? Some ideas?
Btw.: I don't think the thread is a problem, as when I show the form in the mainthread and don't refresh anything, the result (high cpu-load) is the same...
Hi noticed some code in our application when I first started Java programming. I had noticed it created a dialog from a separate thread, but never batted an eye lid as it 'seemed to work'. I then wrapped this method up through my code to display dialogs.
This is as follows:
public class DialogModalVisibleThread
extends Thread {
private JDialog jDialog;
public DialogModalVisibleThread(JDialog dialog, String dialogName) {
this.setName("Set " + dialogName + " Visable");
jDialog = dialog;
}
#Override
public void run() {
jDialog.setVisible(true);
jDialog.requestFocus();
}
}
Usage:
WarnUserDifferenceDialog dialog = new WarnUserDifferenceDialog( _tableDifferenceCache.size() );
DialogModalVisibleThread dmvt = new DialogModalVisibleThread( dialog, "Warn User About Report Diffs");
dmvt.start();
Now, as far as I am now aware, you should never create or modify swing components from a separate thread. All updates must be carried out on the Event Dispatch Thread. Surely this applies to the above code?
EDT on WikiPedia
However, the above code has worked.
But lately, there have been countless repaint issues. For example, click on a JButton which then calls DialogModalVisibleThread to display a dialog. It caused buttons alongside the clicked button not to redraw properly.
The repaint problem is more frequent on my machine and not the other developers machine. The other developer has a laptop with his desktop extended onto a 21" monitor - the monitor being his main display. He is running Windows 7 with Java version 1.6.0_27.
I am running on a laptop with Windows 7 and Java version 1.6.0_24. I have 2 additional monitors with my desktop extended onto both.
In the meantime I am going to upgrade to Java 1.6 update 27.
I wondered if the above code could cause repaint problems or are there any other people out there with related paint issues?
Are there any easy ways to diagnose these problems?
Thanks
So, you're breaking a rule, having problems, and wondering if these problems could be cause by the fact that you broke the rule. The answer is Yes. Respect the rules!
To detect the violations, you might be interested by the following page: http://weblogs.java.net/blog/2006/02/16/debugging-swing-final-summary
The easiest way to check if your problems are being caused by breaking the rules is to fix them (You should fix them anyway :-)
Just use SwingWorker.invokeLater() from the thread you want to update to UI from to easily adhere to Swing's contract. Something like this should do the trick:
#Override
public void run() {
SwingUtilities.invokeLater(new Runnable() {
jDialog.setVisible(true);
jDialog.requestFocus();
}
});
}
EDIT: You should make the 'jDialog' variable final for this to work.