Bug 195561
| Summary: | [exp-run] use elftoolchain tools: src.conf WITH_ELFTOOLCHAIN_TOOLS=yes | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Ports & Packages | Reporter: | Ed Maste <emaste> | ||||||
| Component: | Ports Framework | Assignee: | Ed Maste <emaste> | ||||||
| Status: | Closed FIXED | ||||||||
| Severity: | Affects Only Me | CC: | portmgr | ||||||
| Priority: | --- | Flags: | antoine:
exp-run?
|
||||||
| Version: | Latest | ||||||||
| Hardware: | Any | ||||||||
| OS: | Any | ||||||||
| Bug Depends on: | 195653, 196038, 196107 | ||||||||
| Bug Blocks: | |||||||||
| Attachments: |
|
||||||||
|
Description
Ed Maste
2014-12-01 20:26:05 UTC
Take for exp-run There is a problem, i can't login in an i386 jail created with WITH_ELFTOOLCHAIN_TOOLS=yes something looks really wrong on i386: pid 38148 (make), uid 0: exited on signal 11 (core dumped) pid 38408 (make), uid 0: exited on signal 11 (core dumped) pid 38724 (make), uid 0: exited on signal 11 (core dumped) pid 39396 (csh), uid 0: exited on signal 11 (core dumped) pid 40254 (make), uid 0: exited on signal 11 (core dumped) pid 40319 (csh), uid 0: exited on signal 11 (core dumped) pid 42098 (make), uid 0: exited on signal 11 (core dumped) pid 43351 (csh), uid 0: exited on signal 11 (core dumped) pid 53971 (csh), uid 0: exited on signal 11 (core dumped) pid 54239 (csh), uid 0: exited on signal 11 (core dumped) I have the csh.core if you want To confirm, this is building an i386 jail on an amd64 buildhost, with TARGET=i386? Is it feasible to check the amd64 case by itself while I figure out what's going on there. Yes, TARGET=i386 TARGET_ARCH=i386 /bin/sh from the jail runs, /bin/csh or /usr/bin/make do a core dump On amd64 it's the same, make dumps core. Back to submitter I can provide the core-dumping make for both i386 and amd64 if needed The issue affecting make/csh should be fixed in r275810. Can you try the exp-run again? Take for exp-run Exp-run results: http://package18.nyi.freebsd.org/build.html?mastername=head-amd64-PR195561-default&build=2014-12-15_23h48m44s 6 new failures on amd64: + {"origin"=>"lang/gcc48", "pkgname"=>"gcc48-4.8.4.s20141120", "phase"=>"build", "errortype"=>"???"} + {"origin"=>"lang/gcc49", "pkgname"=>"gcc49-4.9.3.s20141126", "phase"=>"build", "errortype"=>"???"} + {"origin"=>"lang/gcc5", "pkgname"=>"gcc5-5.0.s20141130", "phase"=>"build", "errortype"=>"???"} + {"origin"=>"multimedia/ffmpeg", "pkgname"=>"ffmpeg-2.3.5_4,1", "phase"=>"build", "errortype"=>"linker_error"} + {"origin"=>"multimedia/ffmpeg24", "pkgname"=>"ffmpeg24-2.4.3_4", "phase"=>"build", "errortype"=>"linker_error"} + {"origin"=>"multimedia/libav", "pkgname"=>"libav-10.2_7", "phase"=>"build", "errortype"=>"linker_error"} Failure logs: http://package18.nyi.freebsd.org/data/head-amd64-PR195561-default/2014-12-15_23h48m44s/logs/errors/gcc48-4.8.4.s20141120.log http://package18.nyi.freebsd.org/data/head-amd64-PR195561-default/2014-12-15_23h48m44s/logs/errors/gcc49-4.9.3.s20141126.log http://package18.nyi.freebsd.org/data/head-amd64-PR195561-default/2014-12-15_23h48m44s/logs/errors/gcc5-5.0.s20141130.log http://package18.nyi.freebsd.org/data/head-amd64-PR195561-default/2014-12-15_23h48m44s/logs/errors/ffmpeg-2.3.5_4,1.log http://package18.nyi.freebsd.org/data/head-amd64-PR195561-default/2014-12-15_23h48m44s/logs/errors/ffmpeg24-2.4.3_4.log http://package18.nyi.freebsd.org/data/head-amd64-PR195561-default/2014-12-15_23h48m44s/logs/errors/libav-10.2_7.log In ffmpeg/libav, the ranlib and ar warning are new gcc failures are stage 2 / stage 3 comparison failure of the form
> Comparing stages 2 and 3
> warning: gcc/cc1plus-checksum.o differs
> warning: gcc/cc1obj-checksum.o differs
> warning: gcc/cc1-checksum.o differs
> Bootstrap comparison failure!
> gcc/tree-vect-data-refs.o differs
> gcc/asan.o differs
For multimedia/ffmpeg: during successful build (with gnu tools): # file work/ffmpeg-2.3.5/libswscale/x86/*.o work/ffmpeg-2.3.5/libswscale/x86/input.o: ELF 64-bit LSB relocatable, x86-64, version 1 (FreeBSD), not stripped work/ffmpeg-2.3.5/libswscale/x86/output.o: ELF 64-bit LSB relocatable, x86-64, version 1 (FreeBSD), not stripped work/ffmpeg-2.3.5/libswscale/x86/rgb2rgb.o: ELF 64-bit LSB relocatable, x86-64, version 1 (FreeBSD), not stripped work/ffmpeg-2.3.5/libswscale/x86/scale.o: ELF 64-bit LSB relocatable, x86-64, version 1 (FreeBSD), not stripped work/ffmpeg-2.3.5/libswscale/x86/swscale.o: ELF 64-bit LSB relocatable, x86-64, version 1 (FreeBSD), not stripped work/ffmpeg-2.3.5/libswscale/x86/yuv2rgb.o: ELF 64-bit LSB relocatable, x86-64, version 1 (FreeBSD), not stripped during failing build (with elftoolchain): # file work/ffmpeg-2.3.5/libswscale/x86/*.o work/ffmpeg-2.3.5/libswscale/x86/input.o: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), stripped work/ffmpeg-2.3.5/libswscale/x86/output.o: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), stripped work/ffmpeg-2.3.5/libswscale/x86/rgb2rgb.o: ELF 64-bit LSB relocatable, x86-64, version 1 (FreeBSD), not stripped work/ffmpeg-2.3.5/libswscale/x86/scale.o: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), stripped work/ffmpeg-2.3.5/libswscale/x86/swscale.o: ELF 64-bit LSB relocatable, x86-64, version 1 (FreeBSD), not stripped work/ffmpeg-2.3.5/libswscale/x86/yuv2rgb.o: ELF 64-bit LSB relocatable, x86-64, version 1 (FreeBSD), not stripped From ffmpeg's configure script:
> # add some strip flags
> # -wN '..@*' is more selective than -x, but not available everywhere.
> check_stripflags -wN \'..@*\' || check_stripflags -x
Both elftoolchain strip and binutils strip accept -w.
With a trivial foo.o and strip without arguments (strip foo.o) binutils and elftoolchain strip produce identical output, with debug info, symtab and strtab stripped.
With "strip -wN \'..@*\' foo.o" the binutils .o has the same content as the original (except that the , while elftoolchain strips the debug info, symtab and strtab.
For gcc:
# readelf -S build/stage2-gcc/cc1plus-checksum.o build/stage3-gcc/cc1plus-checksum.o
File: build/stage2-gcc/cc1plus-checksum.o
There are 10 section headers, starting at offset 0xe0:
Section Headers:
[Nr] Name Type Address Offset
Size EntSize Flags Link Info Align
[ 0] NULL 0000000000000000 00000000
0000000000000000 0000000000000000 0 0 0
[ 1] .text PROGBITS 0000000000000000 00000040
0000000000000000 0000000000000000 AX 0 0 1
[ 2] .data PROGBITS 0000000000000000 00000040
0000000000000000 0000000000000000 WA 0 0 1
[ 3] .bss NOBITS 0000000000000000 00000040
0000000000000000 0000000000000000 WA 0 0 1
[ 4] .rodata PROGBITS 0000000000000000 00000040
0000000000000010 0000000000000000 A 0 0 16
[ 5] .comment PROGBITS 0000000000000000 00000050
000000000000003d 0000000000000001 MS 0 0 1
[ 6] .note.GNU-stack PROGBITS 0000000000000000 0000008d
0000000000000000 0000000000000000 0 0 1
[ 7] .shstrtab STRTAB 0000000000000000 0000008d
000000000000004d 0000000000000000 0 0 1
[ 8] .symtab SYMTAB 0000000000000000 00000360
00000000000000d8 0000000000000018 9 8 8
[ 9] .strtab STRTAB 0000000000000000 00000438
0000000000000028 0000000000000000 0 0 1
Key to Flags:
W (write), A (alloc), X (execute), M (merge), S (strings)
I (info), L (link order), G (group), x (unknown)
O (extra OS processing required) o (OS specific), p (processor specific)
File: build/stage3-gcc/cc1plus-checksum.o
There are 17 section headers, starting at offset 0x2080:
Section Headers:
[Nr] Name Type Address Offset
Size EntSize Flags Link Info Align
[ 0] NULL 0000000000000000 00000000
0000000000000000 0000000000000000 0 0 0
[ 1] .text PROGBITS 0000000000000000 00000040
0000000000000000 0000000000000000 AX 0 0 1
[ 2] .data PROGBITS 0000000000000000 00000040
0000000000000000 0000000000000000 WA 0 0 1
[ 3] .bss NOBITS 0000000000000000 00000040
0000000000000000 0000000000000000 WA 0 0 1
[ 4] .rodata PROGBITS 0000000000000000 00000040
0000000000000010 0000000000000000 A 0 0 16
[ 5] .debug_info PROGBITS 0000000000000000 00000050
00000000000012be 0000000000000000 0 0 1
[ 6] .rela.debug_info RELA 0000000000000000 00002638
00000000000013e0 0000000000000018 15 5 8
[ 7] .debug_abbrev PROGBITS 0000000000000000 0000130e
00000000000001e2 0000000000000000 0 0 1
[ 8] .debug_aranges PROGBITS 0000000000000000 000014f0
0000000000000020 0000000000000000 0 0 1
[ 9] .rela.debug_arang RELA 0000000000000000 00003a18
0000000000000018 0000000000000018 15 8 8
[10] .debug_line PROGBITS 0000000000000000 00001510
0000000000000225 0000000000000000 0 0 1
[11] .debug_str PROGBITS 0000000000000000 00001735
0000000000000873 0000000000000001 MS 0 0 1
[12] .comment PROGBITS 0000000000000000 00001fa8
000000000000003d 0000000000000001 MS 0 0 1
[13] .note.GNU-stack PROGBITS 0000000000000000 00001fe5
0000000000000000 0000000000000000 0 0 1
[14] .shstrtab STRTAB 0000000000000000 00001fe5
0000000000000097 0000000000000000 0 0 1
[15] .symtab SYMTAB 0000000000000000 000024c0
0000000000000150 0000000000000018 16 13 8
[16] .strtab STRTAB 0000000000000000 00002610
0000000000000028 0000000000000000 0 0 1
Key to Flags:
W (write), A (alloc), X (execute), M (merge), S (strings)
I (info), L (link order), G (group), x (unknown)
O (extra OS processing required) o (OS specific), p (processor specific)
PR 196038 is (part of?) the reason the ffmpeg ports fail. After it's fixed I will try the gcc port locally to continue the investigation. > readelf -S build/stage2-gcc/cc1plus-checksum.o build/stage3-gcc/cc1plus-checksum.o It looks like the debug info in stage 3 and but not in stage 2 is an expected part of GCC's build - https://gcc.gnu.org/install/build.html (bootstrap-debug option) GCC uses a contrib/compare-debug script to strip the stage 2 and stage 3 .o files before comparing them (and allows for some other differences too). I'm having trouble tracking down the comparison failure though, and I'm not sure where /usr/bin/strip is being used vs. /usr/local/x86_64-portbld-freebsd11.0/bin/strip. I see the binutils portbld strip being picked up by configure. On i386 there are 7 similar failures during install: http://pb2.nyi.freebsd.org/data/head-i386-PR195561-default/2014-12-17_20h57m47s/logs/errors/coreos-etcd-0.4.6.log http://pb2.nyi.freebsd.org/data/head-i386-PR195561-default/2014-12-17_20h57m47s/logs/errors/coreos-etcdctl-0.4.6.log http://pb2.nyi.freebsd.org/data/head-i386-PR195561-default/2014-12-17_20h57m47s/logs/errors/exercism-1.7.1.log http://pb2.nyi.freebsd.org/data/head-i386-PR195561-default/2014-12-17_20h57m47s/logs/errors/fixc-1.0.log http://pb2.nyi.freebsd.org/data/head-i386-PR195561-default/2014-12-17_20h57m47s/logs/errors/logstash-forwarder-0.3.1.20140829.log http://pb2.nyi.freebsd.org/data/head-i386-PR195561-default/2014-12-17_20h57m47s/logs/errors/meek-0.9.log http://pb2.nyi.freebsd.org/data/head-i386-PR195561-default/2014-12-17_20h57m47s/logs/errors/pond-20140824_1.log There is also 1 link failure: http://pb2.nyi.freebsd.org/data/head-i386-PR195561-default/2014-12-17_20h57m47s/logs/errors/caudium14-1.4.18.7.8.866.log for gcc5 on amd64:
The differences seem to be in the Info in the GROUP sections.
There seems to be a difference of 7 between the Info in the GROUP sections of stage2 and stage3 (tested on 4 or 5 stripped objects)
For instance:
# readelf -S stage2-gcc/expmed.o.stripped
There are 20 section headers, starting at offset 0xebf8:
Section Headers:
[Nr] Name Type Address Offset
Size EntSize Flags Link Info Align
[ 0] NULL 0000000000000000 00000000
0000000000000000 0000000000000000 0 0 0
[ 1] .group GROUP 0000000000000000 00000040
000000000000000c 0000000000000004 0 216 4
[ 2] .text PROGBITS 0000000000000000 00000050
000000000000cc47 0000000000000000 AX 0 0 16
[ 3] .rela.text RELA 0000000000000000 0000f0f8
0000000000000000 0000000000000018 0 2 8
[ 4] .data PROGBITS 0000000000000000 0000cc98
000000000000000c 0000000000000000 WA 0 0 8
[ 5] .rela.data RELA 0000000000000000 0000f0f8
0000000000000000 0000000000000018 0 4 8
[ 6] .bss NOBITS 0000000000000000 0000ccc0
0000000000019940 0000000000000000 WA 0 0 64
[ 7] .text.unlikely PROGBITS 0000000000000000 0000ccc0
000000000000007f 0000000000000000 AX 0 0 2
[ 8] .rela.text.unlike RELA 0000000000000000 0000f0f8
0000000000000000 0000000000000018 0 7 8
[ 9] .rodata.str1.8 PROGBITS 0000000000000000 0000cd40
00000000000000e9 0000000000000001 AMS 0 0 8
[10] .rodata.str1.1 PROGBITS 0000000000000000 0000ce29
000000000000000f 0000000000000001 AMS 0 0 1
[11] .rodata PROGBITS 0000000000000000 0000ce40
00000000000005d2 0000000000000000 A 0 0 16
[12] .rela.rodata RELA 0000000000000000 0000f0f8
0000000000000000 0000000000000018 0 11 8
[13] .text.unlikely._Z PROGBITS 0000000000000000 0000d412
0000000000000000 0000000000000000 AXG 0 0 2
[14] .text._ZN16generi PROGBITS 0000000000000000 0000d420
00000000000000a7 0000000000000000 AXG 0 0 16
[15] .comment PROGBITS 0000000000000000 0000d4c7
000000000000003f 0000000000000001 MS 0 0 1
[16] .note.GNU-stack PROGBITS 0000000000000000 0000d506
0000000000000000 0000000000000000 0 0 1
[17] .eh_frame PROGBITS 0000000000000000 0000d508
00000000000015b0 0000000000000000 A 0 0 8
[18] .rela.eh_frame RELA 0000000000000000 0000f0f8
0000000000000000 0000000000000018 0 17 8
[19] .shstrtab STRTAB 0000000000000000 0000eab8
000000000000013f 0000000000000000 0 0 1
Key to Flags:
W (write), A (alloc), X (execute), M (merge), S (strings)
I (info), L (link order), G (group), x (unknown)
O (extra OS processing required) o (OS specific), p (processor specific)
-> Info in .group section is 216
# readelf -S stage3-gcc/expmed.o.stripped
There are 20 section headers, starting at offset 0xebf8:
Section Headers:
[Nr] Name Type Address Offset
Size EntSize Flags Link Info Align
[ 0] NULL 0000000000000000 00000000
0000000000000000 0000000000000000 0 0 0
[ 1] .group GROUP 0000000000000000 00000040
000000000000000c 0000000000000004 0 223 4
[ 2] .text PROGBITS 0000000000000000 00000050
000000000000cc47 0000000000000000 AX 0 0 16
[ 3] .rela.text RELA 0000000000000000 0000f0f8
0000000000000000 0000000000000018 0 2 8
[ 4] .data PROGBITS 0000000000000000 0000cc98
000000000000000c 0000000000000000 WA 0 0 8
[ 5] .rela.data RELA 0000000000000000 0000f0f8
0000000000000000 0000000000000018 0 4 8
[ 6] .bss NOBITS 0000000000000000 0000ccc0
0000000000019940 0000000000000000 WA 0 0 64
[ 7] .text.unlikely PROGBITS 0000000000000000 0000ccc0
000000000000007f 0000000000000000 AX 0 0 2
[ 8] .rela.text.unlike RELA 0000000000000000 0000f0f8
0000000000000000 0000000000000018 0 7 8
[ 9] .rodata.str1.8 PROGBITS 0000000000000000 0000cd40
00000000000000e9 0000000000000001 AMS 0 0 8
[10] .rodata.str1.1 PROGBITS 0000000000000000 0000ce29
000000000000000f 0000000000000001 AMS 0 0 1
[11] .rodata PROGBITS 0000000000000000 0000ce40
00000000000005d2 0000000000000000 A 0 0 16
[12] .rela.rodata RELA 0000000000000000 0000f0f8
0000000000000000 0000000000000018 0 11 8
[13] .text.unlikely._Z PROGBITS 0000000000000000 0000d412
0000000000000000 0000000000000000 AXG 0 0 2
[14] .text._ZN16generi PROGBITS 0000000000000000 0000d420
00000000000000a7 0000000000000000 AXG 0 0 16
[15] .comment PROGBITS 0000000000000000 0000d4c7
000000000000003f 0000000000000001 MS 0 0 1
[16] .note.GNU-stack PROGBITS 0000000000000000 0000d506
0000000000000000 0000000000000000 0 0 1
[17] .eh_frame PROGBITS 0000000000000000 0000d508
00000000000015b0 0000000000000000 A 0 0 8
[18] .rela.eh_frame RELA 0000000000000000 0000f0f8
0000000000000000 0000000000000018 0 17 8
[19] .shstrtab STRTAB 0000000000000000 0000eab8
000000000000013f 0000000000000000 0 0 1
Key to Flags:
W (write), A (alloc), X (execute), M (merge), S (strings)
I (info), L (link order), G (group), x (unknown)
O (extra OS processing required) o (OS specific), p (processor specific)
-> Info in .group section is 223
8 out of the 12 strip tests from the binutils testsuite are about section group: strip-1.d:#name: strip with section group 1 strip-2.d:#name: strip with section group 2 strip-4.d:#name: strip with section group 4 strip-5.d:#name: strip with section group 5 strip-6.d:#name: strip with section group 6 strip-7.d:#name: strip with section group 7 strip-8.d:#name: strip with section group 8 strip-9.d:#name: strip with section group 9 I can put the result I have with gnu strip versus elftoolchain strip somewhere, for instance there are some readelf errors with objects stripped by elftoolchain strip: "readelf: Error: Bad sh_link in group section `.group'" This test crashes strip from elftoolchain too: strip-3.d:#name: strip empty file The crash on empty .o is reported here: https://sourceforge.net/p/elftoolchain/tickets/463/ I put the diff between gnu and elftoolchain strip at: http://package18.nyi.freebsd.org/data/head-amd64-PR195561-default/2014-12-18_18h05m16s/logs/errors/group-section.txt (In reply to Antoine Brodin from comment #18) > There is also 1 link failure: > > http://pb2.nyi.freebsd.org/data/head-i386-PR195561-default/2014-12- > 17_20h57m47s/logs/errors/caudium14-1.4.18.7.8.866.log You can ignore this one, it's broken without elftoolchain too. I have an elftoolchain update in the projects/elftoolchain-update-r3130 branch, which should improve group handling and fix issues found in the i386 exp-run. Exp-run results on i386: http://pb2.nyi.freebsd.org/build.html?mastername=head-i386-PR195561-default&build=2014-12-27_17h54m19s 7 new failures: + {"origin"=>"devel/etcd", "pkgname"=>"coreos-etcd-0.4.6", "phase"=>"stage", "errortype"=>"???"} + {"origin"=>"devel/etcdctl", "pkgname"=>"coreos-etcdctl-0.4.6", "phase"=>"stage", "errortype"=>"???"} + {"origin"=>"finance/fixc", "pkgname"=>"fixc-1.0", "phase"=>"stage", "errortype"=>"???"} + {"origin"=>"misc/exercism", "pkgname"=>"exercism-1.7.1", "phase"=>"stage", "errortype"=>"???"} + {"origin"=>"security/meek", "pkgname"=>"meek-0.9", "phase"=>"stage", "errortype"=>"???"} + {"origin"=>"security/pond", "pkgname"=>"pond-20140824_1", "phase"=>"stage", "errortype"=>"???"} + {"origin"=>"sysutils/logstash-forwarder", "pkgname"=>"logstash-forwarder-0.3.1.20140829", "phase"=>"stage", "errortype"=>"???" Failure logs: http://pb2.nyi.freebsd.org/data/head-i386-PR195561-default/2014-12-27_17h54m19s/logs/errors/coreos-etcd-0.4.6.log http://pb2.nyi.freebsd.org/data/head-i386-PR195561-default/2014-12-27_17h54m19s/logs/errors/coreos-etcdctl-0.4.6.log http://pb2.nyi.freebsd.org/data/head-i386-PR195561-default/2014-12-27_17h54m19s/logs/errors/fixc-1.0.log http://pb2.nyi.freebsd.org/data/head-i386-PR195561-default/2014-12-27_17h54m19s/logs/errors/exercism-1.7.1.log http://pb2.nyi.freebsd.org/data/head-i386-PR195561-default/2014-12-27_17h54m19s/logs/errors/meek-0.9.log http://pb2.nyi.freebsd.org/data/head-i386-PR195561-default/2014-12-27_17h54m19s/logs/errors/pond-20140824_1.log http://pb2.nyi.freebsd.org/data/head-i386-PR195561-default/2014-12-27_17h54m19s/logs/errors/logstash-forwarder-0.3.1.20140829.log Exp-run results on amd64: http://pb2.nyi.freebsd.org/build.html?mastername=head-amd64-PR195561-default&build=2014-12-28_09h50m55s 0 new failure (In reply to Antoine Brodin from comment #25) > Exp-run results on i386: > > http://pb2.nyi.freebsd.org/build.html?mastername=head-i386-PR195561- > default&build=2014-12-27_17h54m19s > > 7 new failures: I reported the i386 failures in upstream elftoolchain ticket 465; it appears they all have the same cause. https://sourceforge.net/p/elftoolchain/tickets/465/ Should be fixed by upstream revs 3131-3134 (I'm up to 3130 in FreeBSD head): https://sourceforge.net/p/elftoolchain/code/3131 https://sourceforge.net/p/elftoolchain/code/3132 https://sourceforge.net/p/elftoolchain/code/3133 https://sourceforge.net/p/elftoolchain/code/3134 I will do another import soon. Updated to upstream r3136 in FreeBSD r276398. I believe this should address all of the issues found by the exp-run. Thanks again for all of the effort on this! There is a regression, installworld fails on i386: ===> rescue/rescue (install) install -N /zpoudriere/jails/head-i386-PR195561/usr/src/etc -s -o root -g wheel -m 555 rescue /zpoudriere/jails/head-i386-PR195561/rescue/rescue strip: 692 gelf_getshdr() failed: Invalid argument install: strip command strip failed on /zpoudriere/jails/head-i386-PR195561/rescue/rescue *** Error code 70 Should be fixed as of r276427 - On both amd64 and i386, I have a hang during french/aster build. See log at: http://pb2.nyi.freebsd.org/data/head-amd64-PR195561-default/2015-01-03_11h00m24s/logs/errors/fr-aster-11.6.0.1_3.log It hangs during /usr/bin/addr2line invocation. I searched a bit and found that this comes from libgfortran.so You can find the source of backtrace() in gcc-4.8.4/libgfortran/runtime/backtrace.c - On i386, java seems to have more memory failures with elftoolchain than without, I have to relaunch an incremental build for the following ports, they always fail with memory failure (heap space) during first run: java/eclipse java/jboss71 misc/freebsd-doc-de misc/freebsd-doc-el misc/freebsd-doc-fr misc/freebsd-doc-hu misc/freebsd-doc-it misc/freebsd-doc-mn misc/freebsd-doc-nl misc/freebsd-doc-pl misc/freebsd-doc-ru misc/freebsd-doc-zh_cn misc/freebsd-doc-zh_tw examples of failures: http://package18.nyi.freebsd.org/data/head-i386-PR195561-default/2015-01-03_11h00m34s/logs/errors/eclipse-4.3.2_3.log http://package18.nyi.freebsd.org/data/head-i386-PR195561-default/2015-01-03_11h00m34s/logs/errors/fr-freebsd-doc-46070,1.log http://package18.nyi.freebsd.org/data/head-i386-PR195561-default/2015-01-03_11h00m34s/logs/errors/jboss71-7.1.3.log Created attachment 151333 [details]
ktrace output for testprog/addr2line
Created attachment 151334 [details]
ktrace output for testprog/gnu addr2line
You can ignore the java memory failures, I managed to get them with MALLOC_PRODUCTION=yes and without WITH_ELFTOOLCHAIN_TOOLS A commit references this bug: Author: emaste Date: Mon Jan 5 04:56:39 UTC 2015 New revision: 276689 URL: https://svnweb.freebsd.org/changeset/base/276689 Log: addr2line: fflush output after each address lookup Certain tools spawn addr2line and pass addresses one at a time for resolution. PR: 195561 Reported by: antoine Sponsored by: The FreeBSD Foundation Changes: head/contrib/elftoolchain/addr2line/addr2line.c I confirm that french/aster build successfully now. http://pb2.nyi.freebsd.org/data/head-i386-PR195561-default/2015-01-05_09h27m28s/logs/fr-aster-11.6.0.1_3.log Looks good, no new failure. |