Bug 173558 - up2date segfault
up2date segfault
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: up2date (Show other bugs)
4.0
i686 Linux
medium Severity high
: ---
: ---
Assigned To: Pradeep Kilambi
Ken Reilly
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-11-17 22:01 EST by Mark Cannell
Modified: 2013-02-26 19:49 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-04-23 12:48:11 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Strace Output (592.87 KB, text/plain)
2005-11-21 14:19 EST, John M
no flags Details
GDB bt output (15.15 KB, text/plain)
2005-11-21 14:55 EST, John M
no flags Details

  None (edit)
Description Mark Cannell 2005-11-17 22:01:16 EST
Description of problem:
New system trying to get updated with bug fixes etc... The up2date did not work
as reported to be "old" and might not work correctly -despite the system being
installed from latest CDs. Got new up2date by hand and installed it.

During update (via rhn) it checks for new file headers then it crashes:

kernel: up2date[5027]: segfault at 0000002a9d412fe0 rip 0000003709a715f0 rsp
0000007fbfffa318 error 4

Version-Release number of selected component (if applicable):

up2date-4.4.50-4.x86_64

How reproducible:
Very

Steps to Reproduce:
1.press the pretty red up2date icon or type up2date in console
2.
3.
  
Actual results:
Nothing
Expected results:
error message or list of software to update

Additional info:
Comment 1 John M 2005-11-21 14:19:21 EST
Created attachment 121308 [details]
Strace Output
Comment 2 John M 2005-11-21 14:54:10 EST
I have also encountered this problem.  up2date fails to run correctly, and 
scheduled packages through RHN fail to install.

I also have seen similar lines in my system logs, such as these:

kernel: up2date[7209] general protection rip:3856e6fd00 rsp:7fbfffbf78 error:0
kernel: rhn_check[24608] general protection rip:3856e6fd00 rsp:7fbfffba98 
error:0

From the attached gdb.log file, this is a key segment that shows that zlib is 
trying to decompress an object, and is failing.  It then segfaults on printing 
out the error:

#0  0x0000003856e6fd00 in strlen () from /lib64/tls/libc.so.6
(gdb) bt
#0  0x0000003856e6fd00 in strlen () from /lib64/tls/libc.so.6
#1  0x00002aaaaab3c61f in PyString_FromFormatV (
    format=0x2aaaae500382 "Error %d %s: %.200s", vargs=0x7fffff9928d0)
    at Objects/stringobject.c:206
#2  0x00002aaaaab71570 in PyErr_Format (exception=0x2aaaadc466b0, 
format=Variable "format" is not 

available.
)
    at Python/errors.c:519
#3  0x00002aaaae4ff285 in PyZlib_decompressobj (selfptr=Variable "selfptr" is 
not available.
)

Using gdb, I was able to perform a walk-through of python, keyed on the 
PyZlib_decompressobj function:

# gdb /usr/bin/python
GNU gdb Red Hat Linux (6.3.0.0-1.63rh)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu"...Using host libthread_db 
library "/lib64/tls/libthread_db.so.1".

(gdb) break PyZlib_decompressobj 
Function "PyZlib_decompressobj" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y

Breakpoint 1 (PyZlib_decompressobj) pending.
(gdb) run /usr/sbin/up2date -l
Starting program: /usr/bin/python /usr/sbin/up2date -l
[Thread debugging using libthread_db enabled]
[New Thread 46912498522496 (LWP 18943)]
Breakpoint 2 at 0x2aaaae4ff170: file ./Modules/zlibmodule.c, line 327.
Pending breakpoint "PyZlib_decompressobj" resolved
[Switching to Thread 46912498522496 (LWP 18943)]

Breakpoint 2, PyZlib_decompressobj (selfptr=0x0, args=0x2aaaaacf8050)
    at ./Modules/zlibmodule.c:327
