Using Google Cast Remote Display API in an iOS game (NOT unity) and I see this in my crash logs (haven't been able to reproduce it on my end)
0x1002162b4 media::cast::AdaptiveCongestionControl::EstimatedAckTime(unsigned int, double) + 4296794804
0x1002163c8 media::cast::AdaptiveCongestionControl::EstimatedSendingTime(unsigned int, double) + 4296795080
This is in a crash:
com.google.cast.io EXC_BAD_ACCESS KERN_INVALID_ADDRESS 0x0000000000000008
Any ideas? It does not seem to happen to a lot of users so far.
Based from this forum, maybe it is due to GCKDeviceManager being deallocated during postNotificationName:object:userInfo:. Try to swizzle into NSNotificationCenter, and see that the postNotificationName dies, and that GCKDeviceManager was trying to remove its own subscriptions.
Also found this thread which states that:
"Unless indicated otherwise, the caller should not release the delegating GCKDeviceManager object from within a delegate method." I found where the rule was not being adhered to. A change to delay setting our reference to the GCKDeviceManager makes the crash go away.
Hope this helps!
Related
I have a table with some data that I want to be able to edit through the QTableWidget. Upon trying to connect the currentItemChanged signal:
self.QTableWidget.currentItemChanged(QTableWidgetItem,QTableWidgetItem).connect(self.editCell)
I get the following error:
'TypeError: native Qt signal is not callable'
I went looking in to the QtDesigner, where you can connect signals. I made a QTableWidget, and connected it to a label so that changing the currentItem hid the label.
In the signal connecting dialog the currentItemChanged signal was written thus:
currentItemChanged(QTableWidgetItem*,QTableWidgetItem*)
I don't know what the * means, but I assume it's important.
Am I using the wrong signal or is my syntax wrong somehow? In short, I want there a signal to be emitted upon changing any particular item/cell(I'm not sure what the distinction is)
____________________EDIT_________________________
EDIT: In the QTableWidgetItem class documentation I also found that it has functions column() and row().
I tried adding them like this:
self.QTableWidget.currentItemChanged(QTableWidgetItem.column(QTableWidgetItem.column()),QTableWidgetItem.row()).connect(self.editCell)
But got the error:
TypeError: descriptor 'column' requires a 'PySide.QtGui.QTableWidgetItem' object but received a 'Shiboken.ObjectType
This bit is concerning:
self.QTableWidget
If your table is literally called "QTableWidget" there may be confusion later on. Specifically, the error you are getting makes it look like you are calling QTableWidget.currentItemChanged.
Also, its worth reviewing the PyQT documentation on "new-style signals", specifically on dealing with overloads to understand how it all works. Fortunately however, QTableWidget.currentItemChanged isn't overloaded so, the code you should be using should just be:
self.yourTable.currentItemChanged.connect(self.editCell)
Regarding your later edits, in this code:
currentItemChanged(QTableWidgetItem*,QTableWidgetItem*)
The QTableWidgetItems that are being parsed are arguments that are given to the signal. You can't change them, as they are definined in the method that defines the slot, and passed when the signal is fired. From the documentation linked above:
void currentItemChanged (QTableWidgetItem *,QTableWidgetItem *)
This signal is emitted whenever the current item changes. The previous item is the item that previously had the focus, current is the new current item.
Occasionally the UnhandledException handler in my app is raised due to an unhandled XAML exception.
The UnhandledExceptionEventArgs contains the message
E_RUNTIME_SETVALUE
and an inner-exception of type ArgumentException
Value does not fall within the expected range.
There is nothing in the call stack other than InitialiseComponent() which I can step into/ over without any exception being thrown.
Any ideas on how to debug further or any experience with E_RUNTIME_SETVALUE issues?
I do remember I had to once add basically no-op value converters to some XAML so I could see what was going on and trace the error. That might help in this case as well.
Also try to turn on mixed-mode debugging to see if more data comes from the native stack.
I had this in UWP and it was because I was using OnIdiom
<OnIdiom x:Key="MyFontSize" x:TypeArguments="x:Double" Tablet="28" Phone="16">
</OnIdiom>
I didn't have desktop included in one of the values and I was running my app on my desktop.
I notice Debug.Assert does not trigger in Metro apps, however, if the project is a traditional one like Console or WinForm, it does trigger. And yes, I am in Debug mode.
Is it a setting not properly set in Visual Studio (11 Beta)? Or Debug.Assert is intended to be disabled in metro apps?
I know many exceptions are swallowed during the execution of Metro apps, but Debug.Assert is so handy that I can't think of a reason why it should be disabled.
Seems like a bug. I would roll out my own assert method. Something like:
[Conditional("DEBUG")]
public static void Assert(bool condition)
{
if (!condition)
System.Diagnostics.Debugger.Break();
}
It does trigger, look in the Output window. It just doesn't automatically prompt you to ask if you want a debugger break and thus just keeps motoring.
The DefaultTraceListener.AssertUIEnabled property is false. That's an implementation problem, can't display a message box on top of Metro UI. Which does actually work but the monitor switches to the desktop, pretty undesirable when you would have liked to click No. Hard to solve and no doubt on the todo list. You can't easily get to the property to set it to true, it is inaccessible from the metadata. Filip's workaround sounds half-decent.
There is the same problem with F# in WinRT, in VS2013. The assert statement, which is an alias for System.Diagnostics.Debug.Assert, does not raise an exception, so unless you are watching the Output window then your assertions can fail without being noticed. Even if you are watching, it is hard to find the spot where the assertion was raised.
I followed Filip's suggestion and wrote a short utility, as follows:
namespace MyProj.Infrastructure
module Diagnostics =
let Assert condition = if not condition then
System.Diagnostics.Debugger.Break()
I chose Debugger.Break over raising an exception because it stops the debugger at the place the assertion fails. However, raising an exception is an acceptable alternative.
I didn't have any suitable global projects or modules already in my solution, so I had to create them just for this, which was quite annoying.
I've looked around SO for similar answers, but my issue seems a litte different.
I have a UITableView that is tied to a NSFetchResultsController. The goal is to pull up some data, add a couple rows into the Context, and the table is automatically updated. Simple, right?
init -> empty table -> performFetch -> create some objects in the Context -> delegate sees this and updates my table.
I'm using the boilerplate NSFetchResultsController for noticing when the current context has been modified.
When I run this with a clean Simulator/iOS platform, the NSFetchController successfully recognizes that data in the Context has been updated. But if I run the app a second time, I get the following error:
CoreData: error: Serious application error. Exception was caught during Core Data change
processing. This is usually a bug within an observer of
NSManagedObjectContextObjectsDidChangeNotification. *** -[__NSArrayI objectAtIndex:]:
index 40 beyond bounds for empty array with userInfo (null)
The crash occurs on calling [self.tableView beginUpdates];
In my debugging I can see that '[fetchedResultsController fetchedObjects]' is completely empty and I think thats the problem - shouldn't this be updating with my test data since I modified the context? I'm using the Apple Recipe and CoreDataBooks examples as reference.
I think this is because you Data Modle in class just not fit the entity in you .xcdatamodeld file.
I have an OpenSL ES function call that causes no problems in one application, but causes a problem in another application, both run on the same device.
The line is:
result = slCreateEngine(&engineObject, 0, NULL, 0, NULL, NULL);
Where result is of the type SLresult, engineObject is of the type SLObjectItf
The error I seem to get is:
05-19 11:56:27.007: ERROR/libOpenSLES(1425): slCreateEngine while another engine 0x299fa0 is active
It seems this is not logged from my code, but maybe it is caused by it? So what could cause this line to produce an error in one app, but not in the other?
As it happens to be, it was partly Android's Activity life-cycle which caused the error, but mostly my own fault. It was caused by the onCreate() and onResume() methods Android provides for an Activity. I never thought of the fact that onResume() also get's called when an Activity is started. Because of this, I never realized that I had a 2nd call to the slCreateEngine function.....
According to the docs "OpenSL ES for Android supports a single engine per application". I had a quick check of the source for OpenSL an I can see this is enforced by a global storing the current active engine.
So if you want to call slCreateEngine, you must make sure all other engines have been destroyed first. This includes the possibility of any 3rd party code you are linking in too (incase you are linking in something else that is creating an OpenSL engine object before you do).