Titanium JIRA Archive
Titanium SDK/CLI (TIMOB)

[TIMOB-26050] Corrupted http response after updating to iOS 11.3

GitHub Issuen/a
TypeBug
Priorityn/a
StatusOpen
ResolutionUnresolved
Affected Version/sn/a
Fix Version/sn/a
Componentsn/a
Labelsn/a
ReporterAlberto Marcone
AssigneeShak Hossain
Created2018-05-08T12:44:22.000+0000
Updated2018-10-02T15:51:24.000+0000

Description

For the past few days, some of our customers have been reporting errors in the response from our server, apparently the XML that the client receives from the server is corrupted, meaning that the xml is missing hundreds of characters at the beginning of the response (the server sends it correctly). In a case the problem went away after initializing the device, reinstalling the app is not enough. Did anyone else report an error like this? I know that we're not using the latest sdk but we've made few customizations that haven't ported to the latest one.

Comments

  1. Hans Knöchel 2018-05-08

    Hey there! We have updated the Ti.Network.HTTPClient to NSURLSession in Titanium SDK 7.0.0, but haven't received any reports of the described issue before. Also, if it is only happening on iOS 11.3+, it might be an issue in the underlaying native API. In any case, we could need to get a (simple, app.js suitable) test-case, your current Titanium SDK version (even when modified) and if possible a trace-log + corruped file.
  2. Alberto Marcone 2018-05-09

    I tried to update to 7.x but the app, stable until now, keeps crashing for no apparent reason, in random places (parsing xml, http responses, etc). I will try to dig a little deeper.
  3. Hans Knöchel 2018-05-09

    Maybe related to the <use-js-core-framework> flag which is enabled by default in 7.x? You could try to manually disable it with 
       <use-js-core-framework>false</use-js-core-framework>
    and compare the results. But if that works, I'd love to get the stack traces of these crashes to fix that as well.
  4. Alberto Marcone 2018-05-09

    well, from the first few tests that I made, it looks like it's not crashing. I didn't have any symbolicated stack trace. I have a HockeyApp stack trace that looks like this: {quote} Exception Codes: SEGV_MAPERR at 0xffffffffffffffe8 Crashed Thread: 6 Thread 0: 0 libsystem_kernel.dylib 0x000000011a3d834a 0x11a3c6000 + 74570 1 CoreFoundation 0x0000000118df6c85 0x118d76000 + 527493 2 CoreFoundation 0x0000000118df61c2 0x118d76000 + 524738 3 CoreFoundation 0x0000000118df5889 0x118d76000 + 522377 4 GraphicsServices 0x000000011b8ae9c6 0x11b8a2000 + 51654 5 UIKit 0x00000001148ef5d6 0x1148c5000 + 173526 6 xxx 0x000000010d3f03c4 0x10d3ec000 + 17348 7 libdyld.dylib 0x0000000119fd0d81 0x119fd0000 + 3457 Thread 1: 0 libsystem_kernel.dylib 0x000000011a3dfbf2 0x11a3c6000 + 105458 1 PSPDFKit 0x0000000113d3e687 0x113b61000 + 1955463 2 PSPDFKit 0x0000000113d3caf7 0x113b61000 + 1948407 3 PSPDFKit 0x0000000114007551 0x113b61000 + 4875601 4 libsystem_pthread.dylib 0x000000011a41493b 0x11a411000 + 14651 5 libsystem_pthread.dylib 0x000000011a414887 0x11a411000 + 14471 6 libsystem_pthread.dylib 0x000000011a41408d 0x11a411000 + 12429 Thread 2: 0 libsystem_kernel.dylib 0x000000011a3e044e 0x11a3c6000 + 107598 1 libsystem_pthread.dylib 0x000000011a41407d 0x11a411000 + 12413 Thread 3: 0 libsystem_kernel.dylib 0x000000011a3e044e 0x11a3c6000 + 107598 1 libsystem_pthread.dylib 0x000000011a41407d 0x11a411000 + 12413 2 ??? 0x0000000110f0dd68 0x0 + 0 Thread 4: 0 libsystem_kernel.dylib 0x000000011a3e044e 0x11a3c6000 + 107598 1 libsystem_pthread.dylib 0x000000011a41407d 0x11a411000 + 12413 ... {quote}
  5. Hans Knöchel 2018-05-14

    [~a.marcone] So by disabling the flag it does not crash? Does it have an influence if you do not include PSPDFKit while having it enabled?
  6. Alberto Marcone 2018-05-16

    the symbolicated stack traces are showing an exception in *invokeCallbackForKey* and *objectForTiString* Thread 8 Crashed: 0 JavaScriptCore 0x0000000188729598 JSC::JSObject::get(JSC::ExecState*, JSC::PropertyName) const + 2000 1 JavaScriptCore 0x000000018872bc0c JSObjectGetProperty + 96 *2 iMeetingRoom 0x000000010073d688 -[KrollObject objectForTiString:context:] (KrollObject.m:1203)* 3 iMeetingRoom 0x000000010073a484 KrollGetProperty (KrollObject.m:187) 4 JavaScriptCore 0x000000018884f90c JSC::JSCallbackObject::getOwnPropertySlot(JSC::JSObject*, JSC::ExecState*, JSC::PropertyName, JSC::PropertySlot&) + 356 5 JavaScriptCore 0x00000001887209ec llint_slow_path_get_by_id + 4556 6 JavaScriptCore 0x0000000188826300 llint_entry + 11452 7 JavaScriptCore 0x000000018882a79c llint_entry + 29016 8 JavaScriptCore 0x000000018882a79c llint_entry + 29016 9 JavaScriptCore 0x000000018882a79c llint_entry + 29016 10 JavaScriptCore 0x000000018882a79c llint_entry + 29016 11 JavaScriptCore 0x0000000188823470 vmEntryToJavaScript + 268 12 JavaScriptCore 0x0000000188dd4a74 JSC::JITCode::execute(JSC::VM*, JSC::ProtoCallFrame*) + 180 13 JavaScriptCore 0x000000018872c40c JSC::Interpreter::executeCall(JSC::ExecState*, JSC::JSObject*, JSC::CallType, JSC::CallData const&, JSC::JSValue, JSC::ArgList const&) + 460 14 JavaScriptCore 0x0000000188ef7540 JSC::profiledCall(JSC::ExecState*, JSC::ProfilingReason, JSC::JSValue, JSC::CallType, JSC::CallData const&, JSC::JSValue, JSC::ArgList const&) + 164 15 JavaScriptCore 0x000000018872c11c JSObjectCallAsFunction + 388 *16 iMeetingRoom 0x000000010073d0d8 -[KrollObject invokeCallbackForKey:withObject:thisObject:onDone:] (KrollObject.m:1103)* 17 CoreFoundation 0x0000000181b8e580 __invoking___ + 140 18 CoreFoundation 0x0000000181a6d748 -[NSInvocation invoke] + 280 19 CoreFoundation 0x0000000181a7256c -[NSInvocation invokeWithTarget:] + 56 20 Foundation 0x00000001824efcac -[__NSOperationInternal _start:] + 844 21 iMeetingRoom 0x0000000100736000 -[KrollContext invoke:] (KrollContext.m:985) 22 iMeetingRoom 0x0000000100736d50 -[KrollContext main] (KrollContext.m:1354) 23 Foundation 0x00000001825d1efc __NSThread__start__ + 1036 24 libsystem_pthread.dylib 0x00000001817ad220 _pthread_body + 268 25 libsystem_pthread.dylib 0x00000001817ad110 _pthread_start + 288 26 libsystem_pthread.dylib 0x00000001817abb10 thread_start + 0 how can I debug this?
  7. Alberto Marcone 2018-05-17

    I'm experiencing new crashes, this looks like it's coming from TiSDK 7.1.0 5 iMeetingRoom 0x0000000102ad0a60 -[KrollObject noteObject:forTiString:context:] (KrollObject.m:1175) 6 iMeetingRoom 0x0000000102acdbbc KrollGetProperty (KrollObject.m:218) 7 JavaScriptCore 0x000000018884f90c JSC::JSCallbackObject::*getOwnPropertySlot*(JSC::JSObject*, JSC::ExecState*, JSC::PropertyName, JSC::PropertySlot&) + 356 Is it something to do with setting properties?
  8. Hans Knöchel 2018-05-17

    Hey [~a.marcone]! Something is borked there. We didn't see that crashes anywhere else so far. Can you send me (via mail, I'll get in touch with you) - tiapp.xml - app.js reproducing the case (if possible) - full crash log and trace log
  9. Alberto Marcone 2018-05-17

    I sent you the crash logs and the tiapp.xml . Unfortunately the crashes happen in different places and I can't put a pin on it. One crash happened when I was logging out the app, the operations involved are: - cleaning a singleton containing the current logged user (setting it to null) - closing dialog and windows, back to the login page this wasn't crashing until I switched from 6.x to 7.x
  10. Alberto Marcone 2018-05-22

    any updates on this? we're stuck with TiSDK and we have to migrate because some modules require it
  11. Hans Knöchel 2018-05-22

    Hey [~a.marcone]! Unfortunately you seem to be the only person having this issue right now. To be sure, try to disable both default values: 
        	<property name="run-on-main-thread" type="bool">true</property>
    	<ios>
                <use-js-core-framework>false</use-js-core-framework>
            </ios>
  12. Alberto Marcone 2018-05-24

    I tried multiple combinations of the values, it doesn't really make any difference. Can I get a little more info about the stacktrace I sent you? When does that usually happens? so that I can try to avoid it?
  13. Hans Knöchel 2018-05-24

    Can you attach your tiapp.xml (nulled) to see if they are in the correct sub-tree of XML? And if you see issues in both 6.3.0 and 7.x, it would be good to have a list of errors per version, so we might be able to track it down this way. In any case, some kind of sample app would be required, otherwise we just can troubleshoot.
  14. Alberto Marcone 2018-10-02

    we eventually solved this problem by wiping our client's tablet and after that everything seemed to work. It must've been something corrupted on their iOS. Now we're facing new issues with http calls that are almost impossible to reproduce (random race conditions). We're using still an app developed in commonJS, how could we debug it? is there any good way on doing it besides console.log() and breakpoints? hundreds of lines and we don't know where to look at. We use HockeyApp but it's useless because the stack traces are not readable.

JSON Source