Hi Samuel,
> De : Samuel Ortiz
>
> Hi Benoit,
>
> On Tue, Dec 07, 2010 at 06:04:18PM +0100, "Benoît Monin" wrote:
[snip]
> >
> > I can post the full syslog or run some other tests if needed.
> The full syslog would be a good start.
>
Full syslog from power-up to crash is here :
http://pastebin.com/raw.php?i=sU7CxpkN
The test was (the steps are indicated in the log):
- power-up
- run /usr/lib/ofono/test/activate-context
- set gsm antenna attenuator to -60dB to force a gsm signal loss
- set gsm antenna attenuator back to 0dB
- run again /usr/lib/ofono/test/activate-context
- connman crash happens here
The actual domainname, apn, PAP username and password have been replaced,
to avoid publishing details of our infrastructure.
>
> > I'll try to reproduce the bug differently, it seems to be related
> > to gateway management.
> Can you reliably reporduce it ? If so, running connmand through gdb would be
> useful as well. The gdb backtraces are usually more useful than our custom
> ones.
>
It happens almost every time with the above test. Here is the gdb backtrace :
#0 __connman_element_get_service (element=0x6f72702e) at src/element.c:198
#1 0x0805dedb in update_order () at src/connection.c:464
#2 __connman_connection_update_gateway () at src/connection.c:475
#3 0x0806047a in __connman_profile_changed (delayed=1) at src/profile.c:182
#4 0x08061abc in service_register (service=0x889fce8) at src/service.c:3613
#5 0x080641e6 in __connman_service_create_from_network (network=0x889e4b8) at
src/service.c:4023
#6 0x0806041b in __connman_profile_add_network (network=0x889e4b8) at
src/profile.c:201
#7 0x0805c5da in network_probe (element=0x889e4b8) at src/network.c:1557
#8 0x08059324 in probe_element (element=0x889e4b8) at src/element.c:1005
#9 0x0805a45a in register_element (element=0x889e4b8, parent=0x889e5e0) at
src/element.c:1044
#10 connman_element_register (element=0x889e4b8, parent=0x889e5e0) at
src/element.c:1115
#11 0x0805b21e in connman_device_add_network (device=0x889e5e0,
network=0x889e4b8) at src/device.c:998
#12 0xb7508a3e in ?? ()
#13 0xb76ae54a in _dbus_pending_call_complete () from
/home/e_bmonin/factory/factory/build_i686-timesys-linux-gnu/toolchain/usr/lib/libdbus-1.so.3
#14 0xb76a19c1 in complete_pending_call_and_unlock () from
/home/e_bmonin/factory/factory/build_i686-timesys-linux-gnu/toolchain/usr/lib/libdbus-1.so.3
#15 0xb76a39bf in dbus_connection_dispatch () from
/home/e_bmonin/factory/factory/build_i686-timesys-linux-gnu/toolchain/usr/lib/libdbus-1.so.3
#16 0x080519ef in message_dispatch (data=0x8896200) at gdbus/mainloop.c:80
#17 0xb76f56b9 in g_timeout_dispatch () from
/home/e_bmonin/factory/factory/build_i686-timesys-linux-gnu/toolchain/usr/lib/libglib-2.0.so.0
#18 0xb76f4e0d in g_main_context_dispatch () from
/home/e_bmonin/factory/factory/build_i686-timesys-linux-gnu/toolchain/usr/lib/libglib-2.0.so.0
#19 0xb76f6e14 in g_main_context_iterate () from
/home/e_bmonin/factory/factory/build_i686-timesys-linux-gnu/toolchain/usr/lib/libglib-2.0.so.0
#20 0xb76f7dce in g_main_loop_run () from
/home/e_bmonin/factory/factory/build_i686-timesys-linux-gnu/toolchain/usr/lib/libglib-2.0.so.0
#21 0x08057e75 in main (argc=1, argv=0xbfd6ae84) at src/main.c:260
I noticed that the routes set up by connman when both eth0 and hso1 are
connected can differ :
route -n with eth0 and hso1
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 0.0.0.0 255.255.255.255 UH 0 0 0 hso1
10.23.208.1 0.0.0.0 255.255.255.255 UH 0 0 0 eth0
10.23.208.0 0.0.0.0 255.255.240.0 U 0 0 0 eth0
0.0.0.0 10.23.208.1 0.0.0.0 UG 0 0 0 eth0
or:
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 0.0.0.0 255.255.255.255 UH 0 0 0 hso1
10.23.208.1 0.0.0.0 255.255.255.255 UH 0 0 0 eth0
10.23.208.0 0.0.0.0 255.255.240.0 U 0 0 0 eth0
0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 hso1
0.0.0.0 10.23.208.1 0.0.0.0 UG 0 0 0 eth0
or:
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 0.0.0.0 255.255.255.255 UH 0 0 0 hso1
10.23.208.0 0.0.0.0 255.255.240.0 U 0 0 0 eth0
0.0.0.0 10.23.208.1 0.0.0.0 UG 0 0 0 eth0
I also tried to reproduce the bug with ethernet devices. eth0 is still
connected to our internal network and eth1 is plugged to a switch with
nothing else connected on it. The configuration is:
eth0 dhcp 10.23.219.21 / 255.255.240.0 gw 10.23.208.1
eth1 manual 10.248.160.97 / 255.255.255.255 gw 0.0.0.0
Unplugging and plugging back eth1 cable did not crash connmand. I also
tried other configuration for eth1 with different netmasks and gateways,
no crash either.
route -n with eth1 unplugged:
Destination Gateway Genmask Flags Metric Ref Use Iface
10.23.208.1 0.0.0.0 255.255.255.255 UH 0 0 0 eth0
10.23.208.0 0.0.0.0 255.255.240.0 U 0 0 0 eth0
0.0.0.0 10.23.208.1 0.0.0.0 UG 0 0 0 eth0
route -n with eth1 plugged:
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 0.0.0.0 255.255.255.255 UH 0 0 0 eth1
10.23.208.1 0.0.0.0 255.255.255.255 UH 0 0 0 eth0
10.23.208.0 0.0.0.0 255.255.240.0 U 0 0 0 eth0
0.0.0.0 10.23.208.1 0.0.0.0 UG 0 0 0 eth0
I'll continue digging with gdb and valgrind. If you think there are
other tests I should try, please let me know.
> Cheers,
> Samuel.
>
--
Thanks for your reply,
Benoît.
_______________________________________________
connman mailing list
[email protected]
http://lists.connman.net/listinfo/connman
