Bug 232094 - puplet segfaults
puplet segfaults
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: pirut (Show other bugs)
6
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Jeremy Katz
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-03-13 17:03 EDT by Gianluca Cecchi
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-04-28 15:52:52 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)
diff between all rpm installed working and not working fc6 x86_64 systems (2.45 KB, text/plain)
2007-03-26 19:13 EDT, Gianluca Cecchi
no flags Details
userhelper gdb session log (4.95 KB, text/plain)
2007-03-31 08:07 EDT, Gianluca Cecchi
no flags Details
log of process found in previous pup.log session (11.28 KB, text/plain)
2007-04-01 03:00 EDT, Gianluca Cecchi
no flags Details
log for pid 4366 see previous pup.log attach (79.12 KB, text/plain)
2007-04-01 03:02 EDT, Gianluca Cecchi
no flags Details
log for pid 4367 see previous pup.log attach (79.74 KB, text/plain)
2007-04-01 03:03 EDT, Gianluca Cecchi
no flags Details
log for pid 4368 see previous pup.log attach (497.98 KB, text/plain)
2007-04-01 03:04 EDT, Gianluca Cecchi
no flags Details
gdb session of pup process (839 bytes, text/plain)
2007-04-02 17:54 EDT, Gianluca Cecchi
no flags Details
gdb session for userhelper process (4.03 KB, text/plain)
2007-04-02 17:56 EDT, Gianluca Cecchi
no flags Details

  None (edit)
Description Gianluca Cecchi 2007-03-13 17:03:35 EDT
Description of problem:
puplet segfaults

Version-Release number of selected component (if applicable):
pirut-1.2.8-1.fc6

How reproducible:
always

Steps to Reproduce:
1. puplet shows updates and I click view updates
2. root password requested
3. nothing happens 

  
Actual results:
in dmesg I find:
pup[3875]: segfault at 00000034a98d87e2 rip 00000034cb043fbb rsp
00007fffaebe8400 error 4

Expected results:
windows with packages that need update

Additional info:
The system is fc6 updated based on quad core 
model name      : Intel(R) Core(TM)2 Quad CPU           @ 2.66GHz
on the same system there is fc6 x86 that doesn't show
the problem.
On both environments livna repository is enabled.
On x86_64 I made many updates an started to have problems with puplet on 

the command "yum update" works in x86_64.
Searching through logs it seems that the problem probably arised on 15th of
February after massive update done on 14th of February.
Not sure as the logs are truncated at that point.
Comment 1 Jeremy Katz 2007-03-19 18:01:05 EDT
Can you run pup under gdb and see if you can reproduce it and get a backtrace?
Comment 2 Gianluca Cecchi 2007-03-20 02:41:40 EDT
[gcecchi@localhost ~]$ gdb pup
GNU gdb Red Hat Linux (6.5-15.fc6rh)
Copyright (C) 2006 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"...
(no debugging symbols found)
Using host libthread_db library "/lib64/libthread_db.so.1".

