Date: Tue, 5 Jun 2018 01:58:48 -0400 From: dalias <dalias@...c.org> To: musl@...ts.openwall.com Subject: Re: 回复：SIGSEGV and SIGILL at malloc/free on ARM926 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. > 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. Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.