327     {
(gdb) next
330         if (!PyArg_ParseTuple(args, "|i:decompressobj", &wbits))
(gdb) 
327     {
(gdb) 
330         if (!PyArg_ParseTuple(args, "|i:decompressobj", &wbits))
(gdb) 
328         int wbits=DEF_WBITS, err;
(gdb) 
330         if (!PyArg_ParseTuple(args, "|i:decompressobj", &wbits))
(gdb) 
331             return NULL;
(gdb) 
330         if (!PyArg_ParseTuple(args, "|i:decompressobj", &wbits))
(gdb) 
333         self = newcompobject(&Decomptype);
(gdb) 
335             return(NULL);
(gdb) 
334         if (self == NULL)
(gdb) 
333         self = newcompobject(&Decomptype);
(gdb) 
334         if (self == NULL)
(gdb) 
336         self->zst.zalloc = (alloc_func)NULL;
(gdb) 
337         self->zst.zfree = (free_func)Z_NULL;
(gdb) 
338         err = inflateInit2(&self->zst, wbits);
(gdb) 
339         switch(err) {
(gdb) 
338         err = inflateInit2(&self->zst, wbits);
(gdb) 
339         switch(err) {
(gdb) 
353             zlib_error(self->zst, err, "while creating decompression 
object");
(gdb) print err
$1 = -6
(gdb) next

Program received signal SIGSEGV, Segmentation fault.
0x0000003856e6fd00 in strlen () from /lib64/tls/libc.so.6

Error -6 may indicate a version error: #define Z_VERSION_ERROR (-6)

See strace.log (attached) for an strace output.
See gdb.log (attached) for a gdb bt output.
Comment 3 John M 2005-11-21 14:55:02 EST
Created attachment 121309 [details]
GDB bt output
Comment 4 John M 2005-11-21 16:18:44 EST
I have been able to solve my problem.  I'm not sure if this is yours, but it 
turns out that python was using a copy of zlib.so that had been packaged with 
Matlab.  My /etc/ld.so.conf.d directory contained a file listing matlab's 
bin/glnxa64 directory, which contains libz.so.1.1.4.

An ldd showed this usage:

# ldd /usr/lib64/python2.3/lib-dynload/zlibmodule.so 
        libz.so.1 => /apps/matlab14sp2/bin/glnxa64/libz.so.1 
(0x00002aaaaabe0000)
        libpthread.so.0 => /lib64/tls/libpthread.so.0 (0x00002aaaaacee000)
        libc.so.6 => /lib64/tls/libc.so.6 (0x00002aaaaae03000)
        libstdc++.so.5 => /usr/lib64/libstdc++.so.5 (0x00002aaaab037000)
        libm.so.6 => /lib64/tls/libm.so.6 (0x00002aaaab212000)
        libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00002aaaab398000)
        /lib64/ld-linux-x86-64.so.2 (0x0000555555554000)

Matlab uses zlib 1.1.4.  Python wants version 1.2.1.*.  Why Python was 
segfaulting is still an issue, but is not an issue with up2date.  I 
added /usr/lib64 and /usr/lib to the top of /etc/ld.so.conf and ran ldconfig.  
Afterwords, ldd showed the correct usage:
# ldd /usr/lib64/python2.3/lib-dynload/zlibmodule.so 
        libz.so.1 => /usr/lib64/libz.so.1 (0x00002aaaaabe0000)
        libpthread.so.0 => /lib64/tls/libpthread.so.0 (0x00002aaaaacf3000)
        libc.so.6 => /lib64/tls/libc.so.6 (0x00002aaaaae08000)
        /lib64/ld-linux-x86-64.so.2 (0x0000555555554000)

up2date was then able to run properly.
Comment 5 Mark Cannell 2005-11-21 17:36:12 EST
(In reply to comment #4)
> I have been able to solve my problem.  I'm not sure if this is yours, but it 
> turns out that python was using a copy of zlib.so that had been packaged with 
> Matlab.  My /etc/ld.so.conf.d directory contained a file listing matlab's 
> bin/glnxa64 directory, which contains libz.so.1.1.4.
> 
snipped
> 
> Matlab uses zlib 1.1.4.  Python wants version 1.2.1.*.  Why Python was 
> segfaulting is still an issue, but is not an issue with up2date.  I 
> added /usr/lib64 and /usr/lib to the top of /etc/ld.so.conf and ran ldconfig.  
> Afterwords, ldd showed the correct usage:
> # ldd /usr/lib64/python2.3/lib-dynload/zlibmodule.so 
>         libz.so.1 => /usr/lib64/libz.so.1 (0x00002aaaaabe0000)
>         libpthread.so.0 => /lib64/tls/libpthread.so.0 (0x00002aaaaacf3000)
>         libc.so.6 => /lib64/tls/libc.so.6 (0x00002aaaaae08000)
>         /lib64/ld-linux-x86-64.so.2 (0x0000555555554000)
> 
> up2date was then able to run properly.
Thanks John,
Unfortunately, my ldd listing is the same as your fixed version I have only libz
 1.2.1 installed. I updated python to the latest offering but still no fix.

Apart from reinstalling the system I have no idea where to go next.

Cheers Mark
Comment 6 Andre 2005-12-05 22:25:11 EST
Hi,

I have the same specs as yours, and was having the same problem. up2date keep
crashing.
I notice that on my first time (previous) registration, it gave me an error that
the activation key is invalid, on second try it worked. and that's when the
problem occurs.

Them I cleaned all the headers
rm -f /var/spool/up2date/*.hdr /var/spool/up2date/rhel-*
delete the system from rhn and reregister it again.

and now up2date managed not to crash on the same error again.

But it has another error, 

[Tue Dec  6 10:10:44 2005] up2date updating login info
[Tue Dec  6 10:10:44 2005] up2date logging into up2date server
[Tue Dec  6 10:10:49 2005] up2date successfully retrieved authentication token
from up2date server
[Tue Dec  6 10:10:49 2005] up2date availablePackageList from network
[Tue Dec  6 10:10:49 2005] up2date Unable to import repomd support so repomd
support will not be available
[Tue Dec  6 10:11:16 2005] up2date A protocol error occurred: Proxy Error ( Bad
network address encountered. For more information about this event, see ISA
Server Help.  ) , attempt #1,
[Tue Dec  6 10:18:55 2005] up2date A socket error occurred: (4, 'Interrupted
system call'), attempt #1

seems like a problem with MS ISA proxy server, but after one ctrl-c, it resume
the downloading process again.

Is it possible it is because of small bandwidth ?

ps: msdoc EventID: 10013
http://www.microsoft.com/resources/documentation/isa/2000/enterprise/proddocs/en-us/isadocs/isa_fireevents.mspx

Cheers,
Andre Kusuma
Comment 7 Barry Platt 2005-12-12 09:50:52 EST
I just experienced the same problem - repeated segfault running up2date --update
--nox --force.  I cleaned the headers, as in the last update: 
# rm -f /var/spool/up2date/*.hdr /var/spool/up2date/rhel-*
but *did not* delete and reregister the system.  up2date then succeeded.  

Regards,
Barry Platt <bplatt@incoherent.net>
Comment 9 RHEL Product and Program Management 2010-04-23 12:48:11 EDT
Development Management has reviewed and declined this request.  You may appeal
this decision by reopening this request.

Note You need to log in before you can comment on or make changes to this bug.