ld-linux.so.2 process excessively consumes CPU

Bug #260004 reported by Matthias
56
This bug affects 6 people
Affects Status Importance Assigned to Milestone
acroread (Ubuntu)
Fix Released
High
Unassigned

Bug Description

Once in a while, a process called "ld-linux.so.2" starts consuming all my system resources, with CPU usage between 90-100%, my 2GB main memory AND my complete swap partition used up completely, making the system unresponsive to a degree that even single keystrokes need up to a minute to get interpreted by the system.

A forum post (http://tinyurl.com/5mdc9p) indicates that Adobe Reader 8 is the source of the problem. It claims that installing the "lsb" package will solve the problem. I can now confirm this does not fix the problem. Instead, the acroread process itself will now turn out to be the resource hog (no ld-linux.so.2 process is listed anymore by 'top' though).

Two known workarounds:
1) uninstall package acroread
2) when slowdown starts, either 'killall -KILL ld-linux.so.2' (package 'lsb' not installed) or 'killall -KILL acroread' (package 'lsb' installed).

Affected Ubuntu version:
Description: Ubuntu 8.04.1
Release: 8.04

Matthias (m-kaeppler)
description: updated
Revision history for this message
Ulrich Lukas (ulrich-lukas) wrote :

I have had the exact same problem since upgrading to 8.04.

Even worse, when the acroread (or ld-linux.so.2) has consumed all of the available system memory (after a significant amount of time), the whole computer locks (almost) completely with the harddisk LED flashing continuously. The systems responsiveness decreases to a minimal level with mouse pointer movements daking several seconds.

When I kill the X-server (and thus acroread) via Ctrl-Alt-Backspace (sometimes taking several minutes), the system works as before the crash.

I've reproduced this bug multiple times; it always coincides with the Adobe Reader Firefox plugin crashing out of Firefox and Opera web browser.

I would consider this a CRITICAL BUG for a LTS distribution version, because:

1. The associated whole-system-crash occurs sporadic and is
2. delayed, can't easily be associated with the crashed application and
3. causes data loss because it forces unknowing users to reboot their system.

I'm Using Kubuntu 8.04 AMD 64 with a vanilla Linux 2.6.27 kernel, but I've had this bug with several other kernel versions before.

Changed in acroread:
status: New → Confirmed
Revision history for this message
Stefan Soriga (sgstefan) wrote :

This is a critical bug, it is present in intrepid too.

Revision history for this message
Vaxius (thegeeker) wrote :

I'm having the exact same symptoms as above. Lately though, simply opening acroread nearly instantly crashes X, bringing up the gdm login. After logging in again, X crashes again before desktop is loaded, and must be completely restarted. This has also started happening intermittently with flash 10, though a quick ps afterwards doesn't show flash still running and gobbling up memory like acroread does.

Relevant part from Xorg.log (full log available at http://pastebin.vaxius.net/pastebin.php?show=3793 or attached):

SetClientVersion: 0 9
Warning: LookupDrawable()/SecurityLookupDrawable() are deprecated. Please convert your driver/module to use dixLookupDrawable().
(II) XAA: Evicting pixmaps

Backtrace:
0: /usr/bin/X(xf86SigHandler+0x7e) [0x80c780e]
1: [0xb7f4f420]
2: /usr/lib/xorg/modules//glesx.so [0xb5815aac]
3: /usr/lib/xorg/modules//libxaa.so(XAAComposite+0x161) [0xb762ac81]
4: /usr/lib/xorg/modules//libxaa.so [0xb7646646]
5: /usr/bin/X [0x8172fa3]
6: /usr/bin/X(CompositePicture+0x150) [0x815a1c0]
7: /usr/bin/X [0x816019f]
8: /usr/bin/X [0x815d055]
9: /usr/bin/X [0x81506de]
10: /usr/bin/X(Dispatch+0x2cf) [0x808d8df]
11: /usr/bin/X(main+0x48b) [0x807471b]
12: /lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe0) [0xb7ce2450]
13: /usr/bin/X(FontFileCompleteXLFD+0x201) [0x8073a91]

Fatal server error:
Caught signal 11. Server aborting