(gdb) run
Starting program: /usr/bin/pup 
(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 exited normally.
(gdb) quit

when I type the run command I get the password prompt window and as soon as I
type enter after the password string, in /var/log/messages I get:
Mar 20 07:39:16 localhost kernel: pup[4282]: segfault at 00000034a98d87e2 rip
00000034cb043fbb rsp 00007fffb43e6c00 error 4

The only non-standard thing is that on the system I have
seamonkey-1.0.7-0.6.1.fc6.i386 installed from x86 fc6, so to be able to run
flash pages... and livna repository with nvidia kernel module.
Comment 3 Miloslav Trmač 2007-03-26 05:53:57 EDT
Please start pup, and when the password prompt is displayed, switch to a virtual
terminal.  Attach gdb to the running "userhelper" process, and let it continue.
 Then switch back to X and enter the root password.  Does that show a backtrace
in gdb?
Comment 4 Gianluca Cecchi 2007-03-26 19:11:11 EDT
I don't know if I have understood what you mean with "let it continue"... sorry.
I did as you told (pid of userhelper was 3913) and I ran
gdb /usr/sbin/userhelper 3913 in a vt console session
This GDB was configured as "x86_64-redhat-linux-gnu"...
(no debugging symbols found)
Using host libthread_db library "/lib64/libthread_db.so.1".

Attaching to program: /usr/sbin/userhelper, process 3913
Reading symbols from /usr/lib64/libuser.so.1...(no debugging symbols found)...do
ne.
Loaded symbols for /usr/lib64/libuser.so.1
Reading symbols from /lib64/libcrypt.so.1...(no debugging symbols found)...done.
Loaded symbols for /lib64/libcrypt.so.1
Reading symbols from /lib64/libgobject-2.0.so.0...
(no debugging symbols found)...done.
Loaded symbols for /lib64/libgobject-2.0.so.0
Reading symbols from /lib64/libgmodule-2.0.so.0...(no debugging symbols found)..
.done.
Loaded symbols for /lib64/libgmodule-2.0.so.0
Reading symbols from /lib64/libdl.so.2...
(no debugging symbols found)...done.
Loaded symbols for /lib64/libdl.so.2
Reading symbols from /lib64/libglib-2.0.so.0...(no debugging symbols found)...do
ne.
Loaded symbols for /lib64/libglib-2.0.so.0
Reading symbols from /lib64/libpam_misc.so.0...
(no debugging symbols found)...done.
Loaded symbols for /lib64/libpam_misc.so.0
Reading symbols from /lib64/libpam.so.0...(no debugging symbols found)...done.
Loaded symbols for /lib64/libpam.so.0
Reading symbols from /lib64/libselinux.so.1...
(no debugging symbols found)...done.
Loaded symbols for /lib64/libselinux.so.1
Reading symbols from /lib64/libattr.so.1...(no debugging symbols found)...done.
Loaded symbols for /lib64/libattr.so.1
Reading symbols from /lib64/libc.so.6...
(no debugging symbols found)...done.
Loaded symbols for /lib64/libc.so.6
Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols found).
..done.
Loaded symbols for /lib64/ld-linux-x86-64.so.2
Reading symbols from /lib64/libaudit.so.0...
(no debugging symbols found)...done.
Loaded symbols for /lib64/libaudit.so.0
Reading symbols from /lib64/libsepol.so.1...(no debugging symbols found)...done.
Loaded symbols for /lib64/libsepol.so.1
Reading symbols from /lib64/libnss_files.so.2...
(no debugging symbols found)...done.
Loaded symbols for /lib64/libnss_files.so.2
Reading symbols from /lib64/security/pam_rootok.so...(no debugging symbols found
)...done.
Loaded symbols for /lib64/security/pam_rootok.so
Reading symbols from /lib64/security/pam_timestamp.so...
(no debugging symbols found)...done.
Loaded symbols for /lib64/security/pam_timestamp.so
Reading symbols from /lib64/security/pam_env.so...(no debugging symbols found)..
.done.
Loaded symbols for /lib64/security/pam_env.so
Reading symbols from /lib64/security/pam_unix.so...
(no debugging symbols found)...done.
Loaded symbols for /lib64/security/pam_unix.so
Reading symbols from /usr/lib64/libcrack.so.2...(no debugging symbols found)...d
one.
Loaded symbols for /usr/lib64/libcrack.so.2
Reading symbols from /lib64/libnsl.so.1...
(no debugging symbols found)...done.
Loaded symbols for /lib64/libnsl.so.1
Reading symbols from /lib64/security/pam_succeed_if.so...(no debugging symbols f
ound)...done.
Loaded symbols for /lib64/security/pam_succeed_if.so
Reading symbols from /lib64/security/pam_deny.so...
(no debugging symbols found)...done.
Loaded symbols for /lib64/security/pam_deny.so
Reading symbols from /lib64/security/pam_permit.so...(no debugging symbols found
)...done.
Loaded symbols for /lib64/security/pam_permit.so
Reading symbols from /lib64/security/pam_xauth.so...
(no debugging symbols found)...done.
Loaded symbols for /lib64/security/pam_xauth.so
0x00000034b7ebfb80 in __read_nocancel ()
   from /lib64/libc.so.6

then gdb stopped at its prompt
(gdb)

I came back to the gui and typed the password: nothing in gdb console, no window
 about pup coming up...
In gdb I typed bt and I got:
(gdb) bt
#0  0x00000034b7ebfb80 in __read_nocancel () from /lib64/libc.so.6
#1  0x00000034b7e699b7 in _IO_new_file_underflow () from /lib64/libc.so.6
#2  0x00000034b7e6a37e in _IO_default_uflow_internal () from /lib64/libc.so.6
#3  0x00000034b7e5fbd4 in _IO_getline_info_internal () from /lib64/libc.so.6
#4  0x00000034b7e5eb29 in fgets () from /lib64/libc.so.6
#5  0x00000000004031f6 in lu_prompt_console ()
#6  0x00000000004036eb in lu_prompt_console ()
#7  0x0000003c1ba06607 in pam_vprompt () from /lib64/libpam.so.0
#8  0x0000003c1ba06770 in pam_prompt () from /lib64/libpam.so.0
#9  0x00002aaaae7fe830 in pam_sm_open_session ()
   from /lib64/security/pam_unix.so
