6 ms·
"While debugging, React Native attaches to a Chrome Developer Tools instance. This is great because it is a powerful debugger. However, once the debugger is att
by kbyatnal 8y ago
"While debugging, React Native attaches to a Chrome Developer Tools instance. This is great because it is a powerful debugger. However, once the debugger is attached, all JavaScript runs within Chrome’s V8 engine. This is fine 99.9% of the time. However, in one instance, we got bit when toLocaleString worked on iOS and but only worked on Android while debugging. It turns out that the Android JSC doesn’t include it and it was silently failing unless you were debugging in which case it was using V8 which does."
Wow, I can't imagine how frustrating this must have been to debug.
- MBCook 8y agoI had something like that once in native web dev. It turned out that by default when using the debugging pane the browser would disable cache so the issue (whatever it was) disappeared. Close debugging? It broke again. Maddening.
- filleduchaos 8y ago> native web dev That has to be the strangest combination of terms I've seen this month.
- skocznymroczny 8y agoI've seen people refer to bare metal Javascript, which sounds even weirder.
- kroltan 8y agoEver heard of PhoneGap or Electron?
- filleduchaos 8y agoYes, and neither of them are native, nor are either of them relevant to my comment. What was your point again?
- efrafa 8y agoYou can disable cache while dev tools are open in chrome but its not the default.
- scrumbledober 8y agoAnd, annoyingly, if you check the disable box any time you close the dev tools it resets to unchecked. If you reopen dev tools it still remains unchecked.
- rising-sky 8y agoWhat version of Chrome did you experience this in? I've never had to re-check the "disable cache" checkbox, even after restarting chrome from a crash state. I am currently at version 67.0.3396.87
- maskedSlacker 8y agoSchrodinger's Bug
- rpeden 8y agoI ran into a fun one like that many years ago in IE. The JavaScript I had written was failing, but when I opened up the devtools to debug it, it worked. It turned out that in that version of IE, the console object only existed when the devtools were open. So a stray console.log call was causing an exception because console was undefined. But when I opened the devtools to see what was going on, console existed and so everything ran just fine. I suppose that's the kind of error that only bites you once. When you know about it, you tend to never make that mistake again. But that first time you run into it can cause a painful few hours of head scratching and attempted debugging. Funnily enough, I ran into a React Native error like the one described in the article, where something worked only while debugging. My previous experience with the heisenbug in IE led me to immediately dig into what was different in RN with the devtools open vs without them. So in a way, those hours I wasted in IE back in 2010 prevented me from potentially wasting hours debugging RN in 2017.
- gm-conspiracy 8y agoBeen bitten by the console bug as well.
- r32a_ 8y agoI've experienced this console.log bug too
- fiiv 8y agoBeen there, that same bug. This one bit a lot of people I think!
- MrRubbish 8y agoI’ve never been bitten by this one.
- exclusiv 8y agoYeah unless you wrap console log you just do this: window.console && console.log('debug msg'); In older Android versions, warnings in modern versions actually crash React Native apps. Can be very frustrating.
- vanadium 8y ago
- spiritcat 8y agofun one was when sort was stable with debugging turned on but not without :P (or vice versa? i forget)
- chengyinliu 8y agoThanks for pointing this out. This part was my experience and as you said, it was quite frustrating. Overall the RN experience made me more skeptical about thing I usually take for granted. It really shows how hard it is for RN to work cross platform. Each abstraction layer can bring in some new problems.
- kbyatnal 8y agoYou were the one who had to find this bug? That's pretty neat! How long did it take for the Aha! moment?
- chengyinliu 8y agoIIRC the whole debugging took half a day. There wasn't exactly an Aha moment either. Enough trying different accounts/platforms/devices/environments made me realize that debugger might have changed the result. Once it was confirmed I actually felt defeated. Hard to feel good when you are hit by observer effect and at the same time realize that the a native JS API could be problematic.
- atomicnumber1 8y agoIt's really fascinating to read about these in hindsight. But yeah, it must have been a nightmare for them.
- LyndsySimon 8y agoI was dealing with a similar bug yesterday. I was using Python (Pyramid/SQLAlchemy/PostgreSQL) and had an integration test that was failing about 80% of the time, but would never fail when I stepped through the test code. I ended up pairing with another developer, who rewrote the test from scratch and didn't have the issue. I think I know what the problem was, though - the test code called the route in question on one line, then the next line retrieved an object that was modified during the request. The line after that asserted that an attribute of that object had been changed. Most of the time, it hadn't changed; sometimes it had. To make matters work, any time the file was modified it seemed to work once or twice then begin failing again. I'm 99% sure what was happening is that by the time the object retrieval happened in the test code, PostgreSQL hadn't fully committed the changes to the DB that were made during the request and the object returned was unmodified. Why was that happening? No idea. I suspect it was something to do with connection pooling or the way we were using gevent monkeypatching elsewhere, even though the tests themselves weren't using gevent. Things like this are both the most frustrating and most fulfilling part of development :)