(II) AIGLX: Suspending AIGLX clients for VT switch

Revision history for this message
junipergold (junipergold) wrote :

I had the same problem as Matthias. But I think I found something that solves the problem for me:

If you are behind a proxy and that proxy is not configured in Adobes preferences, try to provide the right settings. On my system Adobe worked without any problems afterwards.

Revision history for this message
joefidler (joefidler) wrote :

I am seeing this issue about once a week on Intrepid with Acroread 8.1.3 installed. ld-linux.so.2 loads and hogs the laptop to the point where it is not usable and requires a full reboot.

There is some mention elsewhere about this bug - http://blogs.adobe.com/acroread/2007/09/known_issues_with_adobe_reader_1.html. In that post they mention that disabling "Allow Fast Web View" is helpful.

We use acroread a lot so this bug is really hitting us.

Revision history for this message
ivelo (mark-temple) wrote :

I have had the same problem. Here is data from atop and syslog where oom killer runs:

-----------------------------------------------------------------------
Here is my atop entry just before the oom killer hoses me:
-----------------------------------------------------------------------

ATOP - velo 2008/12/16 10:29:32 600 seconds elapsed
PRC | sys 12m55s | user 2m31s | #proc 206 | #zombie 2 | #exit 300 |
CPU | sys 118% | user 27% | irq 1% | idle 205% | wait 49% |
cpu | sys 39% | user 17% | irq 1% | idle 27% | cpu000 w 16% |
cpu | sys 27% | user 5% | irq 0% | idle 58% | cpu003 w 11% |
cpu | sys 27% | user 3% | irq 0% | idle 58% | cpu001 w 12% |
cpu | sys 27% | user 2% | irq 0% | idle 61% | cpu002 w 10% |
CPL | avg1 17.48 | avg5 9.00 | avg15 4.28 | csw 1949602 | intr 709492 |
MEM | tot 4.0G | free 25.4M | cache 2.2G | buff 0.4M | slab 54.6M |
SWP | tot 0.0M | free 0.0M | | vmcom 3.4G | vmlim 7.9G |
PAG | scan 2368e5 | stall 0 | | swin 0 | swout 0 |
DSK | sda | busy 33% | read 38664 | write 11725 | avio 4 ms |
DSK | sdd | busy 2% | read 1625 | write 3420 | avio 2 ms |
DSK | sdb | busy 0% | read 125 | write 2 | avio 7 ms |
DSK | sdc | busy 0% | read 2 | write 2 | avio 5 ms |
NET | transport | tcpi 103286 | tcpo 101960 | udpi 463 | udpo 534 |
NET | network | ipi 103800 | ipo 102577 | ipfrw 0 | deliv 103800 |
NET | eth0 0% | pcki 16157 | pcko 28041 | si 222 Kbps | so 54 Kbps |
NET | lo ---- | pcki 74574 | pcko 74574 | si 344 Kbps | so 344 Kbps |

  PID MINFLT MAJFLT VSTEXT VSIZE RSIZE VGROW RGROW MEM CMD 1/11
12668 222539 1202 103K 859.5M 659.6M 665.9M 549.1M 16% ld-linux.so.2
31287 333 283 24K 511.4M 319.8M 0K -27.1M 8% firefox
 7402 80267 241 1592K 365.7M 175.9M 18256K -8800K 4% Xorg

-----------------------------------------------------------------------
Here is the syslog entry where oom killer runs:
-----------------------------------------------------------------------

Dec 16 10:31:17 velo kernel: [611084.971774] kded invoked oom-killer: gfp_mask=0x1201d2, order=0, oomkilladj=0

Notice that ld-linux.so.2 is the big memory user. Now, where is the problem?

Revision history for this message
joefidler (joefidler) wrote :

I did a bit more testing with this issue as it is hitting us a bit and I have seen several mentions of it around. When a PDF is loaded within Firefox using Adobe's acroread, ld-linux.so.2 (Linux dynamic loader) is loaded. It runs at about 30 - 50% CPU and does not unload when acroread is closed. It will then continue running at high CPU, and with an apparent memory leak it gradually consumes all available memory and then paging starts. The system gradually becomes unusable and requires a full reboot to restore operation ( on my laptop I am unable to even get enouth resources to kill the process). I am using 64Bit Intrepid.

