Update
It is fixed in Xcode 8.0
Environment
Xcode 7.3.1, iPhone SE, iOS 9.3.5
Problem
I bound C function to JavaScript function by JSObjectMakeFunctionWithCallback with JavaScriptCore framework.
If I put breakpoint in this C function,
Xcode debugger hangs when execution position comes here from JavaScript by JSEvaluateScript.
I want to know reason of issue.
I want to know approach to implement C function which works with breakpoint correctly and is callable from JavaScript environment.
I don't need idea using Objective-C API,
Because I want to share code with iOS and Android.
Condition
From my experiment, I got these conditions.
It does not happens in iOS Simulator.
It does not happens when JS function is calling from JSObjectCallAsFunction.
It happens when JS function is calling from JSEvaluateScript.
My opinions by looking call stack in Simulator running is
this issue is from JavaScriptCore's JIT/LLINT embedded assembly.
I guess that these assembly lacks something relates debugging mechanism.
So I worry that there is no solution in programmer on user side of JavaScriptCode.
Reproducible source code
I packaged small reproducible example in this repository.
https://github.com/omochi/jscore-debugger-hangup
steps
Clone this repository.
Open with Xcode.
Open test_main.c.
Put breakpoint at printf in TestNativeFunc and JSEvaluateScript in TestMain.
Run application.
It paused at printf.
Continue.
It paused at JSEvaluateScript.
Xcode hangs.
If you remove two breakpoints, it run correctly and print two func messages.
code
static JSValueRef TestNativeFunc(JSContextRef ctx,
JSObjectRef function,
JSObjectRef thisObject,
size_t argumentCount,
const JSValueRef arguments[],
JSValueRef* exception)
{
printf("func\n");
return JSValueMakeNull(ctx);
}
void TestMain() {
JSGlobalContextRef context = JSGlobalContextCreate(NULL);
JSObjectRef func = JSObjectMakeFunctionWithCallback(context, NULL, &TestNativeFunc);
JSValueProtect(context, func);
JSObjectCallAsFunction(context, func, NULL, 0, NULL, NULL);
JSObjectRef global_object = JSContextGetGlobalObject(context);
JSStringRef f_str = JSStringCreateWithUTF8CString("f");
JSObjectSetProperty(context, global_object, f_str, func, 0, NULL);
JSStringRef script = JSStringCreateWithUTF8CString("f();");
JSEvaluateScript(context, script, NULL, NULL, 1, NULL);
JSStringRelease(f_str);
JSValueUnprotect(context, func);
JSGlobalContextRelease(context);
}
This is a known bug in Xcode 7.3.1, and it should be fixed in Xcode 8.0. If you find that it isn't when you get a chance to upgrade to 8.0, please file a bug with http://bugreporter.apple.com.
Related
I'm aware that Kotlin/Native has very specific rules in regards to mutability of objects between threads.
However to my surprise, I've found that when running unit tests from commonMain (deployed to androidTestDebug), I am able to change mutable states on different threads. For example this works fine when changing the value in MyData:
data class MyData(var value : Int = 0)
suspend fun main() = coroutineScope {
val myData = MyData()
val newContext1 = newSingleThreadContext("contextOne")
val newContext2 = newSingleThreadContext("contextTwo")
launch (newContext1) {
myData.value = 1
}
launch (newContext2) {
myData.value = 2
}
}
However if I run this while targeting iOS, it crashes, giving me kotlin.native.concurrent.InvalidMutabilityException. This is what I would expect to happen on both platforms. I'm new to KMM, but why aren't concurrent mutability rules enforced when running commonMain code on JVM?
Also is there a way to force mutability rules on the JVM so that tests fail on Android just as they would on iOS? I think this would help ensure platform consistency.
No, it shouldn’t crash on Android.
Kotlin native creates Native code from Kotlin, that’s why there’s a need in it’s own concurrency model.
For android part this is plain kotlin code, so JVM concurrency model can be used, and as any other kotlin code that mutates a variable it shouldn’t crash.
I don’t think there’s a way to make it crash on Android.
In kotlin 1.6.0 this should be changed so this code is not gonna crash on both platforms
The problem
I'm trying to scroll on an Ionic App. I would like to scroll until an element is visible.
To test the procedure, I've written two sequential actions.
While testing just the first one is evaluated, the second one throws an exception Support for this gesture is not yet implemented.
How do I scroll, like a user would do, untill an element is visible if I cannot repeat actions?
Environment
Appium version 1.6.4-beta
Desktop OS/version used to run Appium: OSX Sierra
Real device or emulator/simulator: iPad Mini
Code To Reproduce Issue
TouchAction action = new TouchAction(this.driver);
Thread.sleep(5000);
action.press(150, 150).moveTo(0, 350).release().perform();
Thread.sleep(10000);
action.press(150, 150).moveTo(0, 350).release().perform();
The only possible, and horrible, solution that I've found is:
while( !element.isDisplayed() ){
TouchAction action = new TouchAction(this.driver);
action.press(150, 150).moveTo(0, 350).release().perform();
Thread.sleep(5000);
}
Hopefully someone can suggest a cleaner solution.
I am recompiling an application from Visual C++ 6.0 in Visual Studio 2015. It is using Mscomm as serial communication library. Everything gets compiled fine but when I run the program, I get "Attempted an Unsupported Operation" twice. Upon debugging I found out the culprit is the following snippet:
void CFFLSView::DoDataExchange(CDataExchange* pDX)
{
CFormView::DoDataExchange(pDX);
//{{AFX_DATA_MAP(CFFLSView)
DDX_Control(pDX, IDC_MSCOMM1, m_comm);
DDX_Control(pDX, IDC_MSCOMM2, m_comm2);
//}}AFX_DATA_MAP
}
This calls m_comm and m_comm2 to be open COM1 and COM2. I don't have the equipment connected to my computer now, and I will have to test the compiled software at site tomorrow. I suspect that because nothing is connected to COM1 and COM2, the program cannot open port and returns that error but I am not sure that is the case, getting in the site is very difficult and I only have one opportunity to go in and test the software there. I want to make sure that this error is only given because nothing is connected to COM1 and COM2 and not any other problem. I appreciate your comments and thoughts on this. If it helps, the DDX_Control function calls the following function in debug mode:
void CMSComm::SetPortOpen(BOOL bNewValue)
{
static BYTE parms[] =
VTS_BOOL;
InvokeHelper(0x14, DISPATCH_PROPERTYPUT, VT_EMPTY, NULL, parms,
bNewValue);
}
which is supposed to open the port.
XCode 7.2.1
iPad Retina iOS 9.2 Simulator
I have several breakpoints set in a particular class in an XCode project.
Everything I discuss below takes place in this one class file.
I set the breakpoints on -(int16_t)areaNbr by clicking in the gutter, and set no conditions or anything on them. I confirmed they existed as far as LLDB is concerned by running breakpoint list from the LLDB prompt.
The project scheme is set to build for debugging, not release.
I run the project in the simulator, and stop at a breakpoint in a different method than the one in question, at which time I want to go to the LLDB prompt and call po [self areaNbr] and step through areaNbr.
Please note, as this may be quite relevant, I have NO code in the project itself that calls
-(int16_t)areaNbr
Now, I CAN get this to stop at my breakpoints on -(int16_t)areaNbr if I add some code to the project that calls the method.
For example, if I add something like NSLog(#"... %d", [self areaNbr])
I know the issue has nothing to do with compiling away the method simply because nothing calls it, because if that were true, then my call to po [self areaNbr] wouldn't be spitting out the result to the debugger window as pictured below. So the method is being compiled, and certainly recognized as existing by the debugger for execution purposes... just not for stepping purposes.
FYI, [self area] is returning "Area01"
Calling breakpoint list in LLDB returns the following
By default, lldb does not stop at breakpoints in hand-called code. The majority of folks use expr & expr -O -- i.e. po to print values & objects and were annoyed if they stopped at breakpoints they had set for other purposes.
However, it is easy to control this behavior, just use:
(lldb) expr -i 0 -- [self areaNbr]
Then you will stop at your breakpoint.
In this example, I left out the -O which is the object printing part, since if you just want to call this method, you likely don't care about calling description on the result after the expression is evaluated.
You can see all the options for expression evaluation by doing:
(lldb) help expr
I have a really weird issue with cocos2d-x v3, the first 15 touches or so are not registered on my iOS device (tried iPad 2 and iPad air). As soon as a touch is finally registered, everything works fine (aka all touches after that trigger the onTouch functions).
The touch events work perfectly fine in the simulator.
Also, the same code works perfectly fin in my Windows and Android builds.
Has anyone had this happen, or maybe know what could be causing it?
I'm using the listener, and I debugged up to the spot where touchesBegan forwards the input events to the listener, but even there the events don't come in until after the 15th tap or so.
It's really weird... And I figured I'd give it a shot here, as someone might have encountered this as well, before I start stripping code to as clean as possible, and then try to work my way back from there...
Kind regards,
Michaël
EDIT: As requested, here is some code. The desired behaviour is that it works in iOS devices like it should: First touch triggers the onTouchBegan.
I didn't add it as it didn't think it would matter, since the code works fine for Android.
But I appreciate that you'd like to see it, just in case I might have missed something
GameLayer is a Cocos2d::Layer.
void GameLayer::onEnter()
{
cocos2d::CCLayer::onEnter();
// Register Touch Event
auto pEventDispatcher = cocos2d::Director::getInstance()->getEventDispatcher();
if (pEventDispatcher)
{
// Touch listener
auto pTouchListener = cocos2d::EventListenerTouchOneByOne::create();
if (pTouchListener)
{
pTouchListener->setSwallowTouches( true );
pTouchListener->onTouchBegan = CC_CALLBACK_2( GameLayer::onTouchBegan, this );
pTouchListener->onTouchMoved = CC_CALLBACK_2( GameLayer::onTouchMoved, this );
pTouchListener->onTouchEnded = CC_CALLBACK_2( GameLayer::onTouchEnded, this );
pTouchListener->onTouchCancelled = CC_CALLBACK_2( GameLayer::onTouchCancelled, this );
pEventDispatcher->addEventListenerWithSceneGraphPriority( pTouchListener, this );
}
}
}
bool GameLayer::onTouchBegan( cocos2d::Touch* pTouch, cocos2d::Event* /*pEvent*/ )
{
// Breakpoint here triggers fine on first touch for Android/Windows/iOS Simulator,
// but not on iOS device (iPad/iPhone)
bool breakHere = true;
<<snip actual code>>
}
EDIT:
The problem was an std::ofstream trying to open() on the iOS device (most likely in a folder it didn't have access to).
I have lots of layers in my game and I don't do it like you do. In your code the need to get the EventDispatcher locally and create the touch listener like how you are seems odd to me. I've never seen it down that way in so many steps.
I do:
auto listener = cocos2d::EventListenerTouchOneByOne::create();
listener->setSwallowTouches(true);
listener->onTouchBegan = [&](cocos2d::Touch* touch, cocos2d::Event* event)
{
return true;
};
listener->onTouchEnded = [=](cocos2d::Touch* touch, cocos2d::Event* event)
{
// ... do something
};
cocos2d::Director::getInstance()->getEventDispatcher()->addEventListenerWithFixedPriority(listener, 31);
I got it fixed.
The problem was seemingly totally unrelated, I was trying to open an std::ofstream file (my log file), most likely in a folder it didn't have (any and/or write) access to.
Which is not required, nor wanted on the iOS device.
Once I added IOS to the exclusion list (just like Android and some more targets) everything started to work perfect.
I do not know what goes wrong exactly, and why it does start working after a few touch inputs, but I'm guess it was waiting or retrying something in the background.
I found the issue while debugging another one :)
Hopefully this helps anyone else who might stumble onto the same or a related issue.
Kind regards,
Michaël