HEADSUP: Python 2.7 upgrade

szgyg szgyg@ludens.elte.hu
Mon Jan 28 13:25:00 GMT 2013

I didn't see the discussion on the other list. Oh, well.

On 1/28/2013 11:35 AM, Corinna Vinschen wrote:
> On Jan 26 01:08, szgyg wrote:
>> On 1/24/2013 1:29 PM, Corinna Vinschen wrote:
>>>>> The size of the .reloc section in the file header does not indicate how
>>>>> long the relocation information in the section actually is.  Usually the
>>>>> section is larger than the actual relocation info.  The end of the
>>>>> relocation info is indicated by a block header with a base offset of 0
>>>>> and a sizeof of 0, let's call it the NULL block.
>> VirtualSize (offset 8 in section header) should be exact. There are
>> no terminator zero block, but can be zero section padding.
>> VirtualSize + padding = SizeOfRawData.
> Are you implying that rebase (or better: the included imagehelper lib)
> is doing the right thing, or not?  The size of the reloc section is
> taken from SizeOfRawData.  Relocations::check checks if the data is
> within a valid section.  I just don't see what it's doing wrong there.

This problem is unrelated to the segfault.

Relocations::relocate does a strange thing that works by accident. See 
this condition:

  &relocp->SizeOfBlock < (PDWORD) ((char *)relocs + size)
  && relocp->SizeOfBlock != 0;

After the last relocation block, the first half of the condition is 
false if we have 0 or 1 DWORD of padding, and the second half is false 
if the second DWORD of padding is 0. As paddings should be all zeros, 
this condition always terminates the loop, but I wouldn't write it in 
this way. A better form is something like
relocp < relocs + virtual_size

Relocations::fix is broken, but hopefully it doesn't run on dlls not 
created by dllwrap. It should set VirtualSize and zero out the remaining 
part of .reloc. Right now it leaves a .reloc with an invalid, 0-size 
block and additional garbage.


More information about the Cygwin-apps mailing list