Date: Wed, 06 Jun 2018 09:35:06 +0800 From: "徐露" <xulu@...winnertech.com> To: "musl" <musl@...ts.openwall.com> Subject: Re: SIGSEGV and SIGILL at malloc/free on ARM926 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. Content of type "text/html" skipped
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.