Random ofono crash in network-registration
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
ofono (Ubuntu) |
Fix Released
|
Undecided
|
Tony Espy |
Bug Description
Dave Morley reported a couple of bugs today with mobile data connections dropping after a few hours. His testing was done with system image #70 on a maguro phone. He also was running a test version of NetworkManager ( version: to-be-filled-in ) which had fixes to the mobile-data reconnect logic.
While gathering data for these bugs, he noticed an ofono crash file in /var/crash.
Here's the output of decoded backtrace:
root@ubuntu-
GNU gdb (GDB) 7.6-ubuntu
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "arm-linux-
For bug reporting instructions, please see:
<http://
Reading symbols from /usr/sbin/
done.
[New LWP 1029]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-
Core was generated by `ofonod -p ril,rilmodem,
Program terminated with signal 11, Segmentation fault.
#0 ril_register_cb (message=0xa44d48, user_data=0xa43290)
at drivers/
371 drivers/
#0 ril_register_cb (message=0xa44d48, user_data=0xa43290)
at drivers/
cbd = 0xa43290
cb = 0x74215 <register_callback>
nd = 0x0
error = {type = OFONO_ERROR_
#1 0x0001aa04 in handle_response (message=0xa44d48, p=0xa3d200)
at gril/gril.c:366
count = 12
i = <optimized out>
req = 0xa46000
found = 1
#2 dispatch (message=0xa44d48, p=<optimized out>) at gril/gril.c:509
data_len = <optimized out>
bufp = <optimized out>
datap = <optimized out>
#3 new_bytes (rbuf=0xa35790, user_data=0xa3d200) at gril/gril.c:607
rbytes = <optimized out>
p = 0xa3d200
len = 16
wrap = 16
buf = 0xa3d2d0 "c"
#4 0x0001b4ae in received_data (channel=0xa3d090, cond=G_IO_IN,
data=0xa3d270) at gril/grilio.c:124
buf = <optimized out>
io = <optimized out>
status = G_IO_STATUS_AGAIN
rbytes = 0
toread = <optimized out>
total_read = 16
read_count = 2
#5 0x40184b6a in g_main_
from /lib/arm-
No symbol table info available.
#6 0x40184dca in ?? () from /lib/arm-
No symbol table info available.
#7 0x40184dca in ?? () from /lib/arm-
No symbol table info available.
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
Thread 1 (Thread 0x401112b0 (LWP 1029)):
#0 ril_register_cb (message=0xa44d48, user_data=0xa43290)
at drivers/
cbd = 0xa43290
cb = 0x74215 <register_callback>
nd = 0x0
error = {type = OFONO_ERROR_
#1 0x0001aa04 in handle_response (message=0xa44d48, p=0xa3d200)
at gril/gril.c:366
count = 12
i = <optimized out>
req = 0xa46000
found = 1
#2 dispatch (message=0xa44d48, p=<optimized out>) at gril/gril.c:509
data_len = <optimized out>
bufp = <optimized out>
datap = <optimized out>
#3 new_bytes (rbuf=0xa35790, user_data=0xa3d200) at gril/gril.c:607
rbytes = <optimized out>
p = 0xa3d200
len = 16
wrap = 16
buf = 0xa3d2d0 "c"
#4 0x0001b4ae in received_data (channel=0xa3d090, cond=G_IO_IN,
data=0xa3d270) at gril/grilio.c:124
buf = <optimized out>
io = <optimized out>
status = G_IO_STATUS_AGAIN
rbytes = 0
toread = <optimized out>
total_read = 16
read_count = 2
#5 0x40184b6a in g_main_
from /lib/arm-
No symbol table info available.
#6 0x40184dca in ?? () from /lib/arm-
No symbol table info available.
#7 0x40184dca in ?? () from /lib/arm-
No symbol table info available.
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
Related branches
- Tony Espy: Approve
- PS Jenkins bot: Approve (continuous-integration)
-
Diff: 867 lines (+277/-149)7 files modifieddrivers/rilmodem/call-volume.c (+3/-0)
drivers/rilmodem/network-registration.c (+5/-0)
gril/gril.c (+96/-70)
gril/grilrequest.c (+16/-0)
gril/grilrequest.h (+4/-0)
plugins/ril.c (+99/-79)
unit/test-grilrequest.c (+54/-0)
Changed in ofono (Ubuntu): | |
assignee: | nobody → Tony Espy (awe) |
Changed in ofono (Ubuntu): | |
status: | New → In Progress |
I still haven't been able to reproduce this yet, but will try tomorrow.
Also, based on inspecting the code, this might be related to the delay registration technique used by most of the rilmodem modules.