I tested loading a PDF directly with acroread and the issue does not seem to occur - ld-linux.so.2 is loaded, (and there is still a bit of a possible memory leak), but it does not hog CPU and unloads when acroread is finished.

It looks to me that the issue lies with the way the firefox plugin loads ld-linux.so.2. Work around seems to be to disable the Firefox plugin and download PDFs rather the opening them in the browser.

I think the plug-in belongs to Mozilla ?

Revision history for this message
joefidler (joefidler) wrote :

I had another occurrence of the issue today - after I had disabled the acroread plugin. I had used acroread earlier so it may be still related to that application - I will try to prove that. System monitor did not show ld-linux.so.2 as loaded so this issue may be a bit deeper, more random and harder to nail down.

Revision history for this message
Dimitrios Symeonidis (azimout) wrote :

A couple of clarifications:
1) Ubuntu does not ship acroread since 6.06. I imagine you all installed it from the medibuntu reposiroty, or from the adobe website.
2) ld-linux.so.2 is part of the libc6 package
3) the killall command is contained in the package psmisc, which is installed by default. try using it without the -KILL parameter, i.e. "killall ld-linux.so.2"

Revision history for this message
Ulrich Lukas (ulrich-lukas) wrote :

Regarding Dimitrios first comment:

Indeed, this might be a problem because the maintainer likely focuses on bugs in newer Ubuntu releases.
This is understandable.

/But/: 6.06 _is_ supposed to be a "LTS" distribution! There is still official support.

/Plus/, AFAIK, the problem still persists with newer distributions, and Adobe Reader is a /critical/ third-party-application for many users. For many documents and tasks there is no alternative.

The problem with the whole system freezing/crashing because of a single non-root user application consuming too much memory is still present even in the newest Jaunty pre-releases.

This is a _really_ nasty thing, and it is also covered in Bug #159356. (Likely a kernel bug, see
http://bbs.archlinux.org/viewtopic.php?pid=390313#p390313)

Revision history for this message
Dimitrios Symeonidis (azimout) wrote :

setting importance to high

Changed in acroread:
importance: Undecided → High
Revision history for this message
Dimitrios Symeonidis (azimout) wrote :

according to this post: http://citadel.tistory.com/158
the problem can be resolved by disabling two options in acroread:
Edit->Preferences->Internet-> Allow fast web view & Allow speculative downloading in the backgroud

can anyone confirm?
(on my system, when launching acroread, the gnome panel would freeze for 3-4 seconds, now it doesn't anymore)

Revision history for this message
Dimitrios Symeonidis (azimout) wrote :

also, from this blog post comment: http://blogs.adobe.com/acroread/2008/02/known_issues_with_adobe_reader.html#comment-1314549
it seems to be SElinux-related, although we have selinux disabled...

Revision history for this message
Olof Staffans (olof-staffans) wrote :

I have not myself encountered this problem in my Kubuntu (intrepid) installations. However, I have had the same problem in a Fedora with Firefox 2.0.0.19 and Adobe Reader 7.0.

My present workaround is to simply un-installed mozilla-acroread.

Revision history for this message
AashishDattani (aashish-dattani) wrote :

I am working behind a proxy, and I configured the right settings in Adobe preferences. Also, I disabled Allow fast web view & Allow speculative downloading in the backgroud as suggested above and this is working for me. Although ld-linux.so.2 still runs in the background, it does not hog processor resources.

Revision history for this message
RBK (kreckel) wrote :

I disabled the options "Allow fast web view" and "Allow speculative downloading in the backgroud" and it does not make a difference. I'm using acroread 8.1.5 under Debian 5.0.1 on an x86_64 system.

Revision history for this message
Gerhard Radatz (gerhard-radatz) wrote :

I installed 9.1.0-7jaunty2+medibuntu1 now (from the jaunty medibuntu repository) and the problem is gone.

Changed in acroread (Ubuntu):
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Bug attachments

Remote bug watches

Bug watches keep track of this bug in other bug trackers.