On 1/15/2013 11:03 PM, marco atzeri wrote:
On 1/15/2013 12:24 PM, Corinna Vinschen wrote:
On Jan 15 11:36, marco atzeri wrote:
On 1/15/2013 11:07 AM, Corinna Vinschen wrote:
On Jan 15 09:43, marco atzeri wrote:
rebase is segfaulting on two dlls of new package
postgresql-contrib-9.2.2-1
Full packages here
http://matzeri.altervista.org/cygwin-1.7/postgresql/
Just the two dll's here:
http://matzeri.altervista.org/works/rebase/
for i in *.dll; do echo $i ; rebase -O $i ; done
dict_snowball.dll
Segmentation fault (core dumped)
ltree.dll
Segmentation fault (core dumped)
I don't know exactly what's going on here, but there's a common
factor:
[...]
Both DLLs have a section .gnu_deb, whatever that one is good for.
Rebase crashes both times when trying to relocate this .gnu_deb
section.
As you can see, the .gnu_deb section is pretty small, only 28 resp. 20
bytes. What happens is that the relocation information for the
.gnu_deb
section appears to be too big. In case of dict_snowball.dll, the reloc
info covers 44 relocation entries. The segfault occurs as soon as one
entry translates into a memory address which is beyond the committed
area of the file memory map.
[...]
It seems the result of the .dbg creation, that trunks
wrongly the sections.
[...]
for what I can see a dll with debug symbols
should have a .gnu_debuglink sections:
Right. Something's scrambled. AFAIK, the .gnu_debuglink is not
relocatable, it only contains a path. ".gnu_deb" appears to be
a result of using only the fixed 8 bytes of the section name.
Yaakov, do you have any idea what's going on here?
it seems that objcopy is considering the
--long-section-names {enable|disable|keep}
as disable (or keeping an incorrect disable)
using in sequence on a stripped ltree.dll
it seems only a symptom, also using that, I have still one
rebase segfault more crazy than before.
(ltree.dll is fine now)
$ objdump -h dict_snowball.dll
dict_snowball.dll: file format pei-i386
Sections:
Idx Name Size VMA LMA File off Algn
0 .text 00016808 67ec1000 67ec1000 00000400 2**4
CONTENTS, ALLOC, LOAD, READONLY, CODE, DATA
1 .data 00017180 67ed8000 67ed8000 00016e00 2**5
CONTENTS, ALLOC, LOAD, DATA
2 .bss 000000f8 67ef0000 67ef0000 00000000 2**5
ALLOC
3 .edata 00000fe0 67ef1000 67ef1000 0002e000 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
4 .idata 000003e0 67ef2000 67ef2000 0002f000 2**2
CONTENTS, ALLOC, LOAD, DATA
5 .reloc 0000765c 67ef3000 67ef3000 0002f400 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
6 .gnu_debuglink 0000001c 67efb000 67efb000 00036c00 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
$ rebase -O dict_snowball.dll
Segmentation fault (core dumped)
It segfaults and a spurious character appears on the section:
$ objdump -h dict_snowball.dll
dict_snowball.dll: file format pei-i386
Sections:
Idx Name Size VMA LMA File off Algn
0 .text 00016808 4e971000 4e971000 00000400 2**4
CONTENTS, ALLOC, LOAD, READONLY, CODE, DATA
1 .data 00017180 4e988000 4e988000 00016e00 2**5
CONTENTS, ALLOC, LOAD, DATA
2 .bss 000000f8 4e9a0000 4e9a0000 00000000 2**5
ALLOC
3 .edata 00000fe0 4e9a1000 4e9a1000 0002e000 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
4 .idata 000003e0 4e9a2000 4e9a2000 0002f000 2**2
CONTENTS, ALLOC, LOAD, DATA
5 .reloc 0000765c 4e9a3000 4e9a3000 0002f400 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
6 .gnu_debuglinkâ–’ 0000001c 4e9ab000 4e9ab000 00036c00 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
but the second time it works
$ rebase -O dict_snowball.dll
So it is now a rebase bug, a objcopy bug or both ?
all files here:
http://matzeri.altervista.org/works/rebase/
Marco
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
