Exclusive LG phones only from AT&T
Follow-up: Another fix for system-wide freezes when Web browsing
Last week's special report on resolving system-wide freezes that occur when Web browsing generated significant response.
To recap, the issue occurs when Web pages suddenly stop loading - sometimes halfway through a page -- applications refuse to launch, then the system becomes completely unresponsive; eventually, the user is left with a spinning cursor and must manually restart the system.
The issue can be linked (in most cases) to a bug in the lookupd component of Mac OS X which handles various networking routines and may have been adversely affected by recent updates including Java 1.3.1 and 1.4.2 release 2. The most straightforward fix is to simply interrupt the network connection (by pulling an Ethernet cable, turning off an AirPort card, cycling network devices [cable, DSL modems, routers]) though we outlined several more permanent and less intrusive solutions in our special report.
One of the most interesting pieces of feedback to the report came from MacFixIt reader Wes Palmer, who found out a specific way to reproduce the issue with a high level of consistency and a workaround based on that information.
Wes writes: "With Etherpeek running, I was able to force the failure by doing repeated reloads of a particular page in FireFox. It never took more than 6 reloads to fail. Every single time, the last DNS packet received was for js.adsonar.com. I was then able to force a failure outside of FireFox using that address and ping. I added an entry to /etc/hosts:
- 127.0.0.1 js.adsonar.com
"to avoid any DNS queries of that site and have been unable to force a failure since. I'm out of time this morning, so haven't been able to confirm these results with a lot of certainty, but so far they seem consistent and repeatable."
The method for modifying the /etc/hosts entry to disable access to the host js.adsonar.com -- a company that hosts ads used on several Web sites -- as indicated above by Wes is as follows:
Enter the following command in the Terminal (located in Applications/Utilities) and press return:
- sudo /Applications/TextEdit.app/Contents/MacOS/TextEdit /etc/hosts
This will open the /etc/hosts file in the TextEdit application.
Add the line:
127.0.0.1 js.adsonar.comto the end of the file (under hosts) and save. You'll be running in root at this point, so quit TextEdit immediately and do not modify any other files.
Launch your favorite Web browser and check for persistence of the issue.
Feedback? Late-breakers@macfixit.com.Previous coverage:
Resources
Browser would crash. I tried AdBlocker to stop this, but it didn't work. I hope this
fix works. I tried loading that URL directly in my web browser and my computer
still works. So I hope this is a permanent fix.
would my computer communicate (without my knowledge) with a third party?
What's being communicated? What's a DNS query and a DNS packet? Is this
"js.adsonar" the cause of the reported freezes? And who exactly is adsonar?
DNS is how a system resolves names to internet addresses, e.g. how "www.apple.com" becomes a numeric IP address.
Most every commercial web page contains links to ad servers, counters and other sites.
AdSonar is "a targeted internet ad site that drives qualified customers to advertisers on a pay-per-click basis" or basically a site that generates and displays the banner ads that are displayed on most any web site.
/usr/sbin/lookupd -d
in a terminal window. It doesn't run in a daemon mode when done this way,
but provides a prompt for queries and makes requests for the other copy
already running in daemon mode. I did this and passed it the query:
hostWithName js.adsonar.com
It would generally respond as expected on the first query, but if I repeated
the query several times, on the second or a subseqent time my non-daemon
copy of lookupd would fail with a segmentation fault or buss error. These are
memory refernece errors usually related to bad pointers or overrunning a
buffer. Once the non-daemon copy didn't respond for a while and the
daemon copy of lookupd went to 100% CPU utilization for a while. It may have
come back eventually, but I broke out with a <cntrl>C at which point the
daemon copy's CPU utilization when back to normal. However, when I quit the
non-daemon copy that time it wrote lots of messages about malloc trying to
free memory not allocated. Hope this data is useful to someone
troubleshooting the problem.
me, unplugging the network or killing lookupd did not help. I checked
permissions and did a disk repair; no help. Then I ran DiskWarrior and rebuilt
the directory. Problem solved.
---
Thanks,
Allan Marcus
- by October 4, 2005 1:41 AM PDT
- The site js.adsonar.com is just one possible trigger for the lookupd hashing
- Like this Reply to this comment
-
(6 Comments)problem. Apparently the root cause relates to having multiple entries hash to
the same location in the cache of lookupd. This was triggered by the
particular CNAME (DNS) of the site js.adsonar.com which has now been
changed specifically to avoid this problem. Unfortunately, this problem can
manifest itself quite readily due to similar causes. The funny thing is that
different machines running ostensibly the same rev of the OS don't
necessarily experience the same symptoms. My dual G5 is very unreliable
when connected to the network and will freeze in a matter of hours when
reading from the network. My powerbook (on the same gigabit hub) has no
problems at all. The G5 was bought in June so has a new install of Tiger. The
powerbook was upgraded. Go figure. Apple knows of the problem and has
acknowledged my bug report. They are working on it, but I tend to doubt it
making into 10.4.3 at this point. Considering the nature of the problem, I
would guess that it is high priority. Let's hope.