Bug 481453

Lines from messages which may be symptoms, or tie into dbus, et al...

Jan 25 15:19:47 localhost kernel: dellWirelessCtl[7030]: segfault at 5f5f2720 ip 00d06201 sp bf8ff5d0 error 4 in _ctypes.so[cfa000+18000]
Jan 25 15:19:47 localhost NetworkManager: <WARN>  killswitch_getpower_reply(): Error getting killswitch power: /usr/lib/hal/scripts/linux/hal-system-killswitch-get-power-linux: line 112:  7030 Segmentation fault      $DELL_WCTL --st_wlan #012 org.freedesktop.Hal.Device.KillSwitch.NotSupported.
Jan 25 15:19:48 localhost dbus: Would reject message, 1 matched rules; type="method_call", sender=":1.33" (uid=500 pid=3064 comm="/usr/bin/python /usr/bin/guidance-power-manager ") interface="org.freedesktop.Hal.Device.CPUFreq" member="GetCPUFreqGovernor" error name="(unset)" requested_reply=0 destination=":1.0" (uid=0 pid=1877 comm="hald "))
Jan 25 15:19:53 localhost kernel: dellWirelessCtl[7044]: segfault at 5f5f2720 ip 00253201 sp bffdecc0 error 4 in _ctypes.so[247000+18000]
Jan 25 15:19:53 localhost NetworkManager: <WARN>  killswitch_getpower_reply(): Error getting killswitch power: /usr/lib/hal/scripts/linux/hal-system-killswitch-get-power-linux: line 112:  7044 Segmentation fault      $DELL_WCTL --st_wlan #012 org.freedesktop.Hal.Device.KillSwitch.NotSupported.
Jan 25 15:19:53 localhost dbus: Would reject message, 1 matched rules; type="method_call", sender=":1.33" (uid=500 pid=3064 comm="/usr/bin/python /usr/bin/guidance-power-manager ") interface="org.freedesktop.Hal.Device.CPUFreq" member="GetCPUFreqGovernor" error name="(unset)" requested_reply=0 destination=":1.0" (uid=0 pid=1877 comm="hald "))
Jan 25 15:19:58 localhost dbus: Would reject message, 1 matched rules; type="method_call", sender=":1.33" (uid=500 pid=3064 comm="/usr/bin/python /usr/bin/guidance-power-manager ") interface="org.freedesktop.Hal.Device.CPUFreq" member="GetCPUFreqGovernor" error name="(unset)" requested_reply=0 destination=":1.0" (uid=0 pid=1877 comm="hald "))

There is nothing to triage here.

Switching to ASSIGNED so that developers have responsibility to do whatever they want to do with it.

Heh, because the messages file hadn't filled up / lately, I'd lost track of this one.
But logwatch tells me it's still around:
 ################### Logwatch 7.3.6 (05/19/07) #################### 
        Processing Initiated: Tue Feb  3 06:06:42 2009
        Date Range Processed: yesterday
                              ( 2009-Feb-02 )
                              Period is day.
      Detail Level of Output: 0
              Type of Output: unformatted
           Logfiles for Host: walnut
  ################################################################## 
 
 --------------------- Kernel Begin ------------------------ 

 WARNING:  Segmentation Faults in these executables
    dellWirelessCtl :  13983 Time(s)

