mikeash.com pyblog/tales-from-the-crash-mines-issue-1.html commentshttp://www.mikeash.com/?page=pyblog/tales-from-the-crash-mines-issue-1.html#commentsmikeash.com Recent CommentsFri, 29 Mar 2024 14:31:11 GMTPyRSS2Gen-1.0.0http://blogs.law.harvard.edu/tech/rssSaket - 2018-04-25 04:34:44http://www.mikeash.com/?page=pyblog/tales-from-the-crash-mines-issue-1.html#comments"The easiest way to determine this is to look at the the EXRequestHandler.request property getter implementation". Did you meanEXRequestHandler.response because the assembly code following has top line for response? <br /> <br />&nbsp;0x103FC3DF2 -[EXRequestHandler response] procdd97a815f68ebd987ccae06e469af6cdWed, 25 Apr 2018 04:34:44 GMTRob - 2014-03-10 03:40:43http://www.mikeash.com/?page=pyblog/tales-from-the-crash-mines-issue-1.html#commentsSpeaking of crashes. Do you guys know if Crashlytics is still based on PLCrashReporter?c72c54bd9b54fdc8ba0668e34df9f425Mon, 10 Mar 2014 03:40:43 GMTlandonf - 2014-02-07 16:13:09http://www.mikeash.com/?page=pyblog/tales-from-the-crash-mines-issue-1.html#comments<b>N:</b> If I understand your question, that's correct; the pointer was never changed after being returned; it pointed to memory that was then deallocated and overwritten. <br /> <br />If by static analysis you mean automated static analysis, I don't believe so. There was nothing inherently wrong with the original code from a data flow analysis point of view; the problems only emerged once you factored in concurrency and external timing factors that would be opaque to machine analysis, as far as I'm aware. <br /> <br />If you're asking about human static analysis of the code; sure.a30d7f209a8b2d8b4d2447e528ac7a05Fri, 07 Feb 2014 16:13:09 GMTmikeash - 2014-02-07 03:55:34http://www.mikeash.com/?page=pyblog/tales-from-the-crash-mines-issue-1.html#comments<b>Brent</b> and <b>N</b>: Thanks, I've fixed those two errors. I'll let Landon respond to the questions.53d0fee74892c176d5cec5c29bdff23dFri, 07 Feb 2014 03:55:34 GMTN - 2014-02-06 22:16:42http://www.mikeash.com/?page=pyblog/tales-from-the-crash-mines-issue-1.html#comments<div class="blogcommentquote"><div class="blogcommentquoteinner">... a connection error occurred, the property would be set twice in succession, resulting in the race condition we hypothesized, with the response value being deallocated out from under our ... </div></div> <br />Just curious, when (the first) response was deallocated (assuming it was being deallocated as a connection error occurred), why was the response pointer was still had 'valid memory address but not pointing a valid object'? <br />Or the response pointer never changed, it was just dangling pointer (before deallocator updated response pointer, if it ever does that kind of thing, atomic dealloc and update the ptr) pointing to some memory that got re-used and overwritten with some data? <br /> <br />Could static analysis of the code caught this race condition?366dcfbeb142f71f0a696bdddcb9a19fThu, 06 Feb 2014 22:16:42 GMTN - 2014-02-06 22:02:10http://www.mikeash.com/?page=pyblog/tales-from-the-crash-mines-issue-1.html#comments&gt; We this information information in hand <br />Minor typo: With this information ...a950fb586ee0bd2f42fda3e7cf3b66abThu, 06 Feb 2014 22:02:10 GMTBrent - 2014-02-06 17:48:06http://www.mikeash.com/?page=pyblog/tales-from-the-crash-mines-issue-1.html#commentsLink to <a href="http://osxbook.com/">http://osxbook.com/</a> in above is broken.bc6507fa3d329778dd1dffbd63b9a1b5Thu, 06 Feb 2014 17:48:06 GMT