malloc() call somehow calling the rtld malloc() implementaion

[Don Lewis]

On 27 Jan, Konstantin Belousov wrote:
> On Fri, Jan 27, 2017 at 12:19:16PM -0500, Alexander Kabaev wrote:
>> On Fri, 27 Jan 2017 00:31:30 -0800 (PST)
>> Don Lewis <truckman at FreeBSD.org> wrote:

>> > If I create a simple test program that calls malloc() and set a
>> > breakpoint in malloc(), the breakpoint gets set in the rtld version,
>> > but the the libc version of malloc is what gets called.
>> > 
>> > What the heck is going on here, and how can I fix it?
>> > 
>> 
>> rtld on my system does not have malloc exposed as dynamic symbol, it
>> cannot possibly be used for symbol resolution by any outside module.
> 
> Sure.
> 
> Also, the fact that rtld internal malloc is called does not mean that it
> is called by the application. There is no backtrace which would describe
> the reason for rtld allocating memory in reported cases. Generally,
> rtld needs memory for TLS allocation (the program is definitely linked
> with libthr, and even libc uses TLS), and, of course, to create data
> structures to track dlopen-ed objects.

After adding ports gdb as a RUN_DEPENDS so that it gets installed in the
poudriere jail that I was using for debugging, I can confirm that this
is exactly what is happening.  All of the calls to the rtld version of
malloc() happened before main() was entered.  Starting slightly before
the start of main() and continuing until the eventual SIGBUS, all of the
malloc() calls were to the version in libc.