Sorry, missed this defect with all the spam in my inbox :(

I suspect this may be related to the other defect you have open (dellsysidplugin). Can you attach the debugging info requested there (or to this bz#)

Thanks

One idea. The last segfault that I fixed was in version 2.2.7 and only happened
if the "dcdbas" kernel module was not installed.

Can you check lsmod to see if dcdbas is loaded? If not, try 'modprobe dcdbas'
to see if the problem goes away. If that is it, then I should be able to fix
the segfault. (I've tested locally, and dellWirelessCtl works for me with
dcdbas loaded, and gives a reasonable error message if dcdbas is not loaded.)

Regardless of the above, the following should help me track down the error if
it is still segfaulting:

LIBSMBIOS_C_DEBUG_OUTPUT_ALL=1 dellWirelessCtl --st_wlan > stdout.txt
2>stderr.txt

Thanks

Created attachment 330965 [details]
stderr.txt (latD600)

dcdbas is loaded at the time of command:
[root@walnut tmp]# LIBSMBIOS_C_DEBUG_OUTPUT_ALL=1 dellWirelessCtl --st_wlan > stdout.txt 2>stderr.txt
[root@walnut tmp]# lsmod | grep dcd
dcdbas                  6720  0

Created attachment 330966 [details]
stdout.txt (latD600)

This doesnt appear to be segfaulting. Can you confirm that dellWirelessCtl no longer segfaults? If so, I think we can close this bug.

True, the command above didn't segfault, but the kernel errors continue:

Feb  5 12:58:38 localhost kernel: dellWirelessCtl[25431]: segfault at 5f5f2720 ip
 00861201 sp bfa096e0 error 4 in _ctypes.so[855000+18000]
Feb  5 12:58:38 localhost NetworkManager: <WARN>  killswitch_getpower_reply(): 
Error getting killswitch power: /usr/lib/hal/scripts/linux/hal-system-killswitch-
get-power-linux: line 112: 25431 Segmentation fault      $DELL_WCTL --st_wlan 
#012 org.freedesktop.Hal.Device.KillSwitch.NotSupported.
Feb  5 12:58:41 localhost dbus: Would reject message, 1 matched rules; 
type="method_call", sender=":1.31" (uid=500 pid=2603 comm="/usr/bin/python 
/usr/bin/guidance-power-manager ") interface="org.freedesktop.Hal.Device.CPUFreq"
 member="GetCPUFreqGovernor" error name="(unset)" requested_reply=0 
destination=":1.0" (uid=0 pid=1897 comm="hald "))
Feb  5 12:58:44 localhost kernel: dellWirelessCtl[25435]: segfault at 5f5f2720 ip 
00c86201 sp bfef6bd0 error 4 in _ctypes.so[c7a000+18000]
Feb  5 12:58:44 localhost NetworkManager: <WARN>  killswitch_getpower_reply(): 
Error getting killswitch power: /usr/lib/hal/scripts/linux/hal-system-killswitch-
get-power-linux: line 112: 25435 Segmentation fault      $DELL_WCTL --st_wlan 
#012 org.freedesktop.Hal.Device.KillSwitch.NotSupported.
Feb  5 12:58:46 localhost dbus: Would reject message, 1 matched rules; 
type="method_call", sender=":1.31" (uid=500 pid=2603 comm="/usr/bin/python 
/usr/bin/guidance-power-manager ") interface="org.freedesktop.Hal.Device.CPUFreq"
 member="GetCPUFreqGovernor" error name="(unset)" requested_reply=0 
destination=":1.0" (uid=0 pid=1897 comm="hald "))

Ok, so another idea.

At the top of /usr/lib64/hal/scripts/linux/hal-system-killswitch-set-power-linux

add an "export LIBSMBIOS_C_DEBUG_OUTPUT_ALL=1"

And then on each of the $DELL_WCTL calls add an "> /tmp/logfile.txt 2>&1"

And see if it still segfaults. And if it still does, the data I need should be in /tmp/logfile.txt. 

The other option is to figure out a way to get dellWirelessCtl to segfault when running from the cmdline.

Redireected output of both stdin and stdout from within /usr/lib/hal/scripts/linux/hal-system-killswitch-get-power-linux just create empty files.

Created attachment 331889 [details]
selinux alert description

I am also seeing this segfault, and I think it's an selinux policy problem.  I'm attaching the alert log from my system in hopes that it helps identify the core issue.

When I put selinux in permissive mode, then the dellWirelessCtl segfaults go away.  I still get the alerts, but much less frequently.

re-assigning to selinux-policy component so that somebody in selinux can take a look at this.

Libsmbios does not itself do anything to require executable memory that I know of, so I expect that this bug is likely something to do with python or ctypes.

This is not an SELInux issue.

dellWirelessCtl or one of the libraries it is using is trying to set memory both writable and executable.

Does this use assembly code?

Nothing in any of the code paths executed here do any assembly. There is nothing in libsmbios that does anything with anything that would require execmem.

I suspect it may be something in the python ctypes module. The dellWirelessCtl program is a python script that uses python ctypes to run code from libsmbios.so.1.

This might be related to this bug:

https://bugzilla.redhat.com/show_bug.cgi?id=251637

Looks promising.

fwiw, I get something similar...

Feb 18 20:35:47 c640 setroubleshoot: SELinux is preventing dellWirelessCtl (hald_t) "execmem" hald_t. For complete SELinux messages. run sealert -l fbd6c3be-617e-4a62-8d87-13dbb81da8c1
Feb 18 20:35:51 c640 kernel: dellWirelessCtl[5689]: segfault at 5f5f2720 ip 002e4201 sp bfb017e0 error 4 in _ctypes.so[2d8000+18000]

this is on current rawhide...and it's a Dell Latitude C640

I see the same problem (segfault + SELinux alert) on a Dell Latitude D600 on the latest Rawhide, and I'm happy to help troubleshoot the problem if needed.

it might be interesting, or irrelevant, but here's what I get 

[root@c640 ~]# sealert -l fbd6c3be-617e-4a62-8d87-13dbb81da8c1

Summary:

SELinux is preventing dellWirelessCtl (hald_t) "execmem" hald_t.

Detailed Description:

SELinux denied access requested by dellWirelessCtl. It is not expected that this
access is required by dellWirelessCtl and this access may signal an intrusion
attempt. It is also possible that the specific version or configuration of the
application is causing it to require additional access.

Allowing Access:

You can generate a local policy module to allow this access - see FAQ
(http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385) Or you can disable
SELinux protection altogether. Disabling SELinux protection is not recommended.
Please file a bug report (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi)
against this package.

Additional Information:

Source Context                system_u:system_r:hald_t:s0
Target Context                system_u:system_r:hald_t:s0
Target Objects                None [ process ]
Source                        dellWirelessCtl
Source Path                   /usr/bin/python
Port                          <Unknown>
Host                          c640.lucky.net
Source RPM Packages           python-2.6-4.fc11
Target RPM Packages           
Policy RPM                    selinux-policy-3.6.6-5.fc11
Selinux Enabled               True
Policy Type                   targeted
MLS Enabled                   True
Enforcing Mode                Enforcing
Plugin Name                   catchall
Host Name                     c640.lucky.net
Platform                      Linux c640.lucky.net
                              2.6.29-0.137.rc5.git4.fc11.i586 #1 SMP Thu Feb 19
                              21:02:06 EST 2009 i686 i686
Alert Count                   42549
First Seen                    Sat Feb 14 08:35:21 2009
Last Seen                     Sun Feb 22 07:54:56 2009
Local ID                      fbd6c3be-617e-4a62-8d87-13dbb81da8c1
Line Numbers                  

Raw Audit Messages            

node=c640.lucky.net type=AVC msg=audit(1235285696.311:448): avc:  denied  { execmem } for  pid=5581 comm="dellWirelessCtl" scontext=system_u:system_r:hald_t:s0 tcontext=system_u:system_r:hald_t:s0 tclass=process

node=c640.lucky.net type=SYSCALL msg=audit(1235285696.311:448): arch=40000003 syscall=192 success=no exit=-13 a0=0 a1=ff0 a2=7 a3=22 items=0 ppid=5578 pid=5581 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="dellWirelessCtl" exe="/usr/bin/python" subj=system_u:system_r:hald_t:s0 key=(null)

Note that it was *first seem Sat Feb 14* as stated above, and note also that the system was initiated on Feb 10.

I get these messages during boot.  To work around the problem I had to use the ctl-alt-F? keys to login and turn off network manager.  I then had to go edit the ifcfg-eth0 (my wired interface) and add in the ONBOOT, BOOTPROTO, NM_CONTROLLED and TYPE entries by hand.  After I rebooted the problem did no occur.

My system is a Dell Inspiron 8600 which has both a wired and a wireless interface and Network Manager does not seem to be smart enough to only bring up the wired interface not both.

After all this my system is still fairly useless since gdm fails to start.

(In reply to comment #21)
> I get these messages during boot.  To work around the problem I had to use the
> ctl-alt-F? keys to login and turn off network manager.  I then had to go edit
> the ifcfg-eth0 (my wired interface) and add in the ONBOOT, BOOTPROTO,
> NM_CONTROLLED and TYPE entries by hand.  After I rebooted the problem did no
> occur.

And you set those variables to what?
Also, please check /var/log/messages, as the boot message may go away, but I fail to see how the above prevents the actual problem.

Here's the ifcfg-eth0 file

# Broadcom Corporation BCM4401 100Base-T
DEVICE=eth0
HWADDR=00:0d:56:36:eb:13
ONBOOT=yes
BOOTPROTO=dhcp
NM_CONTROLLED=no
TYPE=Ethernet

The other interface eth1

# Intel Corporation PRO/Wireless LAN 2100 3B Mini PCI Adapter
DEVICE=eth1
HWADDR=00:04:23:6a:8e:1b


The reason it stops the problem from occurring is because Network Manager is no longer responsible for bringing up my network interfaces. When NM starts up it tries to bring up both my wired and my wireless interfaces. With NM disabled, and going back to the old way of starting/stopping interfaces via ifup/ifdown, the wireless interface no longer starts up so no more problem. As long as NM was trying to bring up the wireless interface the messages would continue to get displayed.  Now only the wired interface is started.

Neat. I've re-installed this machine from scratch (F10 CD's, then to rawhide via yum). Now, I can't reproduce this bug. Requesting help from those cc'd that can. Maybe between us we can figure out the difference - recent rawhide updates, selinux restorecon (which I've done on this system), /.autorelabel, or whatever.

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

FWIW, it works for me again now, no failures like this...

Closing this now as RAWHIDE. Please, anybody, if you are able to reproduce this, please reopen with additional information.

Thank you

Yes, I can reproduce this on rawhide.

 $ dellWirelessCtl 
Traceback (most recent call last):
  File "/usr/bin/dellWirelessCtl", line 32, in <module>
    import cli
  File "/usr/share/smbios-utils/cli.py", line 7, in <module>
    from libsmbios_c import memory, smi, cmos, pkgconfdir, localedir, GETTEXT_PACKAGE
  File "/usr/lib/python2.6/site-packages/libsmbios_c/__init__.py", line 9, in <module>
    import ctypes
  File "/usr/lib64/python2.6/ctypes/__init__.py", line 546, in <module>
    CFUNCTYPE(c_int)(lambda: None)
MemoryError



Also see bug #488396.

This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Since this bugzilla report was filed, there have been several major updates in various components of the Xorg system, which may have resolved this issue. Users who have experienced this problem are encouraged to upgrade their system to the latest version of their packages. For packages from updates-testing repository you can use command

yum upgrade --enablerepo='*-updates-testing'

Alternatively, you can also try to test whether this bug is reproducible with the upcoming Fedora 12 distribution by downloading LiveMedia of F12 Beta available at http://alt.fedoraproject.org/pub/alt/nightly-composes/ . By using that you get all the latest packages without need to install anything on your computer. For more information on using LiveMedia take a look at https://fedoraproject.org/wiki/FedoraLiveCD .

Please, if you experience this problem on the up-to-date system, let us now in the comment for this bug, or whether the upgraded system works for you.

If you won't be able to reply in one month, I will have to close this bug as INSUFFICIENT_DATA. Thank you.

[This is a bulk message for all open Fedora Rawhide Xorg-related bugs. I'm adding myself to the CC list for each bug, so I'll see any comments you make after this and do my best to make sure every issue gets proper attention.]

I can no longer reproduce this on either fc11 or fc12 (rawhide).

Thank you for letting us know.