From: Rich Felker <dalias@libc.org>
To: musl@lists.openwall.com
Subject: Re: Re: SIGSEGV and SIGILL at malloc/free on ARM926
Date: Tue, 5 Jun 2018 22:27:44 -0400 [thread overview]
Message-ID: <20180606022744.GD1392@brightrain.aerifal.cx> (raw)
In-Reply-To: <4067bdff-eaa2-4efc-8068-a6116a5e243e.xulu@allwinnertech.com>
On Wed, Jun 06, 2018 at 09:35:06AM +0800, 徐露 wrote:
>
> 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.
Yes, the list seems to have rejected the large attachment. I got the
off-list cc's. I can't follow up right now but I'll see if I can tell
later if it looks like it could be a bug on our side.
Rich
prev parent reply other threads:[~2018-06-06 2:27 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-06 1:35 徐露
2018-06-06 2:27 ` Rich Felker [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180606022744.GD1392@brightrain.aerifal.cx \
--to=dalias@libc.org \
--cc=musl@lists.openwall.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).