ofono crash (setting offline while connected)

ofono crash (setting offline while connected)

[Amit Mendapara]

[-- Attachment #1: Type: text/plain, Size: 583 bytes --]

Hi,

While testing the Linktop driver I observed that ofono is crashing if I try
to set modem offline while it is connected (using test/offline-modem.py
script). After some debugging, I found that `linktop_disconnect` function is
being called twice (see the attached debug log).

What could be the reason here? I have seen some hack in mbm driver (in
mbm_disconnect) having `reopen_callback`. I have tried this but then having
another crash (this time when creating gprs context). Anyone, please clarify
how to deal with the issue properly?

Regards
--
Amit Mendapara

[-- Attachment #2: attachment.html --]
[-- Type: text/html, Size: 662 bytes --]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: ofono.log --]
[-- Type: text/x-log, Size: 3421 bytes --]

...
ofonod[16892]: Control: < \r\nOK\r\n\r\n+CIEV: 5,1\r\n\r\n+CIEV: 9,0\r\n
ofonod[16892]: Control: > AT+COPS?\r
ofonod[16892]: Control: < \r\n+COPS: 0,2,"40457",2 \r\n\r\nOK\r\n
ofonod[16892]: Control: > AT+CIND?\r
ofonod[16892]: Control: < \r\n+CIND: 1,3,1,0,1,0,0,0,0,0,0,0\r\n\r\nOK\r\n
ofonod[16892]: Control: > AT+COPS=3,0\r
ofonod[16892]: Control: < \r\nOK\r\n
ofonod[16892]: Control: > AT+COPS?\r
ofonod[16892]: Control: < \r\n+COPS: 0,0,"",2 \r\n\r\nOK\r\n\r\n+CIEV: 2,2\r\n
ofonod[16892]: Control: < \r\n+CIEV: 2,3\r\n
ofonod[16892]: Control: < \r\n+CIEV: 2,2\r\n
ofonod[16892]: Control: < \r\n+CIEV: 2,3\r\n
ofonod[16892]: Modem: > AT+CGDCONT=1,"IP","bsnlnet"\r
ofonod[16892]: Modem: < AT+CGDCONT=1,"IP","bsnlnet"\r
ofonod[16892]: Modem: < \r\nOK\r\n
ofonod[16892]: Modem: > AT+CGDATA="PPP",1\r
ofonod[16892]: Modem: < AT+CGDATA="PPP",1\r
ofonod[16892]: Modem: < \r\nCONNECT\r\n
Entering new phase: 1
Entering new phase: 2
Entering new phase: 3
ofonod[16892]: Control: < \r\n*EPSB: 3\r\n
ofonod[16892]: Control: < \r\n*EPSB: 5\r\n\r\n*EPSB: 6\r\n
ofonod[16892]: Control: < \r\n+CIEV: 2,2\r\n
Received IPCP NAK
Setting suggested ip addr
Setting suggested dns1
Setting suggested dns2
Entering new phase: 4
ofonod[16892]: IP: 10.163.90.180
ofonod[16892]: DNS: 218.248.240.134, 218.248.240.23
ofonod[16892]: Control: < \r\n+CIEV: 2,3\r\n
ofonod[16892]: Control: < \r\n+CIEV: 2,2\r\n
ofonod[16892]: Control: < \r\n*EPSB: 0\r\n
ofonod[16892]: Control: < \r\n+CIEV: 2,3\r\n
ofonod[16892]: Control: < \r\n*EPSB: 3\r\n
ofonod[16892]: Control: < \r\n*EPSB: 5\r\n\r\n*EPSB: 6\r\n
ofonod[16892]: Control: < \r\n+CIEV: 2,2\r\n
ofonod[16892]: Control: < \r\n+CIEV: 2,3\r\n
ofonod[16892]: Control: < \r\n+CIEV: 2,2\r\n
ofonod[16892]: Control: < \r\n+CIEV: 2,3\r\n
ofonod[16892]: Control: < \r\n*EPSB: 0\r\n
ofonod[16892]: Control: < \r\n*EPSB: 3\r\n
ofonod[16892]: Control: < \r\n*EPSB: 5\r\n\r\n*EPSB: 6\r\n
ofonod[16892]: Control: < \r\n*EPSB: 0\r\n
ofonod[16892]: plugins/linktop.c:linktop_set_online() modem 0xbf4ff0 offline
ofonod[16892]: Control: > AT+CFUN=4\r
Entering new phase: 5
ofonod[16892]: plugins/udev.c:remove_modem() /devices/virtual/net/ppp0
Entering new phase: 0
ofonod[16892]: plugins/linktop.c:linktop_disconnect() 
ofonod[16892]: plugins/linktop.c:open_device() Modem /dev/ttyACM0
ofonod[16892]: Reopened GPRS context channel
ofonod[16892]: Control: < \r\nOK\r\n\r\n+CGEV: NW DEACT "IP", "10.163.90.180", 1\r\n\r\n+CGEV: NW DEACT "IP", "10.163.90.180", 1\r\n
ofonod[16892]: Unregistered handle for channel 1: 0x10005
ofonod[16892]: plugins/linktop.c:linktop_disconnect() 
ofonod[16892]: Aborting (signal 11)
ofonod[16892]: ++++++++ backtrace ++++++++
ofonod[16892]: [0]: /lib/libpthread.so.0(+0xfb40) [0x7f0843a44b40]
ofonod[16892]: [1]: ./src/ofonod() [0x46ccce]
ofonod[16892]: [2]: ./src/ofonod() [0x46342c]
ofonod[16892]: [3]: /lib/libglib-2.0.so.0(+0x3f8fe) [0x7f0843ed38fe]
ofonod[16892]: [4]: /lib/libglib-2.0.so.0(+0x3ff35) [0x7f0843ed3f35]
ofonod[16892]: [5]: /lib/libglib-2.0.so.0(g_main_context_dispatch+0x263) [0x7f0843ed43b3]
ofonod[16892]: [6]: /lib/libglib-2.0.so.0(+0x442a8) [0x7f0843ed82a8]
ofonod[16892]: [7]: /lib/libglib-2.0.so.0(g_main_loop_run+0x195) [0x7f0843ed87b5]
ofonod[16892]: [8]: ./src/ofonod() [0x46b6c4]
ofonod[16892]: [9]: /lib/libc.so.6(__libc_start_main+0xfe) [0x7f08430bfd8e]
ofonod[16892]: [10]: ./src/ofonod() [0x40cb89]
ofonod[16892]: +++++++++++++++++++++++++++

Re: ofono crash (setting offline while connected)

[Denis Kenzior]

[-- Attachment #1: Type: text/plain, Size: 957 bytes --]

Hi Amit,

On 02/23/2011 11:07 PM, Amit Mendapara wrote:
> Hi,
> 
> While testing the Linktop driver I observed that ofono is crashing if I
> try to set modem offline while it is connected (using
> test/offline-modem.py script). After some debugging, I found that
> `linktop_disconnect` function is being called twice (see the attached
> debug log).
> 
> What could be the reason here? I have seen some hack in mbm driver (in
> mbm_disconnect) having `reopen_callback`. I have tried this but then
> having another crash (this time when creating gprs context). Anyone,
> please clarify how to deal with the issue properly?

Some of these modems HUP the tty for x seconds.  So if you try to open
them too fast, they will be HUPed again, leading to various issues.

When posting backtraces, please give them directly from gdb, or use the
backtrace script to 'prettify' them.  e.g.:

test/backtrace src/ofonod your_log

Regards,
-Denis

Re: ofono crash (setting offline while connected)

[Amit Mendapara]

[-- Attachment #1: Type: text/plain, Size: 1430 bytes --]

Hi Denis,

I tried several things but no luck. Here I am attaching the backtrace as you
suggested. What I found is, ofono crashes on
`ofono_gprs_context_remove(data->gc)` call when `linktop_disconnect` was
called second time. I am still not sure why `linktop_disconnect` is being
called twice in this case.

Regards
--
Amit Mendapara

On Thu, Feb 24, 2011 at 11:01 PM, Denis Kenzior <denkenz@gmail.com> wrote:

> Hi Amit,
>
> On 02/23/2011 11:07 PM, Amit Mendapara wrote:
> > Hi,
> >
> > While testing the Linktop driver I observed that ofono is crashing if I
> > try to set modem offline while it is connected (using
> > test/offline-modem.py script). After some debugging, I found that
> > `linktop_disconnect` function is being called twice (see the attached
> > debug log).
> >
> > What could be the reason here? I have seen some hack in mbm driver (in
> > mbm_disconnect) having `reopen_callback`. I have tried this but then
> > having another crash (this time when creating gprs context). Anyone,
> > please clarify how to deal with the issue properly?
>
> Some of these modems HUP the tty for x seconds.  So if you try to open
> them too fast, they will be HUPed again, leading to various issues.
>
> When posting backtraces, please give them directly from gdb, or use the
> backtrace script to 'prettify' them.  e.g.:
>
> test/backtrace src/ofonod your_log
>
> Regards,
> -Denis
>

[-- Attachment #2: attachment.html --]
[-- Type: text/html, Size: 1862 bytes --]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: backtrace.log --]
[-- Type: text/x-log, Size: 201 bytes --]

-------- backtrace --------
[0]: __ofono_atom_free() [modem.c:336]
[1]: linktop_disconnect() [linktop.c:147]
[2]: main() [main.c:245]
[3]: _start() [location-reporting.c:0]
---------------------------

Re: ofono crash (setting offline while connected)

[Denis Kenzior]

[-- Attachment #1: Type: text/plain, Size: 787 bytes --]

Hi Amit,

A gentle reminder not to post on this mailing list.

On 02/25/2011 11:51 PM, Amit Mendapara wrote:
> Hi Denis,
> 
> I tried several things but no luck. Here I am attaching the backtrace as
> you suggested. What I found is, ofono crashes on
> `ofono_gprs_context_remove(data->gc)` call when `linktop_disconnect` was
> called second time. I am still not sure why `linktop_disconnect` is
> being called twice in this case.

Sounds like you're encountering the same issue as
https://bugs.meego.com/show_bug.cgi?id=13679.  Basically when the modem
is put offline, the gprs atom and the context are removed automatically
by the core.  However, the modem driver does not clean up properly.

Please work with Martin to come up with a proper fix.

Regards,
-Denis