#10 0x00002aaaae7fc029 in pam_sm_authenticate ()
   from /lib64/security/pam_unix.so
#11 0x0000003c1ba02d57 in _pam_dispatch () from /lib64/libpam.so.0
#12 0x0000003c1ba02662 in pam_authenticate () from /lib64/libpam.so.0
#13 0x00000000004040e6 in lu_prompt_console ()
#14 0x00000000004053ac in lu_prompt_console ()
#15 0x00000034b7e1da44 in __libc_start_main () from /lib64/libc.so.6
#16 0x0000000000402ab9 in lu_prompt_console ()
#17 0x00007fff2a386c48 in ?? ()
#18 0x0000000000000000 in ?? ()
(gdb) quit
The program is running.  Quit anyway (and detach it)? (y or n) y
Detaching from program: /usr/sbin/userhelper, process 3913

Soon after a ps command showed that the pid actually was not active....
and in /var/log/messages:
Mar 27 00:33:33 localhost kernel: pup[4032]: segfault at 00000034a98d87e2 rip 00
000034cb043fbb rsp 00007fff20401030 error 4

I also tried using nv video driver instead of nvidia one, but the problem is the
same.
Under another machine with similar fc6 x86_64 (a dell SX280 with i810 video
driver) I have not these kind of problems... pup works normally.
In attach I send a diff file about the packages, if it can help in some way.
Comment 5 Gianluca Cecchi 2007-03-26 19:13:13 EDT
Created attachment 150976 [details]
diff between all rpm installed working and not working fc6 x86_64 systems
Comment 6 Miloslav Trmač 2007-03-28 02:50:20 EDT
I'm sorry about that, I'll try to be more precise.

* start pup
* when the password prompt is displayed, switch to a virtual terminal.
* find out the PID of a running "userhelper process"
* run (gdb /usr/sbin/userhelper the_pid_found_above)
* Enter a "continue" command.  Leave gdb running.
* Then switch back to X and enter the root password.
* Switch back to the terminal where gdb is running
* If gdb reports "Program recieved signal ..." or something similar, enter
  a "bt" command to get a backtrace.
Comment 7 Gianluca Cecchi 2007-03-28 16:21:10 EDT
ok, done.
this is the output of gdb. It seems no backtrace but exit with code 0377
...
Loaded symbols for /lib64/security/pam_permit.so
Reading symbols from /lib64/security/pam_xauth.so...
(no debugging symbols found)...done.
Loaded symbols for /lib64/security/pam_xauth.so
0x00000034b7ebfb80 in __read_nocancel ()
   from /lib64/libc.so.6
(gdb) continue
Continuing.

Program exited with code 0377.
(gdb) bt
No stack.
(gdb) quit

and in dmesg I have the entry:
pup[6539]: segfault at 00000034a98d87e2 rip 00000034cb043fbb rsp 00007fff92aca2e
0 error 4
Comment 8 Miloslav Trmač 2007-03-29 16:25:28 EDT
Thanks.  Let's try one more gdb session:

* start pup
* when the password prompt is displayed, switch to a virtual terminal.
* find out the PID of a running "userhelper" process
* run (gdb /usr/sbin/userhelper the_pid_found_above)
* Enter a "set follow-fork-mode child" command.
* Enter a "continue" command.  Leave gdb running.
* Then switch back to X and enter the root password.
* Switch back to the terminal where gdb is running
* If gdb reports "Program recieved signal ..." or something similar, enter
  a "bt" command to get a backtrace.

If this doesn't produce anything either, please:
* start pup
* when the password prompt is displayed, switch to a virtual terminal.
* find out the PID of a running "userhelper" process
* run (strace -ff -o log -p the_pid_found_above)
* Then switch back to X and enter the root password.
* Switch back to the terminal
* if strace is still running, terminate it
* search the generated log* files for your root password; if you find it,
  make sure to replace it by some other string
