You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(122) |
Nov
(152) |
Dec
(69) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(6) |
Feb
(25) |
Mar
(73) |
Apr
(82) |
May
(24) |
Jun
(25) |
Jul
(10) |
Aug
(11) |
Sep
(10) |
Oct
(54) |
Nov
(203) |
Dec
(182) |
| 2004 |
Jan
(307) |
Feb
(305) |
Mar
(430) |
Apr
(312) |
May
(187) |
Jun
(342) |
Jul
(487) |
Aug
(637) |
Sep
(336) |
Oct
(373) |
Nov
(441) |
Dec
(210) |
| 2005 |
Jan
(385) |
Feb
(480) |
Mar
(636) |
Apr
(544) |
May
(679) |
Jun
(625) |
Jul
(810) |
Aug
(838) |
Sep
(634) |
Oct
(521) |
Nov
(965) |
Dec
(543) |
| 2006 |
Jan
(494) |
Feb
(431) |
Mar
(546) |
Apr
(411) |
May
(406) |
Jun
(322) |
Jul
(256) |
Aug
(401) |
Sep
(345) |
Oct
(542) |
Nov
(308) |
Dec
(481) |
| 2007 |
Jan
(427) |
Feb
(326) |
Mar
(367) |
Apr
(255) |
May
(244) |
Jun
(204) |
Jul
(223) |
Aug
(231) |
Sep
(354) |
Oct
(374) |
Nov
(497) |
Dec
(362) |
| 2008 |
Jan
(322) |
Feb
(482) |
Mar
(658) |
Apr
(422) |
May
(476) |
Jun
(396) |
Jul
(455) |
Aug
(267) |
Sep
(280) |
Oct
(253) |
Nov
(232) |
Dec
(304) |
| 2009 |
Jan
(486) |
Feb
(470) |
Mar
(458) |
Apr
(423) |
May
(696) |
Jun
(461) |
Jul
(551) |
Aug
(575) |
Sep
(134) |
Oct
(110) |
Nov
(157) |
Dec
(102) |
| 2010 |
Jan
(226) |
Feb
(86) |
Mar
(147) |
Apr
(117) |
May
(107) |
Jun
(203) |
Jul
(193) |
Aug
(238) |
Sep
(300) |
Oct
(246) |
Nov
(23) |
Dec
(75) |
| 2011 |
Jan
(133) |
Feb
(195) |
Mar
(315) |
Apr
(200) |
May
(267) |
Jun
(293) |
Jul
(353) |
Aug
(237) |
Sep
(278) |
Oct
(611) |
Nov
(274) |
Dec
(260) |
| 2012 |
Jan
(303) |
Feb
(391) |
Mar
(417) |
Apr
(441) |
May
(488) |
Jun
(655) |
Jul
(590) |
Aug
(610) |
Sep
(526) |
Oct
(478) |
Nov
(359) |
Dec
(372) |
| 2013 |
Jan
(467) |
Feb
(226) |
Mar
(391) |
Apr
(281) |
May
(299) |
Jun
(252) |
Jul
(311) |
Aug
(352) |
Sep
(481) |
Oct
(571) |
Nov
(222) |
Dec
(231) |
| 2014 |
Jan
(185) |
Feb
(329) |
Mar
(245) |
Apr
(238) |
May
(281) |
Jun
(399) |
Jul
(382) |
Aug
(500) |
Sep
(579) |
Oct
(435) |
Nov
(487) |
Dec
(256) |
| 2015 |
Jan
(338) |
Feb
(357) |
Mar
(330) |
Apr
(294) |
May
(191) |
Jun
(108) |
Jul
(142) |
Aug
(261) |
Sep
(190) |
Oct
(54) |
Nov
(83) |
Dec
(22) |
| 2016 |
Jan
(49) |
Feb
(89) |
Mar
(33) |
Apr
(50) |
May
(27) |
Jun
(34) |
Jul
(53) |
Aug
(53) |
Sep
(98) |
Oct
(206) |
Nov
(93) |
Dec
(53) |
| 2017 |
Jan
(65) |
Feb
(82) |
Mar
(102) |
Apr
(86) |
May
(187) |
Jun
(67) |
Jul
(23) |
Aug
(93) |
Sep
(65) |
Oct
(45) |
Nov
(35) |
Dec
(17) |
| 2018 |
Jan
(26) |
Feb
(35) |
Mar
(38) |
Apr
(32) |
May
(8) |
Jun
(43) |
Jul
(27) |
Aug
(30) |
Sep
(43) |
Oct
(42) |
Nov
(38) |
Dec
(67) |
| 2019 |
Jan
(32) |
Feb
(37) |
Mar
(53) |
Apr
(64) |
May
(49) |
Jun
(18) |
Jul
(14) |
Aug
(53) |
Sep
(25) |
Oct
(30) |
Nov
(49) |
Dec
(31) |
| 2020 |
Jan
(87) |
Feb
(45) |
Mar
(37) |
Apr
(51) |
May
(99) |
Jun
(36) |
Jul
(11) |
Aug
(14) |
Sep
(20) |
Oct
(24) |
Nov
(40) |
Dec
(23) |
| 2021 |
Jan
(14) |
Feb
(53) |
Mar
(85) |
Apr
(15) |
May
(19) |
Jun
(3) |
Jul
(14) |
Aug
(1) |
Sep
(57) |
Oct
(73) |
Nov
(56) |
Dec
(22) |
| 2022 |
Jan
(3) |
Feb
(22) |
Mar
(6) |
Apr
(55) |
May
(46) |
Jun
(39) |
Jul
(15) |
Aug
(9) |
Sep
(11) |
Oct
(34) |
Nov
(20) |
Dec
(36) |
| 2023 |
Jan
(79) |
Feb
(41) |
Mar
(99) |
Apr
(169) |
May
(48) |
Jun
(16) |
Jul
(16) |
Aug
(57) |
Sep
(19) |
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
1
(1) |
2
(2) |
3
(2) |
4
|
5
|
6
|
7
|
|
8
|
9
(5) |
10
(3) |
11
|
12
(3) |
13
(1) |
14
|
|
15
|
16
(3) |
17
|
18
(1) |
19
(1) |
20
|
21
|
|
22
|
23
|
24
|
25
|
26
|
27
(2) |
28
(1) |
|
29
|
30
|
|
|
|
|
|
|
From: Philippe W. <phi...@sk...> - 2019-09-09 22:19:21
|
On Mon, 2019-09-09 at 18:56 +0100, João M. S. Silva wrote: > With this smaller program I still reproduce a similar behaviour: > > (gdb) r > Starting program: pw_fwp_engine.eab > [Thread debugging using libthread_db enabled] Also, I start to be somewhat lost. The above starts a program under gdb, not under valgrind. I thought we were looking at a program working outside of valgrind, and failing under valgrind. But this seems to fail outside of valgrind ? Philippe |
|
From: Philippe W. <phi...@sk...> - 2019-09-09 22:03:36
|
On Mon, 2019-09-09 at 18:56 +0100, João M. S. Silva wrote: > With this smaller program I still reproduce a similar behaviour: > > (gdb) r > Starting program: pw_fwp_engine.eab > [Thread debugging using libthread_db enabled] > Using host libthread_db library "/lib64/libthread_db.so.1". > [New Thread 0x7ffff5356700 (LWP 8448)] > [New Thread 0x7ffff5151700 (LWP 8449)] > [New Thread 0x7ffff4f4c700 (LWP 8450)] > [New Thread 0x7ffff4d47700 (LWP 8451)] > 2 | high_level_task_2 | 2097152 | 153620 > 1 | high_level_task_1 | 2097152 | 153620 > [Thread 0x7ffff5151700 (LWP 8449) exited] > 3 | high_level_task_3 | 2097152 | 153620 > [Thread 0x7ffff5356700 (LWP 8448) exited] > [Thread 0x7ffff4f4c700 (LWP 8450) exited] > [New Thread 0x7fffe7fff700 (LWP 8452)] > 4 | high_level_task_4 | 2097152 | 153620 > [Thread 0x7ffff4d47700 (LWP 8451) exited] > [New Thread 0x7ffff4d47700 (LWP 8453)] > > Thread 7 "udp_input_threa" received signal SIGSEGV, Segmentation fault. > [Switching to Thread 0x7ffff4d47700 (LWP 8453)] > 0x0000000000562532 in wds_processing.udp_input.udp_input_tt ( > <_task>=<error reading variable: Cannot access memory at address > 0x7ffff4712e48>) > at wds_processing-udp_input.adb:61 > 61 task body UDP_Input_TT > (gdb) $sp > $1 = (access void) 0x7ffff4b43a90 At this point, you might use the monitor command v.info scheduler to see the list of threads and their stack, and compare $sp to the stack limits. > > > If the wild guess is eliminated, then you have to dig further on the > > code that causes the SEGV: what address is accessed ? > > In which (or around which) segment is that pointing ? > > what is this (asm) code doing ? (you have to look at assembly, > > because as you say, on the source code level, everything is probably > > correct, as explained by your next paragraph). > > I really cannot understand the assembly, but here it is: > > (gdb) disassemble > Dump of assembler code for function wds_processing__udp_input__udp_input_ttTB: > 0x0000000000562514 <+0>: push %rbp > 0x0000000000562515 <+1>: mov %rsp,%rbp > 0x0000000000562518 <+4>: push %r12 > 0x000000000056251a <+6>: push %rbx > 0x000000000056251b <+7>: lea -0x1020(%rsp),%rsp > 0x0000000000562523 <+15>: lea -0x62f000(%rsp),%r11 > 0x000000000056252b <+23>: sub $0x1000,%rsp > => 0x0000000000562532 <+30>: orq $0x0,(%rsp) That sounds to be early in the function, just after a stack growth. monitor v.info scheduler can give some lights. You might try to increase the stack size of the tasks, just in case you know have a task stack exhausted instead of the main stack. > > > > If further digging on your side does not ring a bell, > > on valgrind developer side, there is not much we can do without > > a (small compilable) reproducer. > > So, then the next step is to produce a small testcase. > > I'm trying but after some hours I seem to be stuck without being able > to reduce it further. At this point, even removing unused variables > now makes Valgrind change from the storage error (apparently related > to Ada elaboration) to the older error: > > valgrind: mmap(0x78d000, 3800866816) failed in UME with error 22 > (Invalid argument). > valgrind: this can be caused by executables with very large text, data > or bss segments. Wasn't this solved by the Wl... linker argument ? Have you given the Wl argument to continue isolate ? Sorry to not be able to help more, but remote debugging by mail is not really possible. Philippe |
|
From: João M. S. S. <joa...@gm...> - 2019-09-09 17:56:47
|
Hello,
> Valgrind does not have a concept of unlimited stack size.
> See manual or --help about option --main-stacksize.
> You might also read about --max-stackframe
I tried using --main-stacksize and --max-stackframe but they seem to
produce no impact. I used up to an 8 GB stack and stack frame.
> To eliminate the wild guess, you really need to capture some
> data *when running under valgrind* to show/prove that the address access
> that causes the SIGSEGV is not due to a stack too small.
> You can do this when debugging under Valgrind + vgdb + gdb
> (e.g. examine the value of the SP, examine where is the failing address, ...).
> Using 'monitor v.info scheduler' at the time of SIGSEGV is also useful,
> as it will show the client stack size and the value of the SP.
I spent some hours cutting the program down to just 2 modules. The
main program is now "null" and just with's the 2 modules.
One of the modules is one thread, and the other is 4 threads.
With this smaller program I still reproduce a similar behaviour:
(gdb) r
Starting program: pw_fwp_engine.eab
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
[New Thread 0x7ffff5356700 (LWP 8448)]
[New Thread 0x7ffff5151700 (LWP 8449)]
[New Thread 0x7ffff4f4c700 (LWP 8450)]
[New Thread 0x7ffff4d47700 (LWP 8451)]
2 | high_level_task_2 | 2097152 | 153620
1 | high_level_task_1 | 2097152 | 153620
[Thread 0x7ffff5151700 (LWP 8449) exited]
3 | high_level_task_3 | 2097152 | 153620
[Thread 0x7ffff5356700 (LWP 8448) exited]
[Thread 0x7ffff4f4c700 (LWP 8450) exited]
[New Thread 0x7fffe7fff700 (LWP 8452)]
4 | high_level_task_4 | 2097152 | 153620
[Thread 0x7ffff4d47700 (LWP 8451) exited]
[New Thread 0x7ffff4d47700 (LWP 8453)]
Thread 7 "udp_input_threa" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffff4d47700 (LWP 8453)]
0x0000000000562532 in wds_processing.udp_input.udp_input_tt (
<_task>=<error reading variable: Cannot access memory at address
0x7ffff4712e48>)
at wds_processing-udp_input.adb:61
61 task body UDP_Input_TT
(gdb) $sp
$1 = (access void) 0x7ffff4b43a90
> If the wild guess is eliminated, then you have to dig further on the
> code that causes the SEGV: what address is accessed ?
> In which (or around which) segment is that pointing ?
> what is this (asm) code doing ? (you have to look at assembly,
> because as you say, on the source code level, everything is probably
> correct, as explained by your next paragraph).
I really cannot understand the assembly, but here it is:
(gdb) disassemble
Dump of assembler code for function wds_processing__udp_input__udp_input_ttTB:
0x0000000000562514 <+0>: push %rbp
0x0000000000562515 <+1>: mov %rsp,%rbp
0x0000000000562518 <+4>: push %r12
0x000000000056251a <+6>: push %rbx
0x000000000056251b <+7>: lea -0x1020(%rsp),%rsp
0x0000000000562523 <+15>: lea -0x62f000(%rsp),%r11
0x000000000056252b <+23>: sub $0x1000,%rsp
=> 0x0000000000562532 <+30>: orq $0x0,(%rsp)
> If further digging on your side does not ring a bell,
> on valgrind developer side, there is not much we can do without
> a (small compilable) reproducer.
> So, then the next step is to produce a small testcase.
I'm trying but after some hours I seem to be stuck without being able
to reduce it further. At this point, even removing unused variables
now makes Valgrind change from the storage error (apparently related
to Ada elaboration) to the older error:
valgrind: mmap(0x78d000, 3800866816) failed in UME with error 22
(Invalid argument).
valgrind: this can be caused by executables with very large text, data
or bss segments.
which is not of interest since it does not replicate the storage issue.
João M. S. Silva
|
|
From: Mike C. <ma...@mc...> - 2019-09-09 13:31:27
|
In glibc 5aad5f617892e75d91d4c8fb7594ff35b610c042 (first released in v2.28) a call to strncmp was added to dl-load.c:is_dst. This causes valgrind to complain about glibc's highly-optimised strncmp performing sixteen-byte reads on short strings in ld.so. Let's intercept strncmp in ld.so too so we use valgrind's simple version to avoid this problem. --- shared/vg_replace_strmem.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/shared/vg_replace_strmem.c b/shared/vg_replace_strmem.c index 87a4bcc55..5c05644fe 100644 --- a/shared/vg_replace_strmem.c +++ b/shared/vg_replace_strmem.c @@ -648,6 +648,8 @@ static inline void my_exit ( int x ) STRNCMP(VG_Z_LIBC_SONAME, __GI_strncmp) STRNCMP(VG_Z_LIBC_SONAME, __strncmp_sse2) STRNCMP(VG_Z_LIBC_SONAME, __strncmp_sse42) + STRNCMP(VG_Z_LD_LINUX_SO_2, strncmp) + STRNCMP(VG_Z_LD_LINUX_X86_64_SO_2, strncmp) #elif defined(VGO_darwin) STRNCMP(VG_Z_LIBC_SONAME, strncmp) -- 2.20.1 |
|
From: Catalin V. <cat...@ke...> - 2019-09-09 12:44:18
|
Hi, I've tried the latest branch, but it does not fix my issue. On 8/13/19 5:59 PM, Petar Jovanovic wrote: > [EXTERNAL] > > Can you check the latest development tree and see if you are seeing > the issue with it? > There have been some changes related to syscall routines, so there is > a (small) chance it could help your issue. > Give it a try. > > Petar |