On Tue, 5 Jun 2018 01:58:48 -0400, Rich Felker <dalias@...c.org> wrote:
>On Tue, Jun 05, 2018 at 11:24:34AM +0800, 徐露 wrote:
>> 
>> Mon, 4 Jun 2018 05:41:29 -0400, Rich Felker <dalias@...c.org> wrote:
>> > Looks like classic double-free.
>> The program crashes randomly. If it is double free, it will may
>> crash at the same place or same time.
>
>Only if the program completely lacks any concurrency. If it's
>multithreaded, or if it's dealing with any external communications
>(pipes, network, etc.) that may be subject to timing differences,
>there is no reason to expect it to behave deterministically.
>
>> Besides, if the memory is freed before, the csize of this chunk
>> should be the same with next chunk's psize.
>
>Not necessarily. If the freed chunk was merged with neighboring free
>space, the bytes which were headers and footers at the time of free
>need not be headers and footers now. If they were not overwritten,
>they'll still have their old values but there's no reason to assume
>the old values are consistent at this point.
>
>> And the chunk's next and
>> prev pointer should point at <mal+xx>.
>
>Not necessarily; they could point to the bin head at mal+xx or to
>other free chunks in the same bin. In the case of two frees in
>immediate succession (with no concurrency) you would expect to find
>the freed chunk at the start of its bin, but in general that need not
>be the case.

Thank you for your prompt reply. I learned a lot from it.

>> For example, the 3rd case. 
>>  #0  0x0045e320 in a_crash () at src/malloc/malloc.c:465
>>  #1  free (p=0x7b81e0) at src/malloc/malloc.c:465
>> psize   csize    prev    next
>>  0x7b81d8:       0x11    0x30 0x4  0x3d0504 <json_object_object_delete>
>>  0x7b81e8:       0x3d0268 <json_object_object_to_json_string>    0x0     0x0     0x0
>>  0x7b81f8:       0x7b8210        0x0     0x0     0x0
>>  0x7b8208:       0x31    0x40    0x60ed30 <mal+56>       0x60ed30 <mal+56>
>
>Of these 4 lines, only the first and last look like it's likely that
>they are or were chunk headers. Assuming the 0x30 in the first line is
>correct, the second and third lines are just space inside the freed
>chunk. But then the fourth line wrongly has the chunk marked as
>in-use, and has another free chunk (of size 0x40) adjacent, which is
>inconsistent.
>
>In case there is any actual bug on our side, rather than just memory
>corruption by the application, can you fill us in on any additional
>details, especially whether the process is multithreaded? Knowing that
>would determine what sorts of further investigation might or couldn't
>be useful.

ARM926 is a signle core processor, and the application is multi-threaded.

I am sorry I sent several wrong mail to you. Perhaps  I attached a large file.