* attach all the generated log* files.
Comment 9 Gianluca Cecchi 2007-03-31 08:07:26 EDT
Created attachment 151348 [details]
userhelper gdb session log
Comment 10 Gianluca Cecchi 2007-04-01 03:00:55 EDT
Created attachment 151373 [details]
log of process found in previous pup.log session
Comment 11 Gianluca Cecchi 2007-04-01 03:02:30 EDT
Created attachment 151374 [details]
log for pid 4366 see previous pup.log attach
Comment 12 Gianluca Cecchi 2007-04-01 03:03:20 EDT
Created attachment 151375 [details]
log for pid 4367 see previous pup.log attach
Comment 13 Gianluca Cecchi 2007-04-01 03:04:44 EDT
Created attachment 151376 [details]
log for pid 4368 see previous pup.log attach
Comment 14 Gianluca Cecchi 2007-04-01 03:09:55 EDT
ok. Attached gdb session.
the set follow-fork-mode child produced nothing usefuls, so I went with the
second option. I attached alla the log files produced, as you asked.
HIH understand better.
Gianluca
Comment 15 Miloslav Trmač 2007-04-02 15:38:31 EDT
Thanks.  Attachment 151376 [details] demonstrates that the crash is in pup;  the gdb
session in comment 2 was probably debugging consolehelper.
Comment 16 Jeremy Katz 2007-04-02 15:45:52 EDT
What's the output of 'rpm -V pirut'?
Comment 17 Gianluca Cecchi 2007-04-02 16:10:21 EDT
[gcecchi@localhost Temp]$ rpm -V pirut
[gcecchi@localhost Temp]$ echo $?
0
[gcecchi@localhost Temp]$ rpm -q pirut
pirut-1.2.8-1.fc6.noarch
[gcecchi@localhost Temp]$ rpm -V usermode
S.?.....   /usr/sbin/userhelper
[gcecchi@localhost Temp]$ ll /usr/sbin/userhelper
-rws--x--x 1 root root 38560 Oct  3 11:08 /usr/sbin/userhelper

downloaded the two rpms
[root@localhost ~]# rpm -Uvh --force usermode-1.87-3.x86_64.rpm
/home/gcecchi/pirut-1.2.8-1.fc6.noarch.rpm 
Preparing...                ########################################### [100%]
   1:pirut                  ########################################### [ 50%]
   2:usermode               ########################################### [100%]
[root@localhost ~]# 
Now
[gcecchi@localhost Temp]$ ll /usr/sbin/userhelper
-rws--x--x 1 root root 34336 Oct  3 11:08 /usr/sbin/userhelper
[gcecchi@localhost Temp]$ rpm -V usermode
..?.....   /usr/sbin/userhelper

I don't understand the ? for the md5sum field....
It seems that the segfault stiil remains..
In dmesg I get
pup[16231]: segfault at 00000034a98d87e2 rip 00000034cb043fbb rsp
00007fff79d8a5a0 error 4

I'm going to further check all rpms on the system and retry debug.

Comment 18 Gianluca Cecchi 2007-04-02 17:53:35 EDT
I forced fsck with a touch of /forcefsck and rebooted.
No errors showed.
Now rpm -V of pirut and userhelper give no error (run as root; I didn't know the
difference of third field when run by a non root user...)
[valeria@localhost ~]$ rpm -V usermode pirut
..?.....   /usr/sbin/userhelper
[valeria@localhost ~]$ su -
Password: 
[root@localhost ~]# rpm -V usermode pirut
[root@localhost ~]# 

I have the same error and I tried to gdb both pup and userhelper

I'm going to attach them as pup.log and userhelper.log.

Comment 19 Gianluca Cecchi 2007-04-02 17:54:58 EDT
Created attachment 151483 [details]
gdb session of pup process
Comment 20 Gianluca Cecchi 2007-04-02 17:56:10 EDT
Created attachment 151485 [details]
gdb session for userhelper process
Comment 21 Gianluca Cecchi 2007-04-02 17:59:07 EDT
the output for dmesg and in /var/log/messages is always:
Apr  2 23:43:04 localhost kernel: pup[5983]: segfault at 00000034a98d87e2 rip
00000034cb043fbb rsp 00007fff8ffe6800 error 4

I don't know if 5983 stands for a process...
The pup I debugged had pid 5917 and userhelper.log 5918
Comment 22 Gianluca Cecchi 2007-04-28 15:52:52 EDT
I close the bug, because updating the machine to f7 test4 caused the problem to
go away.

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