When I set the TabProcGrowth=0 and I then start IE fro the debugger I get an IE error that there is connectivity issues the browser can't see the network. I've had really strange results actually using this. Have you seen the tech notes about IE8 and the Losely-Coupled IE architecture that explains all this? I then attached the debugger to it, overriding the default 'script' mode so that I could do 'native' debugging and it works. I used the MS SysInternals Process Monitor (step #3 above) to determine which process loaded my ActiveX. At this point, I just started adding code back line by line until the browser started crashing.Yes, I have done this. After a while, frustrated, I commented out every line referencing Font Awesome and the browser stopped crashing. I tried changing selectors, changing the load order, and everything else I could think of to no avail. Thinking there was no way that a font could be the issue, I added and removed various pieces of our CSS to determine if it was the cause of the problem. Eventually, I added back our Font Awesome CSS which caused the browser to crash. Along the way, I noticed that we were sending the wrong X-UA meta tag so I got sidetracked and fixed that to no avail. In our application, it was easier to add CSS file by file than it was for JS so I went that route. This implied that there was some interplay between CSS and JS which was causing the browser to crash. As a sanity check, I added both back to the application and it would reliably crash. I then added JS and CSS assets separately to find that neither alone caused the browser to crash. I ran our test scripts against the application to find that, unsurprisingly, the browser did not crash. To re-evaluate everything we did, I removed all of the assets from our application to minimize moving parts regardless of how unlikely a variable was, I wanted to remove it. Frustrated with the resultless weeks spent investigating the issue, I decided step back and take a completely different approach. At this point our capacity had to be reduced down to just one developer - me. We had a plethora of information which told us nothing. Unfortunately, it crashed either way and we were no closer to figuring out what was wrong.Īfter several more days of investigation we were just as perplexed as the day we started. We chose different sized datasets thinking that smaller datasets would not trigger a memory leak while a large one would. The automation enabled us to test dozens of scenarios hundreds of times easily to gain metrics which might help illuminate where, in the code, we should look next. The above image serves as proof that modern browsers were unaffected by the bug we were experiencing.Ĭonvinced that the treemap was the issue and that it had to be a memory leak or a race condition, we created automated tooling using sIEve, virtual machines, and AutoIt scripts. That is until the browser started crashing intermittently for some of our users. It wasn’t lightning fast in IE8, but it worked sufficiently well with a reasonably complex dataset. ![]() One of our teams created an interactive DOM based treemap which worked in Internet Explorer 8 (IE8) and above. Once, I came across a bug which looked like two other things, but turned out to be a third unexpected thing. Testing is always in order with new bugs (or any bug more complex than a typo).ĭebugging gets even trickier and more time consuming when we encounter a bug that resembles a pattern that we’ve seen before. Be warned, sometimes the solutions online solve a similar problem, but not your root problem. Often enough, that set of tools will guide you to a solution within a reasonable amount of time. ![]() Thus, we must investigate using a limited set of tools: When a bug is brand new to us, we haven’t had the opportunity to derive a pattern from it yet because we have no experience to draw upon to create that pattern(s). How Bugs Can Mislead Investigative Efforts But today, we will be exploring the types of bugs that do not come up in our day-to-day work. Because we recognize the pattern, we can quickly debug most of the bugs we come across in our day-to-day work. We are good at pattern recognition and recognizing similarities to problems we’ve faced in the past. Given this experience, it’s easy for us to think that we are good at debugging. Even complex bugs, while requiring investigation, often follow a familiar pattern(s) that help us identify a path to a solution. These problems do not bog us down very much, and they are quick and easy to fix. Often, they are simple typos or a misuse of an API. While coding, we run into a lot of different bugs. Either way, we can usually draw from our experience to find a path forward. Sometimes the problems we face are small or simple. As software engineers we invest time into thinking about the problems we are trying to solve every day.
0 Comments
Leave a Reply. |