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: Always Steps to Reproduce: 1. Just run rhn_register. 2. 3. 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.
Sounds like it is crashing doing hardware detection. Could you try running: /usr/share/rhn/register/hardware.py And sending me the output?
When I run the command /usr/share/rhn/register/hardware.py I get a Segmentation fault.
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): gdb (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) bt (this should show a stack trace. If you could cut&paste that stack trace, it would be very useful) (to exit gdb..) quit
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
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 ~]#
dmiencode.c is gaftons, reassasing to him
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. Thanks.
*** Bug 71214 has been marked as a duplicate of this bug. ***
No action for almost 2 months - time to close?
ping
no feedback, closing for lack of information