ZTE MF683

[Aleksander Morgado]

Hey Shawn,

>> > Here are my CLFAGS; it has -O0, -ggdb, and -DMESSAGE_ENABLE_TRACE.
>> > 
>> > CFLAGS = -DMESSAGE_ENABLE_TRACE -Wall -std=gnu89  -pipe -ggdb -O0
>> > -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64
>> > -Wmissing-declarations -Wmissing-prototypes
>> > -Wdeclaration-after-statement -Wstrict-prototypes -fno-strict-aliasing
>> > -Wno-deprecated-declarations -Wint-to-pointer-cast -Wfloat-equal
>> > -Wno-unused-parameter -Wno-sign-compare -Wundef
>> > -Wimplicit-function-declaration -Wpointer-arith -Winit-self -Wshadow
>> > -Wmissing-include-dirs -Waggregate-return -Werror
>> > 
> CFLAGS are ok now; but did you see the traces printed when running the
> qmicli command with "--verbose"? Those are the ones we would need.
> 
>> > 
>> > Below is another session. First, I tried looking at buffer_size so I
>> > could run a backtrace before the assersion failed; that didn't work.
>> > Somehow the assersion failed even when buffer_size was >=1. Then I
>> > just ran a backtrace every time that function was called.
>> > 
> Once you get the whole trace of what was received we can probably
> reproduce the issue with a unit test; are you able to get the debug logs
> and post them?
> 

I just fixed an issue when creating QMI messages from a raw data buffer
(commit ec138d4f8d74c3c3bc5b3989d927d63f48c4386c). The code wasn't
properly ensuring that the whole message was available in the buffer,
which results in high chances of getting errors like yours if the
message is read slowly (e.g. one byte at a time).

Are you able to test with latest git master and see if the new fix helps
in your error case?

Cheers,

-- 
Aleksander