[TIMOB-7795] Android: RSS Reader Sample: lock-up on use with nativeview is null warning
GitHub Issue | n/a |
Type | Bug |
Priority | High |
Status | Closed |
Resolution | Cannot Reproduce |
Resolution Date | 2012-03-23T12:12:01.000+0000 |
Affected Version/s | Release 1.8.1, Release 1.8.2 |
Fix Version/s | n/a |
Components | Android |
Labels | qe-and021312, qe-and031912 |
Reporter | Dustin Hyde |
Assignee | Hieu Pham |
Created | 2012-02-23T16:29:50.000+0000 |
Updated | 2017-03-10T00:06:45.000+0000 |
Description
When the studio sample RSS Reader project is run and used, the app will eventually crash.
Nativeview is null is logged to the console. A stack trace is written to device. A timeout error is generated. The OS requests to force close the app.
Log attached, stack trace attached.
Occurs in 1.8.1 and 1.8.2 in V8 and Rhino.
Steps to Reproduce:
1. Import Samples > RSS Reader from the dashboard.
2. Run app.
3. Click different RSS feed rows, then press 'back'. Cycle.
Expected Result:
App should not crash.
Actual Result:
App locks up with a black screen. Usually happens after 2 or 3 feeds, but can take longer.
Attachments
May relate to TIMOB-7775.
Cannot reproduce with latest master. ANR no longer exists.
Able to reproduce. SDK: 2.0.0.v20120320133259 Android: V8 Studio: 2.0.0.201203200828 OS: Windows 7 Devices Tested: Nexus One 2.2.2
Is this a crash or lock up? Is there log output that can be referenced? Since this issue is difficult to reproduce on the platform side, can we please get this information added to the ticket?
This is a lock-up, the log is in the attachments.
Attached new lock-up log. Attached new project file, making it easier to reproduce. In the modified project, the rss windows will close automatically after opening. Steps to Reproduce: 1. Click on the first row. Wait for it to load and close. Repeat. (Press 'back' manually if necessary to back out). Bug: Screen turns black and clicks register on console as being unable to dispatch.
Further investigation is required in terms of identifying the correct fix but this appears to be a issue with the lifecycle event of the top activity finishing being blocked on another event from the runtime thread.
We were unable to reproduce this issue on latest master. Marking as Unable to reproduce.
Closing this ticket as the issue cannot be reproduced.