package ubuntu-docs 8.04.2~hardy failed to install/upgrade: subprocess post-installation script returned error exit status 139

[Nicholas Kourtzis]

Binary package hint: ubuntu-docs

Debug info attached.

ProblemType: Package
Architecture: i386
Date: Tue Apr 22 22:10:24 2008
DistroRelease: Ubuntu 8.04
ErrorMessage: subprocess post-installation script returned error exit status 139
NonfreeKernelModules: fglrx
Package: ubuntu-docs 8.04.2~hardy
PackageArchitecture: all
SourcePackage: ubuntu-docs
Title: package ubuntu-docs 8.04.2~hardy failed to install/upgrade: subprocess post-installation script returned error exit status 139
Uname: Linux 2.6.24-16-generic i686

[Michael Vogt (mvo)]

Here is the errors:

dpkg: error processing update-manager (--configure):^M
 subprocess post-installation script returned error exit status 139^M
...
Setting up ubuntu-docs (8.04.2~hardy) ...^M
dpkg: error processing ubuntu-docs (--configure):^M
 subprocess post-installation script returned error exit status 139^M
...
Setting up evolution-common (2.22.1-0ubuntu3) ...^M
dpkg: error processing evolution-common (--configure):^M
 subprocess post-installation script returned error exit status 139^M
...
dpkg: error processing gdm (--configure):^M
 subprocess post-installation script returned error exit status 139^M
...
dpkg: error processing rhythmbox (--configure):^M
 subprocess post-installation script returned error exit status 139^M
Setting up seahorse (2.22.1-0ubuntu2) ...^M
dpkg: error processing seahorse (--configure):^M
 subprocess post-installation script returned error exit status 139^M

[Michael Vogt (mvo)]

Thanks for your bugreport and the log.

Could you please check /var/crash and let us know what files that contains? The error messages you see suggest that there is something in various postinst scripts segfaulting.

[Kaden (kpownall)]

I'd like to add a "me too" to this. Happened earlier this evening when I tried to install my daily updates. Several packages failed to update with the same 139 exit status, but ubuntu-docs was the first one to fail, causing the others to fail due to dependency issues.

$ ls /var/crash
evolution.0.crash gdm.0.crash ubuntu-docs.0.crash
evolution-common.0.crash rhythmbox.0.crash

I'm running same kernel as OP, with no NonFree kernel modules loaded.

[almagest (angelleroy)]

I'm having the same problem. Any operation I perform with apt-get or synaptic returns something like the following (example with sudo apt-get remove ubuntu-docs):

Removing ubuntu-docs ...
Segmentation fault
dpkg: error processing ubuntu-docs (--remove):
 subprocess post-removal script returned error exit status 139
Errors were encountered while processing:
 ubuntu-docs
E: Sub-process /usr/bin/dpkg returned an error code (1)

Contents of /var/crash:

eog.0.crash gnome-applets-data.0.crash ubuntu-docs.0.crash
gdm.0.crash gnome-user-guide.0.crash

[knetch (knetch)]

Any solutions? I don't use evolution. What can I safely get rid of to fix this?

[Andrew Hamblin (lextori)]

I've got a similar error, any thing I can do to help this get solved.

[Kaden (kpownall)]

Michael,

What more information is needed so that this is not an "incomplete"? You asked for contents of /var/crash which I and another poster provided you. No one has asked for any more information, yet the bug is just abandoned as "incomplete" even though everything asked for has been provided? I don't get it.

To those of you still having this issue: I finally gave up waiting for some sort of resolution and just formatted and reinstalled and that solved the issue for me. If I had a better solution for you I'd provide it, but unfortunately I don't.

I thought that using places like launchpad was part of this "community" deal that Linux is so well known for. I understand that everyone here has real jobs and this is just voluntary, but this bug was posted nearly 5 months ago, and to not even get so much as a "screw off"..... I'm sorry, that just leaves a very bitter taste in my mouth.

Sorry to rant, this just really ticks me off. If I've missed something here and I'm the a$$hole, then please tell me and I'll gladly retract everything I said.

[Matthew East (mdke)]

It might be helpful to get the contents of /var/crash/ubuntu-docs.0.crash - can someone attach that?

Kaden - I partially understand your frustration but bug reports are not a support mechanism, you shouldn't expect necessarily to get help from them. Sometimes you might, but other times you won't.

We don't know what is causing this crash, and that is why we haven't fixed the bug. And evidently, no one following this bug knows how to fix a system affected by it. Obviously, the trick is to remove ubuntu-docs and reinstall it, but I'm guessing you guys have tried that.

