Menu
▾
▴
valgrind-users — General discussion list for Valgrind users
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
(58) |
Apr
(261) |
May
(169) |
Jun
(214) |
Jul
(201) |
Aug
(219) |
Sep
(198) |
Oct
(203) |
Nov
(241) |
Dec
(94) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(137) |
Feb
(149) |
Mar
(150) |
Apr
(193) |
May
(95) |
Jun
(173) |
Jul
(137) |
Aug
(236) |
Sep
(157) |
Oct
(150) |
Nov
(136) |
Dec
(90) |
| 2005 |
Jan
(139) |
Feb
(130) |
Mar
(274) |
Apr
(138) |
May
(184) |
Jun
(152) |
Jul
(261) |
Aug
(409) |
Sep
(239) |
Oct
(241) |
Nov
(260) |
Dec
(137) |
| 2006 |
Jan
(191) |
Feb
(142) |
Mar
(169) |
Apr
(75) |
May
(141) |
Jun
(169) |
Jul
(131) |
Aug
(141) |
Sep
(192) |
Oct
(176) |
Nov
(142) |
Dec
(95) |
| 2007 |
Jan
(98) |
Feb
(120) |
Mar
(93) |
Apr
(96) |
May
(95) |
Jun
(65) |
Jul
(62) |
Aug
(56) |
Sep
(53) |
Oct
(95) |
Nov
(106) |
Dec
(87) |
| 2008 |
Jan
(58) |
Feb
(149) |
Mar
(175) |
Apr
(110) |
May
(106) |
Jun
(72) |
Jul
(55) |
Aug
(89) |
Sep
(26) |
Oct
(96) |
Nov
(83) |
Dec
(93) |
| 2009 |
Jan
(97) |
Feb
(106) |
Mar
(74) |
Apr
(64) |
May
(115) |
Jun
(83) |
Jul
(137) |
Aug
(103) |
Sep
(56) |
Oct
(59) |
Nov
(61) |
Dec
(37) |
| 2010 |
Jan
(94) |
Feb
(71) |
Mar
(53) |
Apr
(105) |
May
(79) |
Jun
(111) |
Jul
(110) |
Aug
(81) |
Sep
(50) |
Oct
(82) |
Nov
(49) |
Dec
(21) |
| 2011 |
Jan
(87) |
Feb
(105) |
Mar
(108) |
Apr
(99) |
May
(91) |
Jun
(94) |
Jul
(114) |
Aug
(77) |
Sep
(58) |
Oct
(58) |
Nov
(131) |
Dec
(62) |
| 2012 |
Jan
(76) |
Feb
(93) |
Mar
(68) |
Apr
(95) |
May
(62) |
Jun
(109) |
Jul
(90) |
Aug
(87) |
Sep
(49) |
Oct
(54) |
Nov
(66) |
Dec
(84) |
| 2013 |
Jan
(67) |
Feb
(52) |
Mar
(93) |
Apr
(65) |
May
(33) |
Jun
(34) |
Jul
(52) |
Aug
(42) |
Sep
(52) |
Oct
(48) |
Nov
(66) |
Dec
(14) |
| 2014 |
Jan
(66) |
Feb
(51) |
Mar
(34) |
Apr
(47) |
May
(58) |
Jun
(27) |
Jul
(52) |
Aug
(41) |
Sep
(78) |
Oct
(30) |
Nov
(28) |
Dec
(26) |
| 2015 |
Jan
(41) |
Feb
(42) |
Mar
(20) |
Apr
(73) |
May
(31) |
Jun
(48) |
Jul
(23) |
Aug
(55) |
Sep
(36) |
Oct
(47) |
Nov
(48) |
Dec
(41) |
| 2016 |
Jan
(32) |
Feb
(34) |
Mar
(33) |
Apr
(22) |
May
(14) |
Jun
(31) |
Jul
(29) |
Aug
(41) |
Sep
(17) |
Oct
(27) |
Nov
(38) |
Dec
(28) |
| 2017 |
Jan
(28) |
Feb
(30) |
Mar
(16) |
Apr
(9) |
May
(27) |
Jun
(57) |
Jul
(28) |
Aug
(43) |
Sep
(31) |
Oct
(20) |
Nov
(24) |
Dec
(18) |
| 2018 |
Jan
(34) |
Feb
(50) |
Mar
(18) |
Apr
(26) |
May
(13) |
Jun
(31) |
Jul
(13) |
Aug
(11) |
Sep
(15) |
Oct
(12) |
Nov
(18) |
Dec
(13) |
| 2019 |
Jan
(12) |
Feb
(29) |
Mar
(51) |
Apr
(22) |
May
(13) |
Jun
(20) |
Jul
(13) |
Aug
(12) |
Sep
(21) |
Oct
(6) |
Nov
(9) |
Dec
(5) |
| 2020 |
Jan
(13) |
Feb
(5) |
Mar
(25) |
Apr
(4) |
May
(40) |
Jun
(27) |
Jul
(5) |
Aug
(17) |
Sep
(21) |
Oct
(1) |
Nov
(5) |
Dec
(15) |
| 2021 |
Jan
(28) |
Feb
(6) |
Mar
(11) |
Apr
(5) |
May
(7) |
Jun
(8) |
Jul
(5) |
Aug
(5) |
Sep
(11) |
Oct
(9) |
Nov
(10) |
Dec
(12) |
| 2022 |
Jan
(7) |
Feb
(13) |
Mar
(8) |
Apr
(7) |
May
(12) |
Jun
(27) |
Jul
(14) |
Aug
(27) |
Sep
(27) |
Oct
(17) |
Nov
(17) |
Dec
|
| 2023 |
Jan
(10) |
Feb
(18) |
Mar
(9) |
Apr
(26) |
May
|
Jun
(13) |
Jul
(18) |
Aug
(5) |
Sep
(12) |
Oct
(16) |
Nov
(1) |
Dec
|
| 2024 |
Jan
(4) |
Feb
(3) |
Mar
(6) |
Apr
(17) |
May
(2) |
Jun
(33) |
Jul
(13) |
Aug
(1) |
Sep
(6) |
Oct
(8) |
Nov
(6) |
Dec
(15) |
| 2025 |
Jan
(5) |
Feb
(11) |
Mar
(8) |
Apr
(20) |
May
(1) |
Jun
|
Jul
|
Aug
(9) |
Sep
(1) |
Oct
|
Nov
|
Dec
|
|
From: John R. <jr...@bi...> - 2018-02-13 00:03:25
|
> https://zerobin.net/?0bf6ea80afca0924#PT/yP+KTPOXYx/+IKUC+wwhm/UCF+S2fccpHQB9Cf7Q= [That "paste" site says that the page expires in 6 days.] Looking at the dumped data, I see three Elf32_Shdr Sections named ".rodata": [18] .rodata PROGBITS 00093ac0 093ac0 003504 00 A 0 0 32 [28] .rodata PROGBITS 000970ac 0970ac 0002b4 01 AMS 0 0 4 [41] .rodata PROGBITS 00098a97 098a97 0001a9 01 AMS 0 0 1 while the valgrind code in coregrind/m_debuginfo/readelf.c subroutine Bool ML_(read_elf_debug_info) ( struct _DebugInfo* di ) appears to assume that there will be only one such ".rodata": if (0 == VG_(strcmp)(name, ".rodata")) { if (inrx && !di->rodata_present) { \\\ only di->rodata_present = True; /// once? di->rodata_svma = svma; di->rodata_avma = svma + inrx->bias; di->rodata_size = size; di->rodata_bias = inrx->bias; di->rodata_debug_svma = svma; di->rodata_debug_bias = inrx->bias; /* NB was 'inrw' prior to r11794 */ TRACE_SYMTAB("acquiring .rodata svma = %#lx .. %#lx\n", di->rodata_svma, di->rodata_svma + di->rodata_size - 1); TRACE_SYMTAB("acquiring .rodata avma = %#lx .. %#lx\n", di->rodata_avma, di->rodata_avma + di->rodata_size - 1); TRACE_SYMTAB("acquiring .rodata bias = %#lx\n", (UWord)di->rodata_bias); } else { BAD(".rodata"); } } It might be possible to confirm this diagnosis by turning on TRACE_SYMTAB (which is controlled by command-line argument --trace-symtab=yes and perhaps by --trace-symtab-patt=<patt> ) and looking through what valgrind reports. [Of course I also see the many hundreds of Sections ".rodata.<subr_name>" and ".text.<subr_name>" and ".text.unlikely.<subr_name>" which at first glance seem to be overkill and/or extravagant waste of space. There should be a more-compact way to convey the information.] |
|
From: Paul F. <pj...@wa...> - 2018-02-12 20:59:47
|
> On 11 Feb 2018, at 21:36, John Reiser <jr...@bi...> wrote: > >> --18142-- WARNING: Serious error when reading debug info >> --18142-- When reading debug info from /export/home/paulf/tools/gcc/lib/libstdc++.so.6.0.25: >> --18142-- Can't make sense of .rodata section mapping >> (GCC SVN head, Solaris 11.3, Valgrind git head). > > What does > readelf --headers .../libstdc++.so.6.0.25 > say about the ElfXX_Shdrs and ElfXX_Phdrs, > and the mapping of the Shdrs into the Phdrs ? > One more thing - I get the same with both 32bit and 64bit executables. A+ Paul |
|
From: Paul F. <pj...@wa...> - 2018-02-12 20:42:02
|
Hi John My first attempt to post the output failed as it was too long. Here it is on a paste site https://zerobin.net/?0bf6ea80afca0924#PT/yP+KTPOXYx/+IKUC+wwhm/UCF+S2fccpHQB9Cf7Q= Here's an extract: ELF Header: Magic: 7f 45 4c 46 01 01 01 06 01 00 00 00 00 00 00 00 Class: ELF32 Data: 2's complement, little endian Version: 1 (current) OS/ABI: UNIX - Solaris ABI Version: 1 Type: DYN (Shared object file) Machine: Intel 80386 Version: 0x1 Entry point address: 0x0 Start of program headers: 52 (bytes into file) Start of section headers: 12459088 (bytes into file) Flags: 0x0 Size of this header: 52 (bytes) Size of program headers: 32 (bytes) Number of program headers: 5 Size of section headers: 40 (bytes) Number of section headers: 2202 Section header string table index: 2201 Section Headers: [Nr] Name Type Addr Off Size ES Flg Lk Inf Al [ 0] NULL 00000000 000000 000000 00 0 0 0 [ 1] .dynamic DYNAMIC 000000d4 0000d4 0001a8 08 A 7 0 4 [ 2] .eh_frame_hdr PROGBITS 0000027c 00027c 006584 00 A 0 0 4 [ 3] .SUNW_syminfo VERDEF 00006800 006800 005508 04 AI 6 1 4 [ 4] .hash HASH 0000bd08 00bd08 00aa14 04 A 6 0 4 [ 5] .SUNW_ldynsym LOOS+ffffff3 0001671c 01671c 004f30 10 A 7 1267 4 [ 6] .dynsym DYNSYM 0001b64c 01b64c 015420 10 A 7 2 4 [ 7] .dynstr STRTAB 00030a6c 030a6c 0505de 00 AS 0 0 1 [ 8] .SUNW_version VERNEED 0008104c 08104c 000110 01 A 7 4 4 [ 9] .SUNW_version VERDEF 0008115c 08115c 00059c 01 A 7 41 4 [10] .SUNW_versym VERSYM 000816f8 0816f8 002a84 02 A 6 0 4 [11] .SUNW_dynsymsort LOOS+ffffff1 0008417c 08417c 006344 04 A 5 0 4 [12] .SUNW_dyntlssort LOOS+ffffff2 0008a4c0 08a4c0 000008 04 A 5 0 4 [13] .SUNW_reloc REL 0008a4c8 08a4c8 007b40 08 A 6 0 4 [14] .rel.plt REL 00092008 092008 001a80 08 AI 6 1970 4 [15] .rodata._ZNKSt10l PROGBITS 00093a88 093a88 000010 01 AMS 0 0 1 ... [669] .rodata._ZNSt7__c PROGBITS 0009b2dc 09b2dc 00002a 01 AMS 0 0 4 [670] .rodata._ZNSt7__c PROGBITS 0009b308 09b308 00002a 01 AMS 0 0 4 [671] .plt PROGBITS 0009b334 09b334 003510 10 AX 0 0 4 [672] .text PROGBITS 0009e850 09e850 0a7cb5 00 AX 0 0 16 [673] .init PROGBITS 00146510 146510 00001d 00 AX 0 0 16 [674] .fini PROGBITS 00146530 146530 000018 00 AX 0 0 16 [675] .text.unlikely._Z PROGBITS 00146548 146548 000090 00 AX 0 0 2 [676] .text._ZNSi6ignor PROGBITS 001465e0 1465e0 0001d2 00 AX 0 0 16 [677] .text.unlikely._Z PROGBITS 001467b2 1467b2 000090 00 AX 0 0 2 [678] .text._ZNSt13basi PROGBITS 00146850 146850 0001c8 00 AX 0 0 16 ... [2189] .bss._ZGVZN12_GLO NOBITS 001db090 1cb090 000008 00 WA 0 0 8 [2190] .symtab SYMTAB 00000000 1c8830 028690 10 2191 4905 4 [2191] .strtab STRTAB 00000000 1f0ec0 055620 00 S 0 0 1 [2192] .comment PROGBITS 00000000 2464e0 000099 01 MS 0 0 1 [2193] .debug_frame PROGBITS 00000000 24657c 04dda0 00 0 0 4 [2194] .debug_info PROGBITS 00000000 29431c 493301 00 0 0 1 [2195] .debug_abbrev PROGBITS 00000000 72761d 047d97 00 0 0 1 [2196] .debug_loc PROGBITS 00000000 76f3b4 1a238a 00 0 0 1 [2197] .debug_aranges PROGBITS 00000000 91173e 00a390 00 0 0 1 [2198] .debug_ranges PROGBITS 00000000 91bace 06d018 00 0 0 1 [2199] .debug_line PROGBITS 00000000 988ae6 199eb2 00 0 0 1 [2200] .debug_str PROGBITS 00000000 b22998 0a3c22 01 MS 0 0 1 [2201] .shstrtab STRTAB 00000000 bc65ba 01b693 00 S 0 0 1 Key to Flags: W (write), A (alloc), X (execute), M (merge), S (strings) I (info), L (link order), G (group), T (TLS), E (exclude), x (unknown) O (extra OS processing required) o (OS specific), p (processor specific) Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align LOAD 0x000000 0x00000000 0x00000000 0x17b617 0x17b617 R E 0x10000 LOAD 0x17b618 0x0018b618 0x00000000 0x4d218 0x4fa80 RWE 0x10000 DYNAMIC 0x0000d4 0x000000d4 0x00000000 0x001a8 0x00000 RWE 0 TLS 0x1c8830 0x001d8830 0x00000000 0x00000 0x00010 RW 0x4 LOOS+464e550 0x00027c 0x0000027c 0x00000000 0x064dc 0x064dc R 0x4 Section to Segment mapping: Segment Sections... 00 .dynamic .eh_frame_hdr .SUNW_syminfo .hash .SUNW_ldynsym .dynsym .dynstr .SUNW_version .SUNW_version .SUNW_versym .SUNW_dynsymsort .SUNW_dyntlssort .SUNW_reloc .rel.plt .rodata._ZNKSt10lock_error4whatEv.str1.1 .rodata._ZNKSt12_GLOBAL__N_122generic_error_category4nameEv.str1.1 .rodata._ZNKSt12_GLOBAL__N_121system_error_category4nameEv.str1.1 ... A+ Paul > Message du 11/02/18 22:40 > De : "John Reiser" > A : val...@li... > Copie à : > Objet : Re: [Valgrind-users] rodata warning > > >>> --18142-- WARNING: Serious error when reading debug info >>> --18142-- When reading debug info from /export/home/paulf/tools/gcc/lib/libstdc++.so.6.0.25: >>> --18142-- Can't make sense of .rodata section mapping >>> (GCC SVN head, Solaris 11.3, Valgrind git head). >> What does >> readelf --headers .../libstdc++.so.6.0.25 >> say about the ElfXX_Shdrs and ElfXX_Phdrs, >> and the mapping of the Shdrs into the Phdrs ? > I don’t see any Elf hdrs as above in the output. Here is the output on Linux. Is there something equivalent on Solaris? ====== $ readelf --headers /lib64/libstdc++.so.6 ELF Header: Magic: 7f 45 4c 46 02 01 01 03 00 00 00 00 00 00 00 00 Class: ELF64 Data: 2's complement, little endian Version: 1 (current) OS/ABI: UNIX - GNU ABI Version: 0 Type: DYN (Shared object file) Machine: Advanced Micro Devices X86-64 Version: 0x1 Entry point address: 0x8b880 Start of program headers: 64 (bytes into file) Start of section headers: 1588608 (bytes into file) Flags: 0x0 Size of this header: 64 (bytes) Size of program headers: 56 (bytes) Number of program headers: 8 Size of section headers: 64 (bytes) Number of section headers: 33 Section header string table index: 32 Section Headers: [Nr] Name Type Address Offset Size EntSize Flags Link Info Align [ 0] NULL 0000000000000000 00000000 0000000000000000 0000000000000000 0 0 0 [ 1] .note.gnu.build-i NOTE 0000000000000200 00000200 0000000000000024 0000000000000000 A 0 0 4 [ 2] .gnu.hash GNU_HASH 0000000000000228 00000228 0000000000008410 0000000000000000 A 3 0 8 [ 3] .dynsym DYNSYM 0000000000008638 00008638 00000000000205e0 0000000000000018 A 4 3 8 [ 4] .dynstr STRTAB 0000000000028c18 00028c18 0000000000040f7f 0000000000000000 A 0 0 1 [ 5] .gnu.version VERSYM 0000000000069b98 00069b98 0000000000002b28 0000000000000002 A 3 0 2 [ 6] .gnu.version_d VERDEF 000000000006c6c0 0006c6c0 000000000000050c 0000000000000000 A 4 37 8 [ 7] .gnu.version_r VERNEED 000000000006cbd0 0006cbd0 0000000000000100 0000000000000000 A 4 4 8 [ 8] .rela.dyn RELA 000000000006ccd0 0006ccd0 0000000000016aa0 0000000000000018 A 3 0 8 [ 9] .rela.plt RELA 0000000000083770 00083770 0000000000004ce0 0000000000000018 AI 3 27 8 [10] .init PROGBITS 0000000000088450 00088450 0000000000000017 0000000000000000 AX 0 0 4 [11] .plt PROGBITS 0000000000088470 00088470 0000000000003350 0000000000000010 AX 0 0 16 [12] .plt.got PROGBITS 000000000008b7c0 0008b7c0 00000000000000b8 0000000000000000 AX 0 0 8 [13] .text PROGBITS 000000000008b880 0008b880 00000000000af149 0000000000000000 AX 0 0 16 [14] .fini PROGBITS 000000000013a9cc 0013a9cc 0000000000000009 0000000000000000 AX 0 0 4 [15] .rodata PROGBITS 000000000013a9e0 0013a9e0 0000000000008258 0000000000000000 A 0 0 32 [16] .stapsdt.base PROGBITS 0000000000142c38 00142c38 0000000000000001 0000000000000000 A 0 0 1 [17] .eh_frame_hdr PROGBITS 0000000000142c3c 00142c3c 0000000000007714 0000000000000000 A 0 0 4 [18] .eh_frame PROGBITS 000000000014a350 0014a350 000000000002717c 0000000000000000 A 0 0 8 [19] .gcc_except_table PROGBITS 00000000001714cc 001714cc 0000000000006356 0000000000000000 A 0 0 4 [20] .tbss NOBITS 0000000000378318 00178318 0000000000000020 0000000000000000 WAT 0 0 8 [21] .init_array INIT_ARRAY 0000000000378318 00178318 0000000000000058 0000000000000000 WA 0 0 8 [22] .fini_array FINI_ARRAY 0000000000378370 00178370 0000000000000008 0000000000000000 WA 0 0 8 [23] .jcr PROGBITS 0000000000378378 00178378 0000000000000008 0000000000000000 WA 0 0 8 [24] .data.rel.ro PROGBITS 0000000000378380 00178380 00000000000089c8 0000000000000000 WA 0 0 32 [25] .dynamic DYNAMIC 0000000000380d48 00180d48 0000000000000220 0000000000000010 WA 4 0 8 [26] .got PROGBITS 0000000000380f68 00180f68 0000000000001098 0000000000000008 WA 0 0 8 [27] .got.plt PROGBITS 0000000000382000 00182000 00000000000019b8 0000000000000008 WA 0 0 8 [28] .data PROGBITS 00000000003839c0 001839c0 0000000000000178 0000000000000000 WA 0 0 32 [29] .bss NOBITS 0000000000383b40 00183b38 0000000000003720 0000000000000000 WA 0 0 32 [30] .note.stapsdt NOTE 0000000000000000 00183b38 00000000000000ec 0000000000000000 0 0 4 [31] .gnu_debuglink PROGBITS 0000000000000000 00183c24 0000000000000020 0000000000000000 0 0 4 [32] .shstrtab STRTAB 0000000000000000 00183c44 000000000000013c 0000000000000000 0 0 1 Key to Flags: W (write), A (alloc), X (execute), M (merge), S (strings), l (large) I (info), L (link order), G (group), T (TLS), E (exclude), x (unknown) O (extra OS processing required) o (OS specific), p (processor specific) Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align LOAD 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000177822 0x0000000000177822 R E 200000 LOAD 0x0000000000178318 0x0000000000378318 0x0000000000378318 0x000000000000b820 0x000000000000ef48 RW 200000 DYNAMIC 0x0000000000180d48 0x0000000000380d48 0x0000000000380d48 0x0000000000000220 0x0000000000000220 RW 8 NOTE 0x0000000000000200 0x0000000000000200 0x0000000000000200 0x0000000000000024 0x0000000000000024 R 4 TLS 0x0000000000178318 0x0000000000378318 0x0000000000378318 0x0000000000000000 0x0000000000000020 R 8 GNU_EH_FRAME 0x0000000000142c3c 0x0000000000142c3c 0x0000000000142c3c 0x0000000000007714 0x0000000000007714 R 4 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RW 10 GNU_RELRO 0x0000000000178318 0x0000000000378318 0x0000000000378318 0x0000000000009ce8 0x0000000000009ce8 R 1 Section to Segment mapping: Segment Sections... 00 .note.gnu.build-id .gnu.hash .dynsym .dynstr .gnu.version .gnu.version_d .gnu.version_r .rela.dyn .rela.plt .init .plt .plt.got .text .fini .rodata .stapsdt.base .eh_frame_hdr .eh_frame .gcc_except_table 01 .init_array .fini_array .jcr .data.rel.ro .dynamic .got .got.plt .data .bss 02 .dynamic 03 .note.gnu.build-id 04 .tbss 05 .eh_frame_hdr 06 07 .init_array .fini_array .jcr .data.rel.ro .dynamic .got ===== ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Valgrind-users mailing list Val...@li... https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: Julian S. <js...@ac...> - 2018-02-12 20:09:12
|
I would also be in favour of removing it. Doing so would remove several thousand LOC from the tree, perhaps over 10K. Anything that sgcheck can do, ASan can do faster and with a lower noise level. So I don't think it would be missed. J |
|
From: Ivo R. <iv...@iv...> - 2018-02-12 19:46:21
|
2018-02-12 16:27 GMT+01:00 Mark Wielaard <ma...@kl...>: > Hi, > > The experimental sgcheck tool is in a pretty bad state. On some systems > it doesn't even run a simple /bin/true program because it doesn't > support guarded loads/stores. It is also the only tool which really > uses some of the debuginfo var/type/location data. Given the tool has > been experimental, nobody is working on fixing it, it has been broken > since some years now and it prevents some cleanups/updates to the > debuginfo reader I am proposing to remove it. > > If the tool is really important to you, then please let me know if you > can help with maintaining it. Thank you, Mark, for bringing this topic. I am in agreement. I. |
|
From: Mark W. <ma...@kl...> - 2018-02-12 15:27:40
|
Hi, The experimental sgcheck tool is in a pretty bad state. On some systems it doesn't even run a simple /bin/true program because it doesn't support guarded loads/stores. It is also the only tool which really uses some of the debuginfo var/type/location data. Given the tool has been experimental, nobody is working on fixing it, it has been broken since some years now and it prevents some cleanups/updates to the debuginfo reader I am proposing to remove it. If the tool is really important to you, then please let me know if you can help with maintaining it. Thanks, Mark |
|
From: Ivo R. <iv...@iv...> - 2018-02-12 12:53:14
|
2018-02-11 22:17 GMT+01:00 Paul Floyd <pj...@wa...>:
>
>
>> On 11 Feb 2018, at 21:36, John Reiser <jr...@bi...> wrote:
>>
>>> --18142-- WARNING: Serious error when reading debug info
>>> --18142-- When reading debug info from /export/home/paulf/tools/gcc/lib/libstdc++.so.6.0.25:
>>> --18142-- Can't make sense of .rodata section mapping
>>> (GCC SVN head, Solaris 11.3, Valgrind git head).
>>
>> What does
>> readelf --headers .../libstdc++.so.6.0.25
>> say about the ElfXX_Shdrs and ElfXX_Phdrs,
>> and the mapping of the Shdrs into the Phdrs?
I don't have libstdc++.so.6.0.25.
I have stock libstdc++.so.6.0.21 which is installed with Solaris 11.3
SRU 28 (currently the latest).
readelf --headers /usr/lib/64/libstdc++.so.6.0.21 returns:
ELF Header:
Magic: 7f 45 4c 46 02 01 01 06 01 00 00 00 00 00 00 00
Class: ELF64
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - Solaris
ABI Version: 1
Type: DYN (Shared object file)
Machine: Advanced Micro Devices X86-64
Version: 0x1
Entry point address: 0x0
Start of program headers: 64 (bytes into file)
Start of section headers: 11713976 (bytes into file)
Flags: 0x0
Size of this header: 64 (bytes)
Size of program headers: 56 (bytes)
Number of program headers: 5
Size of section headers: 64 (bytes)
Number of section headers: 2148
Section header string table index: 2146
Section Headers:
[Nr] Name Type Address Offset
Size EntSize Flags Link Info Align
[ 0] NULL 0000000000000000 00000000
0000000000000000 0000000000000000 0 0 0
[ 1] .dynamic DYNAMIC 0000000000000158 00000158
0000000000000370 0000000000000010 A 8 0 8
[ 2] .eh_frame_hdr X86_64_UNWIND 00000000000004c8 000004c8
0000000000007f44 0000000000000000 A 0 0 8
[ 3] .eh_frame X86_64_UNWIND 0000000000008410 00008410
0000000000023b5c 0000000000000000 A 0 0 8
[ 4] .SUNW_syminfo VERDEF 000000000002bf70 0002bf70
000000000000541c 0000000000000004 AI 7 1 8
[ 5] .hash HASH 0000000000031390 00031390
000000000000a838 0000000000000004 A 7 0 8
[ 6] .SUNW_ldynsym LOOS+ffffff3 000000000003bbc8 0003bbc8
0000000000005868 0000000000000018 A 8 943 8
[ 7] .dynsym DYNSYM 0000000000041430 00041430
000000000001f8a8 0000000000000018 A 8 2 8
[ 8] .dynstr STRTAB 0000000000060cd8 00060cd8
000000000004b69a 0000000000000000 AS 0 0 1
[ 9] .SUNW_version VERNEED 00000000000ac378 000ac378
0000000000000100 0000000000000001 A 8 4 8
[10] .SUNW_version VERDEF 00000000000ac478 000ac478
00000000000004c4 0000000000000001 A 8 35 8
[11] .SUNW_versym VERSYM 00000000000ac940 000ac940
0000000000002a0e 0000000000000002 A 7 0 8
[12] .SUNW_dynsymsort LOOS+ffffff1 00000000000af350 000af350
0000000000005ddc 0000000000000004 A 6 0 8
[13] .SUNW_dyntlssort LOOS+ffffff2 00000000000b5130 000b5130
0000000000000008 0000000000000004 A 6 0 8
[14] .SUNW_reloc RELA 00000000000b5138 000b5138
0000000000017160 0000000000000018 A 7 0 8
[15] .rela.plt RELA 00000000000cc298 000cc298
0000000000004c98 0000000000000018 AI 7 1916 8
[16] .gcc_except_table PROGBITS 00000000000d0f30 000d0f30
0000000000007232 0000000000000000 A 0 0 4
[17] .rodata.str1.1 PROGBITS 00000000000d8162 000d8162
0000000000000ce2 0000000000000001 AMS 0 0 1
[18] .rodata._ZTSSt10l PROGBITS 00000000000d8e48 000d8e48
000000000000000f 0000000000000000 A 0 0 8
[19] .rodata._ZTSSt14e PROGBITS 00000000000d8e60 000d8e60
0000000000000013 0000000000000000 A 0 0 16
[...and much more .rodata_* sections, up to...]
[2147] .SUNW_signature GNU_HASH 0000000000000000 00b2bc1e
0000000000000198 0000000000000000 E 0 0 1
Key to Flags:
W (write), A (alloc), X (execute), M (merge), S (strings), l (large)
I (info), L (link order), G (group), T (TLS), E (exclude), x (unknown)
O (extra OS processing required) o (OS specific), p (processor specific)
Program Headers:
Type Offset VirtAddr PhysAddr
FileSiz MemSiz Flags Align
LOAD 0x0000000000000000 0x0000000000000000 0x0000000000000000
0x00000000001a6f65 0x00000000001a6f65 R E 100000
LOAD 0x00000000001a7000 0x00000000002a7000 0x0000000000000000
0x000000000000bd78 0x000000000000f850 RW 100000
DYNAMIC 0x0000000000000158 0x0000000000000158 0x0000000000000000
0x0000000000000370 0x0000000000000000 RW 0
TLS 0x00000000001b2d78 0x00000000002b2d78 0x0000000000000000
0x0000000000000000 0x0000000000000020 RW 8
LOOS+464e550 0x00000000000004c8 0x00000000000004c8 0x0000000000000000
0x0000000000007c14 0x0000000000007c14 R 8
Section to Segment mapping:
Segment Sections...
00 .dynamic .eh_frame_hdr .eh_frame .SUNW_syminfo .hash
.SUNW_ldynsym .dynsym .dynstr .SUNW_version .SUNW_version .SUNW_versym
.SUNW_dynsymsort .SUNW_dyntlssort .SUNW_reloc .rela.plt
.gcc_except_table .rodata.str1.1 .rodata._ZTSSt10lock_error
.rodata._ZTSSt14error_category
.rodata._ZTSNSt12_GLOBAL__N_122generic_error_categoryE
.rodata._ZTSNSt12_GLOBAL__N_121system_error_categoryE
.rodata._ZNSt6chrono12system_clock12is_monotonicE
.rodata._ZTSNSt13__future_base11_State_baseE
.rodata._ZTSNSt13__future_base19_Async_state_commonE
.rodata._ZNSt6chrono12system_clock9is_steadyE
.rodata._ZTSN10__cxxabiv117__array_type_infoE ... [much more entries]
01 .got .fini_array .init_array .data .jcr .tm_clone_table
.data._ZL16__gthread_active
.data.rel.ro._ZTINSt12_GLOBAL__N_122generic_error_categoryE
.data.rel.ro._ZTINSt12_
GLOBAL__N_121system_error_categoryE
.data.rel.ro._ZTVNSt12_GLOBAL__N_122generic_error_categoryE
.data.rel.ro._ZTVNSt12_GLOBAL__N_121system_error_categoryE
.data._ZZL18__gthread_
active_pvE22__gthread_active_mutex
.data._ZZN12_GLOBAL__N_116get_atomic_mutexEvE12atomic_mutex
.data.rel._ZN10__cxxabiv119__terminate_handlerE
.data.rel._ZN10__cxxabiv120__unexp
ected_handlerE .data.rel.ro.local
.data.rel.ro._ZNSt6locale17_S_twinned_facetsE
.data.rel.ro._ZNSt6locale5_Impl19_S_facet_categoriesE
.data.rel.ro._ZNSt6locale5_Impl14_S_id_mess
agesE .data.rel.ro._ZNSt6locale5_Impl14_S_id_monetaryE
.data.rel.ro._ZNSt6locale5_Impl10_S_id_timeE
.data.rel.ro._ZNSt6locale5_Impl13_S_id_collateE
.data.rel.ro._ZNSt6locale5_Im
pl13_S_id_numericE .data.rel.ro._ZNSt6locale5_Impl11_S_id_ctypeE
.data.rel.local._ZNSt10__num_base12_S_atoms_outE
.data.rel.local._ZNSt10__num_base11_S_atoms_inE .data.rel.local
._ZNSt10money_base8_S_atomsE
.data.rel.local._ZNSt17__timepunct_cacheIwE12_S_timezonesE
.data.rel.local._ZNSt17__timepunct_cacheIcE12_S_timezonesE
.data.rel.ro.local._ZNSt6local
e13_S_categoriesE .data.rel.ro.local._ZN9__gnu_cxxL14category_namesE
.data.rel.ro.local._ZZNK11__gnu_debug16_Error_formatter10_Parameter14_M_print_fieldEPKS0_PKcE13__state_names
.data.rel.ro.local._ZZNK11__gnu_debug16_Error_formatter10_Parameter14_M_print_fieldEPKS0_PKcE17__constness_names
.data.rel.local._ZN11__gnu_debug17_S_debug_messagesE .data.rel.
local._ZZN12_GLOBAL__N_126__future_category_instanceEvE5__fec ....
[much more entries]
02
03 .tbss._ZZN12_GLOBAL__N_110get_globalEvE6global
.tbss._ZSt11__once_call .tbss._ZSt15__once_callable
04
Valgrind version valgrind-3.14.0.GIT-5a705cfa90-20180118 on Solaris
11.3 x86 has no problem reading debug info from this libstdc++.so.
There is also native Solaris utility called "elfdump".
You can invoke 'elfdump -p -c -s' on libstdc++.so.6.0.21 and
libstdc++.so.6.0.25 and compare for significant differences.
I.
|
|
From: John R. <jr...@bi...> - 2018-02-11 21:39:32
|
>>> --18142-- WARNING: Serious error when reading debug info
>>> --18142-- When reading debug info from /export/home/paulf/tools/gcc/lib/libstdc++.so.6.0.25:
>>> --18142-- Can't make sense of .rodata section mapping
>>> (GCC SVN head, Solaris 11.3, Valgrind git head).
>> What does
>> readelf --headers .../libstdc++.so.6.0.25
>> say about the ElfXX_Shdrs and ElfXX_Phdrs,
>> and the mapping of the Shdrs into the Phdrs ?
> I don’t see any Elf hdrs as above in the output.
Here is the output on Linux. Is there something equivalent on Solaris?
======
$ readelf --headers /lib64/libstdc++.so.6
ELF Header:
Magic: 7f 45 4c 46 02 01 01 03 00 00 00 00 00 00 00 00
Class: ELF64
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - GNU
ABI Version: 0
Type: DYN (Shared object file)
Machine: Advanced Micro Devices X86-64
Version: 0x1
Entry point address: 0x8b880
Start of program headers: 64 (bytes into file)
Start of section headers: 1588608 (bytes into file)
Flags: 0x0
Size of this header: 64 (bytes)
Size of program headers: 56 (bytes)
Number of program headers: 8
Size of section headers: 64 (bytes)
Number of section headers: 33
Section header string table index: 32
Section Headers:
[Nr] Name Type Address Offset
Size EntSize Flags Link Info Align
[ 0] NULL 0000000000000000 00000000
0000000000000000 0000000000000000 0 0 0
[ 1] .note.gnu.build-i NOTE 0000000000000200 00000200
0000000000000024 0000000000000000 A 0 0 4
[ 2] .gnu.hash GNU_HASH 0000000000000228 00000228
0000000000008410 0000000000000000 A 3 0 8
[ 3] .dynsym DYNSYM 0000000000008638 00008638
00000000000205e0 0000000000000018 A 4 3 8
[ 4] .dynstr STRTAB 0000000000028c18 00028c18
0000000000040f7f 0000000000000000 A 0 0 1
[ 5] .gnu.version VERSYM 0000000000069b98 00069b98
0000000000002b28 0000000000000002 A 3 0 2
[ 6] .gnu.version_d VERDEF 000000000006c6c0 0006c6c0
000000000000050c 0000000000000000 A 4 37 8
[ 7] .gnu.version_r VERNEED 000000000006cbd0 0006cbd0
0000000000000100 0000000000000000 A 4 4 8
[ 8] .rela.dyn RELA 000000000006ccd0 0006ccd0
0000000000016aa0 0000000000000018 A 3 0 8
[ 9] .rela.plt RELA 0000000000083770 00083770
0000000000004ce0 0000000000000018 AI 3 27 8
[10] .init PROGBITS 0000000000088450 00088450
0000000000000017 0000000000000000 AX 0 0 4
[11] .plt PROGBITS 0000000000088470 00088470
0000000000003350 0000000000000010 AX 0 0 16
[12] .plt.got PROGBITS 000000000008b7c0 0008b7c0
00000000000000b8 0000000000000000 AX 0 0 8
[13] .text PROGBITS 000000000008b880 0008b880
00000000000af149 0000000000000000 AX 0 0 16
[14] .fini PROGBITS 000000000013a9cc 0013a9cc
0000000000000009 0000000000000000 AX 0 0 4
[15] .rodata PROGBITS 000000000013a9e0 0013a9e0
0000000000008258 0000000000000000 A 0 0 32
[16] .stapsdt.base PROGBITS 0000000000142c38 00142c38
0000000000000001 0000000000000000 A 0 0 1
[17] .eh_frame_hdr PROGBITS 0000000000142c3c 00142c3c
0000000000007714 0000000000000000 A 0 0 4
[18] .eh_frame PROGBITS 000000000014a350 0014a350
000000000002717c 0000000000000000 A 0 0 8
[19] .gcc_except_table PROGBITS 00000000001714cc 001714cc
0000000000006356 0000000000000000 A 0 0 4
[20] .tbss NOBITS 0000000000378318 00178318
0000000000000020 0000000000000000 WAT 0 0 8
[21] .init_array INIT_ARRAY 0000000000378318 00178318
0000000000000058 0000000000000000 WA 0 0 8
[22] .fini_array FINI_ARRAY 0000000000378370 00178370
0000000000000008 0000000000000000 WA 0 0 8
[23] .jcr PROGBITS 0000000000378378 00178378
0000000000000008 0000000000000000 WA 0 0 8
[24] .data.rel.ro PROGBITS 0000000000378380 00178380
00000000000089c8 0000000000000000 WA 0 0 32
[25] .dynamic DYNAMIC 0000000000380d48 00180d48
0000000000000220 0000000000000010 WA 4 0 8
[26] .got PROGBITS 0000000000380f68 00180f68
0000000000001098 0000000000000008 WA 0 0 8
[27] .got.plt PROGBITS 0000000000382000 00182000
00000000000019b8 0000000000000008 WA 0 0 8
[28] .data PROGBITS 00000000003839c0 001839c0
0000000000000178 0000000000000000 WA 0 0 32
[29] .bss NOBITS 0000000000383b40 00183b38
0000000000003720 0000000000000000 WA 0 0 32
[30] .note.stapsdt NOTE 0000000000000000 00183b38
00000000000000ec 0000000000000000 0 0 4
[31] .gnu_debuglink PROGBITS 0000000000000000 00183c24
0000000000000020 0000000000000000 0 0 4
[32] .shstrtab STRTAB 0000000000000000 00183c44
000000000000013c 0000000000000000 0 0 1
Key to Flags:
W (write), A (alloc), X (execute), M (merge), S (strings), l (large)
I (info), L (link order), G (group), T (TLS), E (exclude), x (unknown)
O (extra OS processing required) o (OS specific), p (processor specific)
Program Headers:
Type Offset VirtAddr PhysAddr
FileSiz MemSiz Flags Align
LOAD 0x0000000000000000 0x0000000000000000 0x0000000000000000
0x0000000000177822 0x0000000000177822 R E 200000
LOAD 0x0000000000178318 0x0000000000378318 0x0000000000378318
0x000000000000b820 0x000000000000ef48 RW 200000
DYNAMIC 0x0000000000180d48 0x0000000000380d48 0x0000000000380d48
0x0000000000000220 0x0000000000000220 RW 8
NOTE 0x0000000000000200 0x0000000000000200 0x0000000000000200
0x0000000000000024 0x0000000000000024 R 4
TLS 0x0000000000178318 0x0000000000378318 0x0000000000378318
0x0000000000000000 0x0000000000000020 R 8
GNU_EH_FRAME 0x0000000000142c3c 0x0000000000142c3c 0x0000000000142c3c
0x0000000000007714 0x0000000000007714 R 4
GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000
0x0000000000000000 0x0000000000000000 RW 10
GNU_RELRO 0x0000000000178318 0x0000000000378318 0x0000000000378318
0x0000000000009ce8 0x0000000000009ce8 R 1
Section to Segment mapping:
Segment Sections...
00 .note.gnu.build-id .gnu.hash .dynsym .dynstr .gnu.version .gnu.version_d .gnu.version_r .rela.dyn .rela.plt .init .plt .plt.got .text .fini .rodata .stapsdt.base .eh_frame_hdr .eh_frame .gcc_except_table
01 .init_array .fini_array .jcr .data.rel.ro .dynamic .got .got.plt .data .bss
02 .dynamic
03 .note.gnu.build-id
04 .tbss
05 .eh_frame_hdr
06
07 .init_array .fini_array .jcr .data.rel.ro .dynamic .got
=====
|
|
From: Paul F. <pj...@wa...> - 2018-02-11 21:17:26
|
> On 11 Feb 2018, at 21:36, John Reiser <jr...@bi...> wrote: > >> --18142-- WARNING: Serious error when reading debug info >> --18142-- When reading debug info from /export/home/paulf/tools/gcc/lib/libstdc++.so.6.0.25: >> --18142-- Can't make sense of .rodata section mapping >> (GCC SVN head, Solaris 11.3, Valgrind git head). > > What does > readelf --headers .../libstdc++.so.6.0.25 > say about the ElfXX_Shdrs and ElfXX_Phdrs, > and the mapping of the Shdrs into the Phdrs ? > > BTW I’m not really expecting any issues with rodata. I don’t see any Elf hdrs as above in the output. A+ Paul |
|
From: John R. <jr...@bi...> - 2018-02-11 20:36:11
|
> --18142-- WARNING: Serious error when reading debug info
> --18142-- When reading debug info from /export/home/paulf/tools/gcc/lib/libstdc++.so.6.0.25:
> --18142-- Can't make sense of .rodata section mapping
>
> (GCC SVN head, Solaris 11.3, Valgrind git head).
What does
readelf --headers .../libstdc++.so.6.0.25
say about the ElfXX_Shdrs and ElfXX_Phdrs,
and the mapping of the Shdrs into the Phdrs ?
|
|
From: Paul F. <pj...@wa...> - 2018-02-11 18:38:46
|
Hi I’m getting this warning: --18142-- WARNING: Serious error when reading debug info --18142-- When reading debug info from /export/home/paulf/tools/gcc/lib/libstdc++.so.6.0.25: --18142-- Can't make sense of .rodata section mapping (GCC SVN head, Solaris 11.3, Valgrind git head). Is it significant? Is there anything I can do about it? Regards Paul |
|
From: Wuweijia <wuw...@hu...> - 2018-02-11 01:35:47
|
Hi:
There is valgrind assert failure when valgrind run the process. But it does not always occurred ,sometimes.
There is only two thread , One the thread is sleeping and waiting the message, another thread is running.
I do not how to debug it, can you show me some idea?
Is there any flags of valgrind output to help me debug or trace the assertion failure.
The output as below:
--8330-- sync signal handler: signal=11, si_code=1, EIP=0x5c670cd, eip=0x834dc4fc, from kernel
--8330-- SIGSEGV: si_code=1 faultaddr=0xfedfbb04 tid=1 ESP=0xfedfbb04 seg=0xfe5ff000-0xfedfbfff
--8330-- -> extended stack base to 0xfedfb000
--8330-- sync signal handler: signal=11, si_code=1, EIP=0x5c23ce1, eip=0x833e782c, from kernel
--8330-- SIGSEGV: si_code=1 faultaddr=0xfedfae44 tid=1 ESP=0xfedfae44 seg=0xfe5ff000-0xfedfafff
--8330-- -> extended stack base to 0xfedfa000
--8330-- sync signal handler: signal=11, si_code=2, EIP=0x5dc84bf, eip=0x835f0014, from kernel
--8330-- SIGSEGV: si_code=2 faultaddr=0x5dc8ce8 tid=1 ESP=0xfedfac50 seg=0x5c0a000-0x5e37fff
--8330-- delivering signal 11 (SIGSEGV):2 to thread 1
--8330-- delivering 11 (code 2) to default handler; action: terminate+core
--8330-- -> extended stack base to 0xfedfa000
--8330-- get_thread_out_of_syscall zaps tid 2 lwp 8331
--8330-- sys_sigaction: sigNo 11, new 0x8326deec, old 0x0, new flags 0x0
--8330-- sys_sigaction: sigNo 7, new 0x8326deec, old 0x0, new flags 0x0
--8330-- sys_sigaction: sigNo 4, new 0x8326deec, old 0x0, new flags 0x0
--8330-- sys_sigaction: sigNo 8, new 0x8326deec, old 0x0, new flags 0x0
valgrind: external/valgrind/coregrind/m_scheduler/scheduler.c:2240 (vgPlain_sanity_check_general): Assertion 'VG_TDICT_CALL(tool_expensive_sanity_check)' failed.
host stacktrace:
==8330== at 0x3804793C: show_sched_status_wrk (m_libcassert.c:343)
sched status:
running_tid=1
Note: see also the FAQ in the source distribution.
It contains workarounds to several common problems.
In particular, if Valgrind aborted or crashed after
identifying problems in your program, there's a good chance
that fixing those problems will prevent Valgrind aborting or
crashing, especially if it happened in m_mallocfree.c.
Env:
Version: 3.12.
CPU : Aarch64
ABI: armeabi-v7a
OS: android
BR
Owen
|
|
From: John R. <jr...@bi...> - 2018-02-07 23:28:53
|
> when I run Valgrind on my executable it starts and then always fails after printing out this error: > Thread 9: status = VgTs_Runnable (lwpid 2354) > ==2333== at 0x6C5BCC: sys_clone (linux_syscall_support.h:2666) > ==2333== by 0x6C5BCC: google_breakpad::ExceptionHandler::GenerateDump(google_breakpad::ExceptionHandler::CrashContext*) (exception_handler.cc:527) > ==2333== by 0x6C60C3: google_breakpad::ExceptionHandler::SignalHandler(int, siginfo_t*, void*) (exception_handler.cc:368) > ==2333== by 0x4CE5ACF: ??? (in /lib/libc-2.22.so <http://libc-2.22.so>) There is a good chance that the combination of the app and Android does not behave in the way that valgrind expects a process to behave. Android does not necessarily have the same behavior as Linux, and the differences can lead to SIGSEGV, etc. Run the whole thing (your app under valgrind) under the Android equivalent of 'strace', and pay particular attention to the layout of the address space (mmap, etc.) Also turn on --trace-syscalls=yes and --trace-signals=yes and -v -v -v to see what valgrind is up to. |
|
From: John R. <jr...@bi...> - 2018-02-07 23:11:40
|
>> This code below takes 31 seconds elapsed bare, and 36 seconds elapsed under valgrind. >> The charged CPU time is 119 seconds bare, 35 seconds under valgrind. > > That was valgrind-3.12.0. > With valgrind-3.13.0 on Core i5-6500 CPU @ 3.20 GHz, > I see 34 seconds bare (129 CPU seconds), > and 25 seconds valgrind ( 25 CPU seconds). With --fair-sched=yes: 3.12.0: 50 seconds elapsed, 50 seconds CPU [i5-2500. 3.3GHz] 3.13.0: 54 seconds elapsed, 54 seconds CPU [i5-6500, 3.2GHz] |
|
From: John R. <jr...@bi...> - 2018-02-07 21:34:29
|
> This code below takes 31 seconds elapsed bare, and 36 seconds elapsed under valgrind. > The charged CPU time is 119 seconds bare, 35 seconds under valgrind. That was valgrind-3.12.0. With valgrind-3.13.0 on Core i5-6500 CPU @ 3.20 GHz, I see 34 seconds bare (129 CPU seconds), and 25 seconds valgrind ( 25 CPU seconds). |
|
From: Adam S. <ada...@gm...> - 2018-02-07 21:32:29
|
That's a good point. The application runs fine on its own though. It is just when run inside Valgrind that there is a problem. On Wed, Feb 7, 2018 at 3:29 PM, Tom Hughes <to...@co...> wrote: > If I'm reading that right it is coming from the breakpad exception handler > which I can well believe is using clone with some odd flag set to do some > crazy stuff. > > Of course if you've got there then the process is already dead anyway so > I'm not sure how much it matters? > > Tom > > On 07/02/18 21:25, Adam Scott wrote: > >> Even with the patches from that bug the error still occurred. >> >> On Wed, Feb 7, 2018 at 3:16 PM, Adam Scott <ada...@gm... <mailto: >> ada...@gm...>> wrote: >> >> I am using the latest version 3.13. I will pull down that patch and >> try it out. >> >> On Wed, Feb 7, 2018 at 3:03 PM, Philippe Waroquiers >> <phi...@sk... >> <mailto:phi...@sk...>> wrote: >> >> Which version are you using ? >> Some improvements to clone handling was done in 3.13 : >> * On Linux, clone handling has been improved to honour >> CLONE_VFORK that >> involves a child stack. Note however that CLONE_VFORK | >> CLONE_VM is handled >> like CLONE_VFORK (by removing CLONE_VM), so applications that >> depend on >> CLONE_VM exact semantics will (still) not work. >> >> Otherwise, I am sure we have still a bunch of clone related bugs >> opened. E.g. https://bugs.kde.org/show_bug.cgi?id=183406 >> <https://bugs.kde.org/show_bug.cgi?id=183406> >> and https://bugs.kde.org/show_bug.cgi?id=386427 >> <https://bugs.kde.org/show_bug.cgi?id=386427> which has >> a patch, and might be what you have encountered. >> >> Philippe >> >> >> On Wed, 2018-02-07 at 14:51 -0600, Adam Scott wrote: >> > I'm hoping someone else has seen this issue and is able to >> help me. I have search all over the internet for a solution and >> haven't been able to find one. I am trying to run Valgrind on >> armv7 architecture, and after compiling Valgrind and getting it >> onto the target I am able to run Valgrind successfully on 'ls >> -l' but when I run Valgrind on my executable it starts and then >> always fails after printing out this error: >> > >> > ==2333== Unsupported clone() flags: 0x800600 >> > ==2333== >> > ==2333== The only supported clone() uses are: >> > ==2333== - via a threads library (LinuxThreads or NPTL) >> > ==2333== - via the implementation of fork or vfork >> > ==2333== >> > ==2333== Valgrind detected that your program requires >> > ==2333== the following unimplemented functionality: >> > ==2333== Valgrind does not support general clone(). >> > ==2333== This may be because the functionality is hard to >> implement, >> > ==2333== or because no reasonable program would behave this >> way, >> > ==2333== or because nobody has yet needed it. In any case, >> let us know at >> > ==2333== www.valgrind.org <http://www.valgrind.org> and/or >> try to work around the problem, if you can. >> > ==2333== >> > ==2333== Valgrind has to exit now. Sorry. Bye! >> > ==2333== >> > >> > sched status: >> > running_tid=9 >> > >> > The thread that has the crash has the following stack: >> > Thread 9: status = VgTs_Runnable (lwpid 2354) >> > ==2333== at 0x6C5BCC: sys_clone >> (linux_syscall_support.h:2666) >> > ==2333== by 0x6C5BCC: >> google_breakpad::ExceptionHandler::GenerateDump(google_ >> breakpad::ExceptionHandler::CrashContext*) >> (exception_handler.cc:527) >> > ==2333== by 0x6C60C3: >> google_breakpad::ExceptionHandler::SignalHandler(int, >> siginfo_t*, void*) (exception_handler.cc:368) >> > ==2333== by 0x4CE5ACF: ??? (in /lib/libc-2.22.so >> <http://libc-2.22.so>) >> > >> ------------------------------------------------------------ >> ------------------ >> > Check out the vibrant tech community on one of the world's most >> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot >> > _______________________________________________ >> > Valgrind-users mailing list >> > Val...@li... >> <mailto:Val...@li...> >> > https://lists.sourceforge.net/lists/listinfo/valgrind-users >> <https://lists.sourceforge.net/lists/listinfo/valgrind-users> >> >> >> >> >> >> ------------------------------------------------------------ >> ------------------ >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >> >> >> >> _______________________________________________ >> Valgrind-users mailing list >> Val...@li... >> https://lists.sourceforge.net/lists/listinfo/valgrind-users >> >> > > -- > Tom Hughes (to...@co...) > http://compton.nu/ > |
|
From: Philippe W. <phi...@sk...> - 2018-02-07 21:31:54
|
On Wed, 2018-02-07 at 15:25 -0600, Adam Scott wrote: > Even with the patches from that bug the error still occurred. Ouch. Bad luck. As I understand from the stack trace, the valgrind crash happens somewhere inside google breakpad, which is itself a crash reporter ? If this is correct, it might be worth trying to see what is the reason of the crash reporter starting up ? And maybe you could disable this crash reporter ? (otherwise, it would be useful to add some info in the bug report references, with the details of your crash, just in case someone looks further on these clone handling limitations. Philippe |
|
From: Tom H. <to...@co...> - 2018-02-07 21:29:42
|
If I'm reading that right it is coming from the breakpad exception handler which I can well believe is using clone with some odd flag set to do some crazy stuff. Of course if you've got there then the process is already dead anyway so I'm not sure how much it matters? Tom On 07/02/18 21:25, Adam Scott wrote: > Even with the patches from that bug the error still occurred. > > On Wed, Feb 7, 2018 at 3:16 PM, Adam Scott <ada...@gm... > <mailto:ada...@gm...>> wrote: > > I am using the latest version 3.13. I will pull down that patch and > try it out. > > On Wed, Feb 7, 2018 at 3:03 PM, Philippe Waroquiers > <phi...@sk... > <mailto:phi...@sk...>> wrote: > > Which version are you using ? > Some improvements to clone handling was done in 3.13 : > * On Linux, clone handling has been improved to honour > CLONE_VFORK that > involves a child stack. Note however that CLONE_VFORK | > CLONE_VM is handled > like CLONE_VFORK (by removing CLONE_VM), so applications that > depend on > CLONE_VM exact semantics will (still) not work. > > Otherwise, I am sure we have still a bunch of clone related bugs > opened. E.g. https://bugs.kde.org/show_bug.cgi?id=183406 > <https://bugs.kde.org/show_bug.cgi?id=183406> > and https://bugs.kde.org/show_bug.cgi?id=386427 > <https://bugs.kde.org/show_bug.cgi?id=386427> which has > a patch, and might be what you have encountered. > > Philippe > > > On Wed, 2018-02-07 at 14:51 -0600, Adam Scott wrote: > > I'm hoping someone else has seen this issue and is able to > help me. I have search all over the internet for a solution and > haven't been able to find one. I am trying to run Valgrind on > armv7 architecture, and after compiling Valgrind and getting it > onto the target I am able to run Valgrind successfully on 'ls > -l' but when I run Valgrind on my executable it starts and then > always fails after printing out this error: > > > > ==2333== Unsupported clone() flags: 0x800600 > > ==2333== > > ==2333== The only supported clone() uses are: > > ==2333== - via a threads library (LinuxThreads or NPTL) > > ==2333== - via the implementation of fork or vfork > > ==2333== > > ==2333== Valgrind detected that your program requires > > ==2333== the following unimplemented functionality: > > ==2333== Valgrind does not support general clone(). > > ==2333== This may be because the functionality is hard to > implement, > > ==2333== or because no reasonable program would behave this way, > > ==2333== or because nobody has yet needed it. In any case, > let us know at > > ==2333== www.valgrind.org <http://www.valgrind.org> and/or > try to work around the problem, if you can. > > ==2333== > > ==2333== Valgrind has to exit now. Sorry. Bye! > > ==2333== > > > > sched status: > > running_tid=9 > > > > The thread that has the crash has the following stack: > > Thread 9: status = VgTs_Runnable (lwpid 2354) > > ==2333== at 0x6C5BCC: sys_clone (linux_syscall_support.h:2666) > > ==2333== by 0x6C5BCC: > google_breakpad::ExceptionHandler::GenerateDump(google_breakpad::ExceptionHandler::CrashContext*) > (exception_handler.cc:527) > > ==2333== by 0x6C60C3: > google_breakpad::ExceptionHandler::SignalHandler(int, > siginfo_t*, void*) (exception_handler.cc:368) > > ==2333== by 0x4CE5ACF: ??? (in /lib/libc-2.22.so > <http://libc-2.22.so>) > > > ------------------------------------------------------------------------------ > > Check out the vibrant tech community on one of the world's most > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > _______________________________________________ > > Valgrind-users mailing list > > Val...@li... > <mailto:Val...@li...> > > https://lists.sourceforge.net/lists/listinfo/valgrind-users > <https://lists.sourceforge.net/lists/listinfo/valgrind-users> > > > > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > > > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > -- Tom Hughes (to...@co...) http://compton.nu/ |
|
From: Adam S. <ada...@gm...> - 2018-02-07 21:25:33
|
Even with the patches from that bug the error still occurred. On Wed, Feb 7, 2018 at 3:16 PM, Adam Scott <ada...@gm...> wrote: > I am using the latest version 3.13. I will pull down that patch and try it > out. > > On Wed, Feb 7, 2018 at 3:03 PM, Philippe Waroquiers < > phi...@sk...> wrote: > >> Which version are you using ? >> Some improvements to clone handling was done in 3.13 : >> * On Linux, clone handling has been improved to honour CLONE_VFORK that >> involves a child stack. Note however that CLONE_VFORK | CLONE_VM is >> handled >> like CLONE_VFORK (by removing CLONE_VM), so applications that depend on >> CLONE_VM exact semantics will (still) not work. >> >> Otherwise, I am sure we have still a bunch of clone related bugs >> opened. E.g. https://bugs.kde.org/show_bug.cgi?id=183406 >> and https://bugs.kde.org/show_bug.cgi?id=386427 which has >> a patch, and might be what you have encountered. >> >> Philippe >> >> >> On Wed, 2018-02-07 at 14:51 -0600, Adam Scott wrote: >> > I'm hoping someone else has seen this issue and is able to help me. I >> have search all over the internet for a solution and haven't been able to >> find one. I am trying to run Valgrind on armv7 architecture, and after >> compiling Valgrind and getting it onto the target I am able to run Valgrind >> successfully on 'ls -l' but when I run Valgrind on my executable it starts >> and then always fails after printing out this error: >> > >> > ==2333== Unsupported clone() flags: 0x800600 >> > ==2333== >> > ==2333== The only supported clone() uses are: >> > ==2333== - via a threads library (LinuxThreads or NPTL) >> > ==2333== - via the implementation of fork or vfork >> > ==2333== >> > ==2333== Valgrind detected that your program requires >> > ==2333== the following unimplemented functionality: >> > ==2333== Valgrind does not support general clone(). >> > ==2333== This may be because the functionality is hard to implement, >> > ==2333== or because no reasonable program would behave this way, >> > ==2333== or because nobody has yet needed it. In any case, let us know >> at >> > ==2333== www.valgrind.org and/or try to work around the problem, if >> you can. >> > ==2333== >> > ==2333== Valgrind has to exit now. Sorry. Bye! >> > ==2333== >> > >> > sched status: >> > running_tid=9 >> > >> > The thread that has the crash has the following stack: >> > Thread 9: status = VgTs_Runnable (lwpid 2354) >> > ==2333== at 0x6C5BCC: sys_clone (linux_syscall_support.h:2666) >> > ==2333== by 0x6C5BCC: google_breakpad::ExceptionHand >> ler::GenerateDump(google_breakpad::ExceptionHandler::CrashContext*) >> (exception_handler.cc:527) >> > ==2333== by 0x6C60C3: google_breakpad::ExceptionHandler::SignalHandler(int, >> siginfo_t*, void*) (exception_handler.cc:368) >> > ==2333== by 0x4CE5ACF: ??? (in /lib/libc-2.22.so) >> > ------------------------------------------------------------ >> ------------------ >> > Check out the vibrant tech community on one of the world's most >> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot >> > _______________________________________________ >> > Valgrind-users mailing list >> > Val...@li... >> > https://lists.sourceforge.net/lists/listinfo/valgrind-users >> > > |
|
From: John R. <jr...@bi...> - 2018-02-07 21:21:15
|
> Have you tried with --fair-sched=yes, as suggested in an earlier mail ?
> What were/are the results ?
When I tried it, then --fair-sched=yes gave even more lop-sided results than without.
I used 2 threads, with slice size of m_nStep = 16 rasters, and kept track of how many
slices were processed by each thread. Without --fair-sched=yes, then the division
was mostly 43 versus 50 or closer, with a few 93 versus 0. With --fair-sched=yes,
then the division was often 93 versus 0, with fewer 40 versus 53 or closer.
(Core i5-2500K CPU @ 3.30GHz; 4 cores, otherwise "idle")
I have never encountered the extremely-slow "hang" that the original post described.
This code below takes 31 seconds elapsed bare, and 36 seconds elapsed under valgrind.
The charged CPU time is 119 seconds bare, 35 seconds under valgrind.
Actual hardware contention is brutally slow.
===== build with: g++ -g -O sync-fetch-and-add.cpp -lpthread
#include <pthread.h>
int m_nCurrent;
void *
start_th(void *argstr) // top-level function for thread
{
unsigned t = 0;
for (unsigned j = 0; j < 1000*1000; ++j) {
t += __sync_fetch_and_add(&m_nCurrent, 0x1);
}
return (void *)(long)t;
}
pthread_t thread1, thread2, thread3, thread4;
int
main(int argc, char *argv[])
{
for (unsigned j=0; j < 400; ++j) {
m_nCurrent = 0; // start over each time
int rv1 = pthread_create(&thread1, NULL, start_th, 0);
int rv2 = pthread_create(&thread2, NULL, start_th, 0);
int rv3 = pthread_create(&thread3, NULL, start_th, 0);
int rv4 = pthread_create(&thread4, NULL, start_th, 0);
void *res1, *res2, *res3, *res4;
int rvE1 = pthread_join(thread1, &res1);
int rvE2 = pthread_join(thread2, &res2);
int rvE3 = pthread_join(thread3, &res3);
int rvE4 = pthread_join(thread4, &res4);
}
return 0;
}
=====
|
|
From: Adam S. <ada...@gm...> - 2018-02-07 21:16:20
|
I am using the latest version 3.13. I will pull down that patch and try it out. On Wed, Feb 7, 2018 at 3:03 PM, Philippe Waroquiers < phi...@sk...> wrote: > Which version are you using ? > Some improvements to clone handling was done in 3.13 : > * On Linux, clone handling has been improved to honour CLONE_VFORK that > involves a child stack. Note however that CLONE_VFORK | CLONE_VM is > handled > like CLONE_VFORK (by removing CLONE_VM), so applications that depend on > CLONE_VM exact semantics will (still) not work. > > Otherwise, I am sure we have still a bunch of clone related bugs > opened. E.g. https://bugs.kde.org/show_bug.cgi?id=183406 > and https://bugs.kde.org/show_bug.cgi?id=386427 which has > a patch, and might be what you have encountered. > > Philippe > > > On Wed, 2018-02-07 at 14:51 -0600, Adam Scott wrote: > > I'm hoping someone else has seen this issue and is able to help me. I > have search all over the internet for a solution and haven't been able to > find one. I am trying to run Valgrind on armv7 architecture, and after > compiling Valgrind and getting it onto the target I am able to run Valgrind > successfully on 'ls -l' but when I run Valgrind on my executable it starts > and then always fails after printing out this error: > > > > ==2333== Unsupported clone() flags: 0x800600 > > ==2333== > > ==2333== The only supported clone() uses are: > > ==2333== - via a threads library (LinuxThreads or NPTL) > > ==2333== - via the implementation of fork or vfork > > ==2333== > > ==2333== Valgrind detected that your program requires > > ==2333== the following unimplemented functionality: > > ==2333== Valgrind does not support general clone(). > > ==2333== This may be because the functionality is hard to implement, > > ==2333== or because no reasonable program would behave this way, > > ==2333== or because nobody has yet needed it. In any case, let us know > at > > ==2333== www.valgrind.org and/or try to work around the problem, if you > can. > > ==2333== > > ==2333== Valgrind has to exit now. Sorry. Bye! > > ==2333== > > > > sched status: > > running_tid=9 > > > > The thread that has the crash has the following stack: > > Thread 9: status = VgTs_Runnable (lwpid 2354) > > ==2333== at 0x6C5BCC: sys_clone (linux_syscall_support.h:2666) > > ==2333== by 0x6C5BCC: google_breakpad::ExceptionHandler:: > GenerateDump(google_breakpad::ExceptionHandler::CrashContext*) > (exception_handler.cc:527) > > ==2333== by 0x6C60C3: google_breakpad::ExceptionHandler::SignalHandler(int, > siginfo_t*, void*) (exception_handler.cc:368) > > ==2333== by 0x4CE5ACF: ??? (in /lib/libc-2.22.so) > > ------------------------------------------------------------ > ------------------ > > Check out the vibrant tech community on one of the world's most > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > _______________________________________________ > > Valgrind-users mailing list > > Val...@li... > > https://lists.sourceforge.net/lists/listinfo/valgrind-users > |
|
From: Philippe W. <phi...@sk...> - 2018-02-07 21:03:58
|
Which version are you using ? Some improvements to clone handling was done in 3.13 : * On Linux, clone handling has been improved to honour CLONE_VFORK that involves a child stack. Note however that CLONE_VFORK | CLONE_VM is handled like CLONE_VFORK (by removing CLONE_VM), so applications that depend on CLONE_VM exact semantics will (still) not work. Otherwise, I am sure we have still a bunch of clone related bugs opened. E.g. https://bugs.kde.org/show_bug.cgi?id=183406 and https://bugs.kde.org/show_bug.cgi?id=386427 which has a patch, and might be what you have encountered. Philippe On Wed, 2018-02-07 at 14:51 -0600, Adam Scott wrote: > I'm hoping someone else has seen this issue and is able to help me. I have search all over the internet for a solution and haven't been able to find one. I am trying to run Valgrind on armv7 architecture, and after compiling Valgrind and getting it onto the target I am able to run Valgrind successfully on 'ls -l' but when I run Valgrind on my executable it starts and then always fails after printing out this error: > > ==2333== Unsupported clone() flags: 0x800600 > ==2333== > ==2333== The only supported clone() uses are: > ==2333== - via a threads library (LinuxThreads or NPTL) > ==2333== - via the implementation of fork or vfork > ==2333== > ==2333== Valgrind detected that your program requires > ==2333== the following unimplemented functionality: > ==2333== Valgrind does not support general clone(). > ==2333== This may be because the functionality is hard to implement, > ==2333== or because no reasonable program would behave this way, > ==2333== or because nobody has yet needed it. In any case, let us know at > ==2333== www.valgrind.org and/or try to work around the problem, if you can. > ==2333== > ==2333== Valgrind has to exit now. Sorry. Bye! > ==2333== > > sched status: > running_tid=9 > > The thread that has the crash has the following stack: > Thread 9: status = VgTs_Runnable (lwpid 2354) > ==2333== at 0x6C5BCC: sys_clone (linux_syscall_support.h:2666) > ==2333== by 0x6C5BCC: google_breakpad::ExceptionHandler::GenerateDump(google_breakpad::ExceptionHandler::CrashContext*) (exception_handler.cc:527) > ==2333== by 0x6C60C3: google_breakpad::ExceptionHandler::SignalHandler(int, siginfo_t*, void*) (exception_handler.cc:368) > ==2333== by 0x4CE5ACF: ??? (in /lib/libc-2.22.so) > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: Adam S. <ada...@gm...> - 2018-02-07 20:51:46
|
I'm hoping someone else has seen this issue and is able to help me. I have search all over the internet for a solution and haven't been able to find one. I am trying to run Valgrind on armv7 architecture, and after compiling Valgrind and getting it onto the target I am able to run Valgrind successfully on 'ls -l' but when I run Valgrind on my executable it starts and then always fails after printing out this error: ==2333== Unsupported clone() flags: 0x800600 ==2333== ==2333== The only supported clone() uses are: ==2333== - via a threads library (LinuxThreads or NPTL) ==2333== - via the implementation of fork or vfork ==2333== ==2333== Valgrind detected that your program requires ==2333== the following unimplemented functionality: ==2333== Valgrind does not support general clone(). ==2333== This may be because the functionality is hard to implement, ==2333== or because no reasonable program would behave this way, ==2333== or because nobody has yet needed it. In any case, let us know at ==2333== www.valgrind.org and/or try to work around the problem, if you can. ==2333== ==2333== Valgrind has to exit now. Sorry. Bye! ==2333== sched status: running_tid=9 The thread that has the crash has the following stack: Thread 9: status = VgTs_Runnable (lwpid 2354) ==2333== at 0x6C5BCC: sys_clone (linux_syscall_support.h:2666) ==2333== by 0x6C5BCC: google_breakpad::ExceptionHandler::GenerateDump(google_breakpad::ExceptionHandler::CrashContext*) (exception_handler.cc:527) ==2333== by 0x6C60C3: google_breakpad::ExceptionHandler::SignalHandler(int, siginfo_t*, void*) (exception_handler.cc:368) ==2333== by 0x4CE5ACF: ??? (in /lib/libc-2.22.so) |
|
From: Philippe W. <phi...@sk...> - 2018-02-07 20:49:31
|
Have you tried with --fair-sched=yes, as suggested in an earlier mail ?
What were/are the results ?
Philippe
On Wed, 2018-02-07 at 07:52 +0000, Wuweijia wrote:
> Hi:
> There are some news about this question. The new code as below, I change from __sync_fetch_and_add to pthread_mutex_xxx
>
> pthread_mutex_lock(&g_mutex);
> int curr = m_nCurrent;
> m_nCurrent += m_nStep;
> pthread_mutex_unlock(&g_mutex);
>
> Now there is no testcases with valgrind running too long, and failed.
>
> But pthread_mutex_lock is not efficient as __sync_fetch_and_add, so the pthread_mutex_lock is just for now, for testing.
>
> And I think there is something related to schedule module of valgrind . why it last too long?
>
> BR
> Owen
>
>
> -----邮件原件-----
> 发件人: John Reiser [mailto:jr...@bi...]
> 发送时间: 2018年1月26日 12:44
> 收件人: val...@li...
> 主题: Re: [Valgrind-users] 答复: 答复: 答复: [Help] Valgrind sometime run the program very slowly sometimes , it last at least one hour. can you show me why or some way to analyze it?
>
> On 01/25/2018 15:37 UTC, Wuweijia wrote:
>
> > Function1:
> > bool CDynamicScheduling::GetProcLoop(
> > int& nBegin,
> > int& nEndPlusOne)
> > {
> > int curr = __sync_fetch_and_add(&m_nCurrent, m_nStep);
>
> How large is 'm_nStep'? [Are you sure?] The overhead expense of switching threads in valgrind would be reduced by making m_nStep as large as possible. It looks like the code in Function2 would produce the same values regardless.
>
>
> > if (curr > m_nEnd)
> > {
> > return false;
> > }
> >
> > nBegin = curr;
> > int limit = m_nEnd + 1;
>
> Local variable 'limit' is unused. By itself this is unimportant, but it might be a clue to something that is not shown here.
>
> > nEndPlusOne = curr + m_nStep;
> > return true;
> > }
> >
> >
> > Function2:
> > ....
> > int beginY, endY;
> > while (pDS->GetProcLoop(beginY, endY)){
> > for (y = beginY; y < endY; y++){
> > for(x = 0; x < dstWDiv2-7; x+=8){
> > vtmp0 = vld2q_u16(&pSrc[(y<<1)*srcStride+(x<<1)]);
> > vtmp1 = vld2q_u16(&pSrc[((y<<1)+1)*srcStride+(x<<1)]);
>
> I hope the actual source contains a comment such as:
> Compute pDst[] as the rounded average of non-overlapping 2x2 blocks of pixels in pSrc[].
>
> > vst1q_u16(&pDst[y*dstStride+x], (vtmp0.val[0] + vtmp0.val[1] + vtmp1.val[0] + vtmp1.val[1] + vdupq_n_u16(2)) >> vdupq_n_u16(2));
> > }
> > for(; x < dstWDiv2; x++){
> > pDst[y*dstStride+x] = (pSrc[(y<<1)*srcStride+(x<<1)] + pSrc[(y<<1)*srcStride+(x<<1)+1] + pSrc[((y<<1)+1)*srcStride+(x<<1)] + pSrc[((y<<1)+1)*srcStride+((x<<1)+1)] + 2) >> 2;
> > }
> > }
> > }
> >
> > return;
> > }
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
|
|
From: Wuweijia <wuw...@hu...> - 2018-02-07 07:52:53
|
Hi:
There are some news about this question. The new code as below, I change from __sync_fetch_and_add to pthread_mutex_xxx
pthread_mutex_lock(&g_mutex);
int curr = m_nCurrent;
m_nCurrent += m_nStep;
pthread_mutex_unlock(&g_mutex);
Now there is no testcases with valgrind running too long, and failed.
But pthread_mutex_lock is not efficient as __sync_fetch_and_add, so the pthread_mutex_lock is just for now, for testing.
And I think there is something related to schedule module of valgrind . why it last too long?
BR
Owen
-----邮件原件-----
发件人: John Reiser [mailto:jr...@bi...]
发送时间: 2018年1月26日 12:44
收件人: val...@li...
主题: Re: [Valgrind-users] 答复: 答复: 答复: [Help] Valgrind sometime run the program very slowly sometimes , it last at least one hour. can you show me why or some way to analyze it?
On 01/25/2018 15:37 UTC, Wuweijia wrote:
> Function1:
> bool CDynamicScheduling::GetProcLoop(
> int& nBegin,
> int& nEndPlusOne)
> {
> int curr = __sync_fetch_and_add(&m_nCurrent, m_nStep);
How large is 'm_nStep'? [Are you sure?] The overhead expense of switching threads in valgrind would be reduced by making m_nStep as large as possible. It looks like the code in Function2 would produce the same values regardless.
> if (curr > m_nEnd)
> {
> return false;
> }
>
> nBegin = curr;
> int limit = m_nEnd + 1;
Local variable 'limit' is unused. By itself this is unimportant, but it might be a clue to something that is not shown here.
> nEndPlusOne = curr + m_nStep;
> return true;
> }
>
>
> Function2:
> ....
> int beginY, endY;
> while (pDS->GetProcLoop(beginY, endY)){
> for (y = beginY; y < endY; y++){
> for(x = 0; x < dstWDiv2-7; x+=8){
> vtmp0 = vld2q_u16(&pSrc[(y<<1)*srcStride+(x<<1)]);
> vtmp1 = vld2q_u16(&pSrc[((y<<1)+1)*srcStride+(x<<1)]);
I hope the actual source contains a comment such as:
Compute pDst[] as the rounded average of non-overlapping 2x2 blocks of pixels in pSrc[].
> vst1q_u16(&pDst[y*dstStride+x], (vtmp0.val[0] + vtmp0.val[1] + vtmp1.val[0] + vtmp1.val[1] + vdupq_n_u16(2)) >> vdupq_n_u16(2));
> }
> for(; x < dstWDiv2; x++){
> pDst[y*dstStride+x] = (pSrc[(y<<1)*srcStride+(x<<1)] + pSrc[(y<<1)*srcStride+(x<<1)+1] + pSrc[((y<<1)+1)*srcStride+(x<<1)] + pSrc[((y<<1)+1)*srcStride+((x<<1)+1)] + 2) >> 2;
> }
> }
> }
>
> return;
> }
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________
Valgrind-users mailing list
Val...@li...
https://lists.sourceforge.net/lists/listinfo/valgrind-users
|
188 messages has been excluded from this view by a project administrator.
