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
(4) |
|
2
(5) |
3
(3) |
4
(3) |
5
(7) |
6
(7) |
7
(9) |
8
(10) |
|
9
(12) |
10
(26) |
11
(9) |
12
(6) |
13
(7) |
14
(15) |
15
(25) |
|
16
(20) |
17
(32) |
18
(11) |
19
(19) |
20
(22) |
21
(6) |
22
(8) |
|
23
(16) |
24
(25) |
25
(11) |
26
(16) |
27
(12) |
28
(15) |
29
(11) |
|
30
(5) |
31
(8) |
|
|
|
|
|
|
From: Jeremy F. <je...@go...> - 2005-01-27 23:58:48
|
One of the things I've noticed lately is that there are a number of
places in the code which say things like:
if (tid is in baseBlock) {
// get registers from baseBlock
} else {
// get registers from ThreadState
}
This could be simplified by saying:
if (tis is in baseblock)
save_registers_to_ThreadState()
// get registers from ThreadState
But it seems to me that the baseBlock is fairly redundant. We could
just make ThreadState.arch the home for all the VCPU state, and point
ebp at it while the thread runs. This would not only make getting at
the VCPU state much simpler and more consistent, it removes all the code
responsible for shuffling the state around, and all the code which sets
up the baseBlock in the first place.
I can see two objections to this:
But the baseBlock is configured differently for different Tools
True, but but apart from pointers to helper functions (see
below), this is just a has shadow regs/doesn't have shadow regs
switch. The ThreadState always contains shadow state either
way.
But the baseBlock has all the pointers to helpers.
Yes; as I understand it, they're there for two reasons:
1. they let us generate more compact code, because we can
generate short-form call instructions, and
2. the calls don't need relocating when the code is copied
into the translation cache
But it seems to me that these indirect calls are not good for
performance; the CPU would prefer to see a simple predictable
direct call. And if the offset is >128 it ends up generating a
longer sequence anyway.
And it will slightly complicate codegen, since x86 calls are
relative, so we can't fully generate the call until we know
where it will be placed in the translation cache - but this is
already handled to deal with BB-chaining, so extending that
mechanism to handle relocating other calls shouldn't be a big
problem.
The big question to me is what the new codegen is doing with this stuff,
and whether it has some other dependency on/requirement for the
baseBlock. Julian?
J
|
|
From: Eyal L. <ey...@ey...> - 2005-01-27 08:35:20
|
Jeremy Fitzhardinge wrote: > On Thu, 2005-01-27 at 17:23 +1100, Eyal Lebedinsky wrote: > >>Jeremy Fitzhardinge wrote: >> >>>Could you try again with --trace-signals=yes. >> >>Done. '3' is a good run, '4' is a failed run. > > > OK, this explains what's going on. It is the same problem as before - > it's getting a SIGSEGV to grow the stack, but it's missing siginfo so it > doesn't realize its a stack growth. Then it tries to report the > sigsegv, but dies while trying to print the backtrace. > > So the question is, why are there lots of signals still being queued? Can you ask VG to tell how many is "lots" in this case? > The code currently takes care to mop them up where ever the signals are > being sampled, but I guess that won't happen if the master is blocked in > a syscall... Hm. > > Can you go into a bit of detail about the process/thread structure here? > Those two traces are from a single-threaded program, but for this bug to > occur (and be Valgrind's fault), there needs to be lots of thread > exiting going on. Is there a process where: > 1. the main thread is blocked in a syscall, while > 2. other thread(s) are creating lots of other short-lived threads? I don't think so. I can describe the scenario for the program in question. We have a few servers running, and they stay up for the full test period. A sequence of tests is running. Each test runs a few programs (maybe a dozen) in order. Each connection to a server gets a thread which normally serves it from start to finish. When no client is active there should only be some housekeeping threads on the servers. Between tests we run this 'ssashut' program, which is a very simple one. It only issues one transaction, telling a server to release cached resources. Naturally, it gets a thread on the server. All of our programs run as a thread, meaning main() is practically empty, it just launches a thread and then joins it. This way we do not need to control mains, just threads. I short, I do not expect too many threads to be active (or exiting) when ssashut is run. Is there a way to request VG to log a global status report on demand? I can then run this status report before each ssashut. I wonder is some resource is not released by VG itself. Note that some VG processes (my servers) start early and never exit before the failure, does VG delay some housekeeping to when a process exits? Just a thought. -- Eyal Lebedinsky (ey...@ey...) <http://samba.org/eyal/> attach .zip as .dat |
|
From: Jeremy F. <je...@go...> - 2005-01-27 07:16:51
|
On Thu, 2005-01-27 at 17:23 +1100, Eyal Lebedinsky wrote:
> Jeremy Fitzhardinge wrote:
> > Could you try again with --trace-signals=yes.
>
> Done. '3' is a good run, '4' is a failed run.
OK, this explains what's going on. It is the same problem as before -
it's getting a SIGSEGV to grow the stack, but it's missing siginfo so it
doesn't realize its a stack growth. Then it tries to report the
sigsegv, but dies while trying to print the backtrace.
So the question is, why are there lots of signals still being queued?
The code currently takes care to mop them up where ever the signals are
being sampled, but I guess that won't happen if the master is blocked in
a syscall... Hm.
Can you go into a bit of detail about the process/thread structure here?
Those two traces are from a single-threaded program, but for this bug to
occur (and be Valgrind's fault), there needs to be lots of thread
exiting going on. Is there a process where:
1. the main thread is blocked in a syscall, while
2. other thread(s) are creating lots of other short-lived threads?
J
|
|
From: Eyal L. <ey...@ey...> - 2005-01-27 06:23:36
|
Jeremy Fitzhardinge wrote: > Could you try again with --trace-signals=yes. Done. '3' is a good run, '4' is a failed run. Mmm, I still do not see my posting with logs 1/2 on the list. Hope it gets there is due time. -- Eyal Lebedinsky (ey...@ey...) <http://samba.org/eyal/> attach .zip as .dat |
|
From: Eyal L. <ey...@ey...> - 2005-01-27 05:32:27
|
An earlier reply of mine is not showing on the list, and it also was
missing the attachements so this is not a big loss... Here it is with
more details.
Jeremy Fitzhardinge wrote:
> On Wed, 2005-01-26 at 19:14 +1100, Eyal Lebedinsky wrote:
>
>> I do not have an easy way to reproduce, however I can provide better logs.
>> The attached one shows a successfully run of the currently failing program
>> followed by one that aborted quietly.
>>
>> The failure in the ipc area may explain why my program always dies while
>> holding a semaphore, which I must remove manually before my system is
>> usable again.
>
> Is your program multithreaded?
Sure is. But the one dying ('2') never managed to progress to the point of
starting a thread. Look at log '1' to compare to a good run.
> Your trace makes it appear that it dies
> in the sys_ipc syscall doing a semget, but Valgrind does literally
> nothing in this case - there's nothing for it to check, so it does
> nothing. Could you try again with --trace-signals=yes.
I now have more logs. '1' is a log of a good run, '2' is a similar run that
failed. The logs include both VG traces any my own. You will see none of my
traces in the failed one because it failed as it was establishing the
framework for our trace system when we access our shared memory object.
I will try and get a more detailed log.
[later] I confirmed that the log '2' has none of my traces because it never
got that far. Log '1' shows library calls issued by my program, like
iodll[18641/---]> share.c(2266): CALL getpid
SYSCALL[18641,1]( 4) --> 45 (0x2D)
SYSCALL[18641,1]( 20):sys_getpid () --> 18641 (0x48D1)
SYSCALL[18641,1]( 20):sys_getpid () --> 18641 (0x48D1)
SYSCALL[18641,1]( 4) mayBlock:sys_write ( 2, 0x52BFB4F0, 45 ) --> ...
iodll[18641/---]> share.c(2266): CALL RETURN
as well as our own internal calls, like
iodll[0/0]> main.c(892) ssamain_trace_init: ENTER
You will notice that log '2' never got even this far, never logging
any of our tracing.
I am now running with '--trace-signals=yes'.
> And could you please, please, please file a bug and attach these logs to
> it.
Done
Bug 97975 has been added to the database
> J
--
Eyal Lebedinsky (ey...@ey...) <http://samba.org/eyal/>
attach .zip as .dat
|
|
From: <js...@ac...> - 2005-01-27 03:56:38
|
Nightly build on phoenix ( SuSE 9.1 ) started at 2005-01-27 03:50:00 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow -- Finished tests in none/tests ---------------------------------------- == 194 tests, 15 stderr failures, 0 stdout failures ================= corecheck/tests/as_mmap (stderr) corecheck/tests/fdleak_fcntl (stderr) helgrind/tests/allok (stderr) helgrind/tests/deadlock (stderr) helgrind/tests/inherit (stderr) helgrind/tests/race (stderr) helgrind/tests/race2 (stderr) helgrind/tests/readshared (stderr) massif/tests/toobig-allocs (stderr) massif/tests/true_html (stderr) massif/tests/true_text (stderr) memcheck/tests/pth_once (stderr) memcheck/tests/scalar (stderr) memcheck/tests/threadederrno (stderr) memcheck/tests/writev (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <to...@co...> - 2005-01-27 03:23:55
|
Nightly build on dunsmere ( Fedora Core 3 ) started at 2005-01-27 03:20:04 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow seg_override: valgrind --num-callers=4 ./seg_override -- Finished tests in none/tests/x86 ------------------------------------ yield: valgrind --num-callers=4 ./yield -- Finished tests in none/tests ---------------------------------------- == 201 tests, 12 stderr failures, 0 stdout failures ================= helgrind/tests/allok (stderr) helgrind/tests/deadlock (stderr) helgrind/tests/inherit (stderr) helgrind/tests/race (stderr) helgrind/tests/race2 (stderr) helgrind/tests/readshared (stderr) massif/tests/toobig-allocs (stderr) massif/tests/true_html (stderr) massif/tests/true_text (stderr) memcheck/tests/scalar (stderr) memcheck/tests/scalar_supp (stderr) memcheck/tests/vgtest_ume (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2005-01-27 03:21:23
|
Nightly build on audi ( Red Hat 9 ) started at 2005-01-27 03:15:03 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow helgrind/tests/allok (stderr) helgrind/tests/deadlock (stderr) helgrind/tests/inherit (stderr) helgrind/tests/race (stderr) helgrind/tests/race2 (stderr) helgrind/tests/readshared (stderr) massif/tests/toobig-allocs (stderr) massif/tests/true_html (stderr) massif/tests/true_text (stderr) memcheck/tests/badpoll (stderr) memcheck/tests/buflen_check (stderr) memcheck/tests/execve (stderr) memcheck/tests/execve2 (stderr) memcheck/tests/scalar (stderr) memcheck/tests/scalar_exit_group (stderr) memcheck/tests/scalar_supp (stderr) memcheck/tests/writev (stderr) none/tests/tls (stdout) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2005-01-27 03:15:08
|
Nightly build on ginetta ( Red Hat 8.0 ) started at 2005-01-27 03:10:03 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow seg_override: valgrind --num-callers=4 ./seg_override -- Finished tests in none/tests/x86 ------------------------------------ yield: valgrind --num-callers=4 ./yield -- Finished tests in none/tests ---------------------------------------- == 199 tests, 12 stderr failures, 0 stdout failures ================= helgrind/tests/allok (stderr) helgrind/tests/deadlock (stderr) helgrind/tests/inherit (stderr) helgrind/tests/race (stderr) helgrind/tests/race2 (stderr) helgrind/tests/readshared (stderr) massif/tests/toobig-allocs (stderr) massif/tests/true_html (stderr) massif/tests/true_text (stderr) memcheck/tests/pth_once (stderr) memcheck/tests/scalar (stderr) memcheck/tests/threadederrno (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2005-01-27 03:08:54
|
Nightly build on alvis ( Red Hat 7.3 ) started at 2005-01-27 03:05:04 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow yield: valgrind --num-callers=4 ./yield -- Finished tests in none/tests ---------------------------------------- == 199 tests, 14 stderr failures, 0 stdout failures ================= helgrind/tests/allok (stderr) helgrind/tests/deadlock (stderr) helgrind/tests/inherit (stderr) helgrind/tests/race (stderr) helgrind/tests/race2 (stderr) helgrind/tests/readshared (stderr) massif/tests/toobig-allocs (stderr) massif/tests/true_html (stderr) massif/tests/true_text (stderr) memcheck/tests/post-syscall (stderr) memcheck/tests/pth_once (stderr) memcheck/tests/scalar (stderr) memcheck/tests/threadederrno (stderr) memcheck/tests/vgtest_ume (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2005-01-27 03:05:30
|
Nightly build on standard ( Red Hat 7.2 ) started at 2005-01-27 03:00:05 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow -- Finished tests in none/tests/x86 ------------------------------------ yield: valgrind --num-callers=4 ./yield -- Finished tests in none/tests ---------------------------------------- == 199 tests, 13 stderr failures, 0 stdout failures ================= helgrind/tests/allok (stderr) helgrind/tests/deadlock (stderr) helgrind/tests/inherit (stderr) helgrind/tests/race (stderr) helgrind/tests/race2 (stderr) helgrind/tests/readshared (stderr) massif/tests/toobig-allocs (stderr) massif/tests/true_html (stderr) massif/tests/true_text (stderr) memcheck/tests/pth_once (stderr) memcheck/tests/scalar (stderr) memcheck/tests/threadederrno (stderr) memcheck/tests/vgtest_ume (stderr) make: *** [regtest] Error 1 |
|
From: Eyal L. <ey...@ey...> - 2005-01-27 01:02:29
|
Jeremy Fitzhardinge wrote: > On Wed, 2005-01-26 at 19:14 +1100, Eyal Lebedinsky wrote: > >>I do not have an easy way to reproduce, however I can provide better logs. >>The attached one shows a successfull run of the currently failing program >>followed by one that aborted quietly. >> >>The failure in the ipc area may explain why my program always dies while >>holding a semaphore, which I must remove manually before my system is >>usable again. > > Is your program multithreaded? Your trace makes it appear that it dies > in the sys_ipc syscall doing a semget, but Valgrind does literally > nothing in this case - there's nothing for it to check, so it does > nothing. Could you try again with --trace-signals=yes. I now have more logs. ssashut.1 is a log of a good run, ssashut.2 is a similar run that failed. The logs include both VG traces any my own. You will see non of my traces in the failed one because it failed as it was establishing the framework for our trace system when we access our shared memory object. I will try and get a more detailed log. > And could you please, please, please file a bug and attach these logs to > it. Will do soon. Promise. > J -- Eyal Lebedinsky (ey...@ey...) <http://samba.org/eyal/> attach .zip as .dat |