AW: Ofono 1.21 crashes with Sierra MC7455

Jonas Bonn jonas at southpole.se
Thu Oct 26 03:31:09 PDT 2017


On 10/26/2017 11:14 AM, Jonas Bonn wrote:
> On 10/26/2017 11:04 AM, Jonas Bonn wrote:
>> On 10/26/2017 10:55 AM, Jonas Bonn wrote:
>>> On 10/26/2017 10:48 AM, Eswaran Vinothkumar (BEG/PJ-IOT-EL) wrote:
>>>>
>>>> May I know is there any config option to disable the signal handler 
>>>> in Ofono.
>>>>
>>> No, there's not... you need to hack it out of the code. Search for 
>>> the following line in src/main.c:
>>>
>>> signal = setup_signalfd();
>>>
>>> and comment it out.  I think that's sufficient...
>>
>> Sorry, that was wrong.  It's signal_setup() in src/log.c that needs 
>> to be adjusted.  Just put a 'return' at the beginning of that 
>> function so that it becomes a no-op.
>>
>> /Jonas
>>
> Here's a backtrace from the crasher that I'm seeing.  I suspect it's 
> the same issue you have:
>
> #0  0x00007ffa4c7a316e in g_queue_remove ()
>    from /lib/x86_64-linux-gnu/libglib-2.0.so.0
> #1  0x00005624b81441b9 in __qmi_device_discovery_complete 
> (d=0x5624b95bcd40,
>     device=<optimized out>) at drivers/qmimodem/qmi.c:889
> #2  0x00005624b8144d21 in handle_packet (buf=<optimized out>,
>     hdr=<optimized out>, device=0x5624b95bcc90) at 
> drivers/qmimodem/qmi.c:817
> #3  received_data (user_data=0x5624b95bcc90, cond=<optimized out>,
>     channel=<optimized out>) at drivers/qmimodem/qmi.c:865
> #4  0x00007ffa4c79168a in g_main_context_dispatch ()
>    from /lib/x86_64-linux-gnu/libglib-2.0.so.0
> #5  0x00007ffa4c791a40 in ?? () from 
> /lib/x86_64-linux-gnu/libglib-2.0.so.0
> #6  0x00007ffa4c791d62 in g_main_loop_run ()
>    from /lib/x86_64-linux-gnu/libglib-2.0.so.0
> #7  0x00005624b8107e77 in main (argc=<optimized out>, argv=<optimized 
> out>)
>     at src/main.c:306
>
> /Jonas

Seems to be this:

i)  When the modem is first powered on, service discovery takes some 
time (more than 5 seconds)
ii)  The service discovery timeout fires before the QMI request returns 
so discover_reply gets called before discover_callback and things get 
cleaned up
iii)  Then the QMI request returns and discover_callback gets called 
even though the request has timed out in ii)

...and this is where things go wrong because the userdata pointer to 
discover_callback is probably no longer valid.

How do we handle the QMI request returning a _late_ response, i.e. after 
it technically has timed out?  I'll dig a bit more...

/Jonas

>
>
>
>>
>>
>> _______________________________________________
>> ofono mailing list
>> ofono at ofono.org
>> https://lists.ofono.org/mailman/listinfo/ofono
>
>
>
>
> _______________________________________________
> ofono mailing list
> ofono at ofono.org
> https://lists.ofono.org/mailman/listinfo/ofono


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ofono.org/pipermail/ofono/attachments/20171026/ef7fa315/attachment.html>


More information about the ofono mailing list