Re: Custom malloc fails after gcc-5.x due to changes in eh_alloc.cc

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 23 March 2017 at 11:32, Kaushik Phatak wrote:
> Hi,
> One of our application uses its own custom malloc implementation.
> This code worked well in gcc-4.9.1, however once we switched the gcc-5.3.0 this stopped working.
>
> During initialization of the application (i.e. before it makes a call to malloc), it executes an
> init function -> "hardware_mem_init"
> This is called using a constructor with "__attribute__ ((init_priority (101)))" to ensure
> this it gets called before any other constructor call.

Why do you have to do it with a global constructor? That just seems fragile.

Why can't you call the init function on the first call to malloc? For
example, using a local static variable:

bool do_init() { hardware_mem_init(); return true; }

void* malloc(size_t n)
{
  static const bool initialised = do_init();
  // ...
}


> However, some class of libstdc++ library, is trying to allocate memory using malloc,
> and this happens well before our process gets a chance to initialize and
> setup the memory blocks properly (using hardware_mem_init).
>
> We narrowed down the issue to be caused due to the following patch which gets introduced in gcc-5.1.0,
> [PATCH] Fix PR64535 - increase emergency EH buffers via a new allocator
> https://gcc.gnu.org/ml/gcc-patches/2015-01/msg00681.html
>
> This creates an emergency pool for allocating memory to handle higher number of bad_alloc's, which is good;
> however it uses malloc which ends up calling our customized routine and our application fails as it
> does not get a chance to run the hardware_mem_init.
>
> Is there any way to get this to work by setting up some init_priority? Or some other option
> to allocate the emergency pool without using malloc?

The uncommitted patch at
https://gcc.gnu.org/ml/gcc-patches/2016-12/msg01158.html allows GCC to
be configured so it uses a fixed-size static pool, rather than using
malloc. I plan to change that for GCC 8, but you could apply that
patch locally.

That patch still isn't ideal as it requires rebuilding GCC. It would
be good if you could use an environment variable to control it at
run-time.



[Index of Archives]     [Linux C Programming]     [Linux Kernel]     [eCos]     [Fedora Development]     [Fedora Announce]     [Autoconf]     [The DWARVES Debugging Tools]     [Yosemite Campsites]     [Yosemite News]     [Linux GCC]

  Powered by Linux