The best option is to try a genuine support resource (free ones are listed here - http://www.ubuntu.com/support/communitysupport)

[Keith Jackson (krjackson)]

I ran into a similar problem where I couldn't upgrade or install anything. Like the others, I would get a segfault and "subprocess post-installation script returned error exit status 139". This was also on hardy on x86. I spent a little time with gdb and could see this: Core was generated by `/usr/bin/perl -w /usr/sbin/update-binfmts --import cli'. I ran that command by hand, and it segfaults. Attaching gdb to that core file showed me:
(gdb) where
#0 0xb7ecd13c in readdir64_r () from /lib/tls/i686/cmov/libc.so.6
#1 0x080fe65c in Perl_pp_readdir ()
#2 0x080c0cab in Perl_runops_standard ()
#3 0x0806727b in perl_run ()
#4 0x08063792 in main ()

I downgraded libc6 from 2.7-10ubuntu4 to 2.7-10ubuntu3 and libc6-i686 from 2.7-10ubuntu4 to 2.7-10ubuntu3. I was then able to run dpgk --configure -a and complete the upgrades that were hanging.

As soon as I do an apt-get upgrade it upgrades back to the newer libc6 and I have the same problems again. It certainly seems that there is something strange going on with readdir64_r in the latest libc6

[Dougie Richardson (dougierichardson)]

Adding the GLibC people in on this.

[Dougie Richardson (dougierichardson)]

Apologies for multiple emails. Never leave an unattended laptop near a small cat with an affinity for anything warm and recently attracting the interest of humans.

[Keith Jackson (krjackson)]

I decided to pursue this a little further, and wrote a really brain dead test case:
#include <sys/types.h>
#include <dirent.h>

int main() {
 DIR *d;
 struct dirent64 *dent;
 struct dirent64 *dresult;
 d = opendir("/tmp");
 readdir64_r(d, dent, &dresult);
 closedir(d);
}

This segfaults on my machine in the same way. Here's what I see from gdb:
(gdb) where
#0 0xb7ed09bc in memcpy () from /lib/tls/i686/cmov/libc.so.6
#1 0xb7eef10b in readdir64_r () from /lib/tls/i686/cmov/libc.so.6
#2 0x08048485 in main ()

If I get some time this evening I'll try stepping through this to see what is going on. For now I'm going to have to let this go.

[Colin Watson (cjwatson)]

Thanks for this detective work; it's particularly interesting to know that this goes away after downgrading glibc. For what it's worth, the same bug is present in Intrepid.

This is especially curious since the changes in glibc 2.7-10ubuntu4 don't seem as though they should touch readdir64_r:

glibc (2.7-10ubuntu4) hardy-proposed; urgency=low

  * glibc fixes for hardy. LP: #269299.
  * Fix vscanf define in strict C99 or POSIX mode. LP: #234893.
  * Merge changes from glibc-2.7-11, -12 and -13:
    - Cherry-pick upstream fixes with respect to locale rwlocks, merge them into
      patches/any/cvs-strerror_r.diff. Closes: #489906.
    - patches/any/cvs-getaddrinfo.diff: new patch from CVS to correctly
      initialize internal resolver structures in getaddrinfo(). Closes:
      #489586.
    - patches/any/cvs-iconv-braces.diff: new patch from upstream to fix various
      iconv bugs.
    - local/manpages/nscd.conf.5: update nscd.conf manpage. Closes: #482505.

 -- Matthias Klose <email address hidden> Fri, 12 Sep 2008 09:17:19 +0200

[Colin Watson (cjwatson)]

Keith, this code is incorrect. The second argument to readdir64_r is supposed to point to somewhere to store the result; instead you're just passing it an uninitialised pointer. Understandably, it segfaults.

In order to correct it, one must also define a feature test macro to get the definition of 'struct dirent64'. Here's corrected code, which does not segfault:

#define _LARGEFILE64_SOURCE
#include <sys/types.h>
#include <dirent.h>

int main() {
 DIR *d;
 struct dirent64 dent;
 struct dirent64 *dresult;
 d = opendir("/tmp");
 readdir64_r(d, &dent, &dresult);
 closedir(d);
}

[Colin Watson (cjwatson)]

(Thus my comment that the same bug is present in Intrepid may not apply.)

[Colin Watson (cjwatson)]

Getting the contents of /var/crash/ubuntu-docs.0.crash would help, as Matthew previously noted.

I suspect that Keith may be seeing a different bug, since update-binfmts isn't invoked by all these packages. One thing which does seem to be common to many of these maintainer scripts is scrollkeeper. Could somebody affected by this bug please try running 'sudo scrollkeeper-update -q' and post the output? If that also segfaults, try 'sudo scrollkeeper-update -v' as well for more output.

[Keith Jackson (krjackson)]

Doh! Thanks Colin. That's what happens after a year or two of mostly python coding. :-) You forget how to write C.

I did learn one very interesting thing a few minutes ago. I only have this segfault if I am running a xen kernel. When I boot into: 2.6.24-21-server I'm fine. If I'm running 2.6.24-21-xen, I see the segfault.

I don't have scrollkeeper even installed on my box, so I can't get you the output of that.

I did however attach the crash file from sun-java6-bin.

I also just tried installing xen on an identical box. I did an apt-get install ubuntu-xen-server, rebooted into the xen kernel, and tried the same apt-get install sun-java6-bin, and no problem. That leads me to conclude that this must be something unique about the one box I have.

If even I can't replicate this problem on another identical machine, it is unlikely that anyone else can help much with this.

I apologize for wasting folks time trying to track this down.