Bug 62676 - rhn_register fails on new install due to 'python crashing' error
rhn_register fails on new install due to 'python crashing' error
Product: Red Hat Satellite 5
Classification: Red Hat
Component: Registration (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Cristian Gafton
Fanny Augustin
: 71214 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2002-04-04 02:38 EST by Tim Conrad
Modified: 2007-10-23 22:02 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-03-05 22:18:44 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Tim Conrad 2002-04-04 02:38:25 EST
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; Q312461)

Description of problem:
Running Redhat Linux 7.2 on a fresh install right out of the box on a Pentium 
II 300 MHz desktop computer. Did a custom install with all the packages. Upon 
running rhn_register for the first time and entering my existing account 
information I received the following error 'Application "/usr/bin/python" 
(process xxxxx) has crashed due to a fatal system error. (Segmentation Fault)'.

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

How reproducible:

Steps to Reproduce:
1. Just run rhn_register.

Actual Results:  'Application "/usr/bin/python" (process xxxxx) has crashed due 
to a fatal system error. (Segmentation Fault)'

Expected Results:  It should have recognized my existing Redhat Network account 
and added this new system profile to my account.

Additional info:

Updated all the rpm packages, up2date packages, rhn_register packages, and 
python-popt package. Nothing helped.
Comment 1 Adrian Likins 2002-04-11 15:09:24 EDT
Sounds like it is crashing doing hardware detection. Could
you try running:


And sending me the output?
Comment 2 Tim Conrad 2002-04-11 15:17:35 EDT
When I run the command /usr/share/rhn/register/hardware.py I get a Segmentation 
Comment 3 Adrian Likins 2002-04-11 15:32:44 EDT
Hmm, well. That would definately be a crash during hardware
detection. Someone on your particular hardware is triggering
a bug somewhere causing the segfault.

This might be kind of difficult to debug. Are you familar
with gdb?

if so, can you try (comments in parens are just that, comments,
no need to type them):

(then when gdb starts, type:)
exec-file python

r /usr/share/rhn/register/hardware.py

(this should try to run the module, and catch the segfault)
(then type)

(this should show a stack trace. If you could cut&paste that stack
trace, it would be very useful)

(to exit gdb..)

Comment 4 Tim Conrad 2002-04-11 16:33:45 EDT
Here is the stake trace from gdb.

#0  0x400f5c4f in strlen () from /lib/i686/libc.so.6
#1  0x0807e60d in ?? () at eval.c:41
#2  0x4002e4b8 in dmi_table () at eval.c:41
#3  0x080a39a0 in ?? () at eval.c:41
Cannot access memory at address 0x1
Comment 5 Thomas J. Baker 2002-05-10 13:53:31 EDT
I'm getting a similiar error under 7.3. Here's a backtrace:

[root@doolittle ~]# /usr/share/rhn/register/hardware.py
Segmentation fault (core dumped)
[root@doolittle ~]# gdb python
GNU gdb Red Hat Linux (5.1.90CVS-5)
Copyright 2002 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 "i386-redhat-linux"...
(no debugging symbols found)...
(gdb) r /usr/share/rhn/register/hardware.py
Starting program: /usr/bin/python /usr/share/rhn/register/hardware.py
(no debugging symbols found)...(no debugging symbols found)...[New Thread 1024
(LWP 22650)]

(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (LWP 22650)]
0x42080b1b in strlen () from /lib/i686/libc.so.6
(gdb) bt
#0  0x42080b1b in strlen () from /lib/i686/libc.so.6
#1  0x0807e63d in PyString_FromString ()
#2  0x40027498 in dmi_table ()
   from /usr/lib/python1.5/site-packages/dmimodule.so
#3  0x080a3a00 in PyDict_Type ()
Cannot access memory at address 0x1
(gdb) quit
The program is running.  Exit anyway? (y or n) y
[root@doolittle ~]# 
Comment 6 Adrian Likins 2002-05-15 15:50:45 EDT
dmiencode.c is gaftons, reassasing to him
Comment 7 Cristian Gafton 2002-08-15 02:01:56 EDT
tried on all the bioses I have access to and I can't repoduce this. I will need
some more help diagnosing this problem.

Basically what I need is for somebody to get the up2date src.rpm, install it on
the affected system and then attempt to get more information from debugging:

rpm -Uvh up2date-*.src.rpm
cd /usr/src/redhat/SPECS
rpm -bp up2date.spec
cd ../BUILD/up2date-*

compile a debugging version of dmimodule.so:

gcc -shared -fPIC -Wl,-soname,dmimodule.so -I/usr/include/python1.5 \
   -g dmimodule.c -o dmimodule.so

then run gdb again in the same directory against ./hardware.py

on the segfault gdb should print now more information about where exactly in
dmidecode.c the problem showed up.

Comment 8 Josef Komenda 2002-09-06 13:03:44 EDT
*** Bug 71214 has been marked as a duplicate of this bug. ***
Comment 9 Josef Komenda 2002-11-12 12:28:22 EST
No action for almost 2 months - time to close?
Comment 10 Mihai Ibanescu 2003-01-15 11:10:51 EST
Comment 11 Cristian Gafton 2003-03-05 22:18:44 EST
no feedback, closing for lack of information

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