IPP Software Navigation Tools IPP Links Communication Pan-STARRS Links

Changeset 41560


Ignore:
Timestamp:
Apr 29, 2021, 1:51:12 PM (5 years ago)
Author:
eugene
Message:

fix malloc bug for memory ranges

File:
1 edited

Legend:

Unmodified
Added
Removed
  • trunk/Ohana/src/libohana/src/ohana_allocate.c

    r41341 r41560  
    6161}
    6262
     63
     64/* these are the measured values, but below we round the ends up and down
     65# define PS_BAD_MALLOC_RANGE_1_MIN 39637060
     66# define PS_BAD_MALLOC_RANGE_1_MAX 39649156
     67
     68# define PS_BAD_MALLOC_RANGE_2_MIN 79288100
     69# define PS_BAD_MALLOC_RANGE_2_MAX 79294312
     70*/
     71
     72# define PS_BAD_MALLOC_RANGE_1_MIN 39636000
     73# define PS_BAD_MALLOC_RANGE_1_MAX 39650000
     74
     75# define PS_BAD_MALLOC_RANGE_2_MIN 79288000
     76# define PS_BAD_MALLOC_RANGE_2_MAX 79298000
     77
    6378void *ohana_malloc (const char *file, int line, const char *func, size_t Nelem, size_t esize) {
    6479
     
    7994  // if (size % 8) size += (8 - size % 8); // do NOT round to 8-byte boundary (did not fix corruption)
    8095
     96  // for gcc 4.3.2, linux 3.7.6 (at least) there are bad malloc sizes.  if a request
     97  // is made for one of these bad ranges, actually allocate a larger amount
     98  if ((fullSize > PS_BAD_MALLOC_RANGE_1_MIN) && (fullSize < PS_BAD_MALLOC_RANGE_1_MAX)) { fullSize = PS_BAD_MALLOC_RANGE_1_MAX; }
     99  if ((fullSize > PS_BAD_MALLOC_RANGE_2_MIN) && (fullSize < PS_BAD_MALLOC_RANGE_2_MAX)) { fullSize = PS_BAD_MALLOC_RANGE_2_MAX; }
     100
     101  // this was another attempt to fix corruption problems probably due to the gcc error described above
    81102  if (USE_MMAP_LOCAL && (fullSize > USE_MMAP_SIZE)) {
    82103    fprintf (stderr, "** mmap %ld (%s, %d, %s)\n", fullSize, file, line, func);
     
    169190  size_t fullSize = sizeof(OhanaMemblock) + size + 2*sizeof(void *);
    170191  size_t oldFullSize = sizeof(OhanaMemblock) + oldsize + 2*sizeof(void *);
     192
     193  // for gcc 4.3.2, linux 3.7.6 (at least) there are bad malloc sizes.  if a request
     194  // is made for one of these bad ranges, actually allocate a larger amount
     195  if ((fullSize > PS_BAD_MALLOC_RANGE_1_MIN) && (fullSize < PS_BAD_MALLOC_RANGE_1_MAX)) { fullSize = PS_BAD_MALLOC_RANGE_1_MAX; }
     196  if ((fullSize > PS_BAD_MALLOC_RANGE_2_MIN) && (fullSize < PS_BAD_MALLOC_RANGE_2_MAX)) { fullSize = PS_BAD_MALLOC_RANGE_2_MAX; }
     197  if ((oldFullSize > PS_BAD_MALLOC_RANGE_1_MIN) && (oldFullSize < PS_BAD_MALLOC_RANGE_1_MAX)) { oldFullSize = PS_BAD_MALLOC_RANGE_1_MAX; }
     198  if ((oldFullSize > PS_BAD_MALLOC_RANGE_2_MIN) && (oldFullSize < PS_BAD_MALLOC_RANGE_2_MAX)) { oldFullSize = PS_BAD_MALLOC_RANGE_2_MAX; }
    171199
    172200  pthread_mutex_lock(&memBlockListMutex);
Note: See TracChangeset for help on using the changeset viewer.