Hello Dr. Henson,

> This latter case would be easier to track down if 
> OpenSSL was compiled against a debugging malloc 
> library (there are several freeware ones available) 
> which would hopefully cause any invalid call to be 
> trapped when it was made rather than its after 
> effects.

I debugged my program and OpenSSL against dmalloc ( http://dmalloc.com/ ) and modified 
"mem.c" from OpenSSL to get more information. Here are the latest malloc calls before 
the segmantation fault. It seems, that OpenSSL overwrites allocated memory - may be 
memory allocated for 32-Bit and used with 64-Bit?

Best regards,
Stephan Collet

LEVITTE_DEBUG_MEM-IN: CRYPTO_malloc:> Size: 1   File: a_mbstr.c   Line: 234
1059130582: 7099: checking heap
1059130582: 7099: need 137 bytes /*128 Byte Top-Fence+8 Byte Bottom-Fence+1 Byte 
Size*/  
1059130582: 7099: *** alloc: at 'ra=0x1c9f4002c7c00' for 1 bytes, got '0x1002f1ed8|s1'
LEVITTE_DEBUG_MEM-Alloc: CRYPTO_malloc:> RetPointer: 1002f1ed8
LEVITTE_DEBUG_MEM-Out: CRYPTO_malloc:> SUCCESS

LEVITTE_DEBUG_MEM-IN: CRYPTO_malloc:> Size: 64   File: mem_dbg.c   Line: 425
1059130582: 7100: checking heap
1059130582: 7100: need 200 bytes
1059130582: 7100: *** alloc: at 'ra=0x1c9f40000002b' for 64 bytes, got '0x1003e8008|s1'
LEVITTE_DEBUG_MEM-Alloc: CRYPTO_malloc:> RetPointer: 1003e8008
LEVITTE_DEBUG_MEM-Out: CRYPTO_malloc:> SUCCESS

LEVITTE_DEBUG_MEM: [ 2182] + 0x1002f1ed8 (1)

LEVITTE_DEBUG_MEM-IN: CRYPTO_malloc:> Size: 24   File: lhash.c   Line: 193
1059130582: 7101: checking heap
1059130582: 7101: need 160 bytes
1059130582: 7101: *** alloc: at 'ra=0x1c9f4000a7d10' for 24 bytes, got '0x1003f3848|s1'
LEVITTE_DEBUG_MEM-Alloc: CRYPTO_malloc:> RetPointer: 1003f3848
LEVITTE_DEBUG_MEM-Out: CRYPTO_malloc:> SUCCESS

LEVITTE_DEBUG_MEM-IN: CRYPTO_malloc:> Size: 16   File: tasn_new.c   Line: 170
1059130582: 7102: checking heap
1059130582: 7102: ERROR: _dmalloc_chunk_heap_check: failed OVER picket-fence 
magic-number check (err 27)
1059135742: 7102: need 152 bytes
1059135742: 7102: *** alloc: at 'ra=0x1c9f400000000' for 16 bytes, got '0x1004e4308|s1'
debug-malloc library: dumping program, fatal error
   Error: failed OVER picket-fence magic-number check (err 27)


http://dmalloc.com/docs/5.2.1/online/dmalloc_8.html#SEC8
========================================
fence-post (i.e. bounds) checking 
Fence-post memory is the area immediately above or below memory allocations. It is all 
too easy to write code that accesses above or below an allocation -- especially when 
dealing with arrays or strings. The library can write special values in the areas 
around every allocation so it will notice when these areas have been overwritten.


My modifications in mem.c:
---------------------------
void *CRYPTO_malloc(int num, const char *file, int line)
 {
 void *ret = NULL;
 extern unsigned char cleanse_ctr;

#ifdef LEVITTE_DEBUG_MEM
 fprintf(stderr, "LEVITTE_DEBUG_MEM-IN: CRYPTO_malloc:> Size: %d   File: %s   Line: 
%d\n", num, file, line);
#endif

 if (num < 0) return NULL;

 allow_customize = 0;
 if (malloc_debug_func != NULL)
  {
  allow_customize_debug = 0;
  malloc_debug_func(NULL, num, file, line, 0);
  }
 ret = malloc_ex_func(num,file,line);

#ifdef LEVITTE_DEBUG_MEM
 fprintf(stderr, "LEVITTE_DEBUG_MEM-Alloc: CRYPTO_malloc:> RetPointer: %p\n", ret);
#endif

 if (malloc_debug_func != NULL)
  malloc_debug_func(ret, num, file, line, 1);

        /* Create a dependency on the value of 'cleanse_ctr' so our memory
         * sanitisation function can't be optimised out. NB: We only do
         * this for >2Kb so the overhead doesn't bother us. */
        if(ret && (num > 2048))
                ((unsigned char *)ret)[0] = cleanse_ctr;

#ifdef LEVITTE_DEBUG_MEM
 fprintf(stderr, "LEVITTE_DEBUG_MEM-Out: CRYPTO_malloc:> SUCCESS\n");
#endif

 return ret;
 }
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [EMAIL PROTECTED]
Automated List Manager                           [EMAIL PROTECTED]

Reply via email to