Hi Dan,
May nothing to do with the mentioned crash problem. Just want to discuss
about the codes. Any chance below scenario can happen for WIFI device?
src/nm-device.c
When device deactivate below function will be called:
gboolean nm_device_deactivate_quickly (NMDevice *self)
{
...
/* Tear down an existing activation request */
clear_act_request (self); <------ This function will clear
priv->act_request = NULL
return TRUE;
}
Then NM_DEVICE_STATE_FAILED state change occured for some reason.
src/nm-device-wifi.c
static void device_state_changed (...)
{
...
case NM_DEVICE_STATE_FAILED:
activation_failure_handler (device);
break;
...
}
static void activation_failure_handler (NMDevice *dev)
{
...
req = nm_device_get_act_request (dev);
g_assert (req); <------ This assert will fail and NetworkManager quit?
...
}
Thanks!!
2009/6/9 Dan Williams <[email protected]>
> On Tue, 2009-06-09 at 18:43 +0530, sanjeev sharma wrote:
> > Hi All,
> >
> > I have been observing a crash of Network Manager when experimenting
> > with the rf kill
> > switch. I was trying to flip the
> > switch before the previous switch state change had been fully processed
> by
> > software.
> >
> > These are the log messages i have been seeing
> >
> > daemon.warn NetworkManager: <WARN> nm_device_wifi_set_ssid(): error
> > setting SSID to '(null)' for device eth0: Input/output error
> >
> > daemon.warn NetworkManager: <WARN> wireless_get_range(): (eth0):
> > couldn't get driver range information (5).
> >
> > daemon.warn NetworkManager: <WARN> nm_supplicant_interface_add_cb():
> > Unexpected supplicant error getting interface: wpa_supplicant couldn't
> > grab this interface.
> >
> > daemon.warn NetworkManager: <WARN> nm_signal_handler(): Caught
> > signal 11. Generating backtrace...
>
> Can you gdb NM and get a backtrace where it crashes? Obviously we're
> not handling this case correctly, but it's a bit unclear exactly where
> the error is unless there's a better backtrace.
>
> The bits in question are in
> src/supplicant-manager/nm-supplicant-interface.c. We may need to add a
> signal to the supplicant interface object for something like "invalid",
> so that we know to tear down the supplicant interface object in NM when
> it cannot be added to the supplicant.
>
> But it actually looks like we should just fix the bug itself, since the
> rest of the code looks like it will handle re-configuring the interface
> when the device un-kills itself. Need the backtrace for that though.
>
> Dan
>
> > daemon.crit NetworkManager: ******************* START
> > **********************************
> > daemon.crit NetworkManager: Frame 0: [0xbeb20c4c]
> > May 29 12:08:07 (none) daemon.crit NetworkManager: *******************
> > END **********************************
> >
> >
> > would anybody through some pointer on it which causes segfault and how
> > to prevent it.
> >
> > Sanjeev
>
> _______________________________________________
> NetworkManager-list mailing list
> [email protected]
> http://mail.gnome.org/mailman/listinfo/networkmanager-list
>
_______________________________________________
NetworkManager-list mailing list
[email protected]
http://mail.gnome.org/mailman/listinfo/networkmanager-list
