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
(11) |
2
(14) |
3
(11) |
|
4
(7) |
5
(14) |
6
(15) |
7
(31) |
8
(12) |
9
(9) |
10
(9) |
|
11
(9) |
12
(10) |
13
(10) |
14
(9) |
15
(10) |
16
(11) |
17
(10) |
|
18
(10) |
19
(10) |
20
(11) |
21
(13) |
22
(16) |
23
(9) |
24
(7) |
|
25
(9) |
26
(7) |
27
(9) |
28
(5) |
29
(5) |
30
(9) |
|
|
From: <js...@ac...> - 2006-06-26 10:46:45
|
Nightly build on minnie ( SuSE 10.0, ppc32 ) started at 2006-06-26 09:00:01 BST Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 206 tests, 11 stderr failures, 5 stdout failures, 0 posttest failures == memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/leakotron (stdout) memcheck/tests/mempool (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/sigaltstack (stderr) memcheck/tests/xml1 (stderr) none/tests/faultstatus (stderr) none/tests/mremap (stderr) none/tests/ppc32/jm-fp (stdout) none/tests/ppc32/jm-fp (stderr) none/tests/ppc32/round (stdout) none/tests/ppc32/round (stderr) none/tests/ppc32/test_fx (stdout) none/tests/ppc32/test_fx (stderr) none/tests/ppc32/test_gx (stdout) |
|
From: Tom H. <to...@co...> - 2006-06-26 08:08:10
|
In message <Pine.LNX.4.64.0606261237140.15353@parore>
John Carter <joh...@ta...> wrote:
> On Mon, 26 Jun 2006, Tom Hughes wrote:
>
>> There is no munmap or similar to trigger the change, so there are only
>> a limited number of other things that could cause and I suspect the most
>> likely is a stack switch but I need to look at that in more detail.
>
> Hmm. Quite likely.
>
> Ecos is a full multi-threaded RTOS that runs without an MMU, so it is
> running here as a ordinary userland linux process. A somewhat weird process,
> but ordinary and without exotic assist from the kernel.
So you're running multiple threads in a single kernel thread and doing
your own context switches.
> 5) Including the scheduler which invokes hal_thread_load_context
Which looks like it is where the problem occurs judging by the rest of
the data... What I don't understand is why VG_(unknown_SP_update) is
allowing such a large change in SP without the stack switch code
triggering - anything more than 2Mb should trigger it.
I've attached a patch to make that routine report what is going on - it
might produce quite a lot of output though.
A solution is probably to use VALGRIND_STACK_REGISTER to register your
thread stacks so that valgrind can detect the changes cleanly, but I'd
like to know why the automatic code isn't triggering properly.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Tom H. <th...@cy...> - 2006-06-26 02:46:35
|
Nightly build on alvis ( i686, Red Hat 7.3 ) started at 2006-06-26 03:15:23 BST Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 236 tests, 19 stderr failures, 0 stdout failures, 0 posttest failures == memcheck/tests/addressable (stderr) memcheck/tests/badjump (stderr) memcheck/tests/describe-block (stderr) memcheck/tests/erringfds (stderr) memcheck/tests/leak-0 (stderr) memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-regroot (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/match-overrun (stderr) memcheck/tests/mempool (stderr) memcheck/tests/partial_load_dflt (stderr) memcheck/tests/partial_load_ok (stderr) memcheck/tests/partiallydefinedeq (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/sigkill (stderr) memcheck/tests/stack_changes (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) memcheck/tests/xml1 (stderr) |
|
From: Tom H. <to...@co...> - 2006-06-26 02:45:57
|
Nightly build on dunsmere ( athlon, Fedora Core 5 ) started at 2006-06-26 03:30:04 BST Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 237 tests, 5 stderr failures, 0 stdout failures, 0 posttest failures == memcheck/tests/mempool (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/stack_switch (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/xml1 (stderr) |
|
From: Tom H. <th...@cy...> - 2006-06-26 02:39:24
|
Nightly build on dellow ( x86_64, Fedora Core 5 ) started at 2006-06-26 03:10:18 BST Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 260 tests, 2 stderr failures, 0 stdout failures, 0 posttest failures == memcheck/tests/x86/scalar (stderr) memcheck/tests/xml1 (stderr) |
|
From: Tom H. <th...@cy...> - 2006-06-26 02:31:18
|
Nightly build on gill ( x86_64, Fedora Core 2 ) started at 2006-06-26 03:00:18 BST Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 260 tests, 4 stderr failures, 0 stdout failures, 0 posttest failures == memcheck/tests/stack_switch (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) none/tests/fdleak_fcntl (stderr) |
|
From: John C. <joh...@ta...> - 2006-06-26 01:03:59
|
On Mon, 26 Jun 2006, Tom Hughes wrote:
>> ==7822== Warning: set address range perms: large range 0xBEE35714-0x8A86463 (noaccess)
>
> Well that's very odd because it wraps around the end of the address
> space which is going to give some very odd effects.
Ah, you're right. I was reading that merely as an expression of "the
stack grows downwards".
> The start address is in the stack, and the end address has wrapped
> around and is in the data segment of your executable, and is greater
> than the first address complained about so does explain the complaint.
Yup. It would.
> There is no munmap or similar to trigger the change, so there are only
> a limited number of other things that could cause and I suspect the most
> likely is a stack switch but I need to look at that in more detail.
Hmm. Quite likely.
Ecos is a full multi-threaded RTOS that runs without an MMU, so it is
running here as a ordinary userland linux process. A somewhat weird process,
but ordinary and without exotic assist from the kernel.
Looking at the startup code and running it with --db-attached=yes I can
tell you...
1) Ecos starts,
2) allocates heap via that big brk that I was whinging about
earlier.
3) Initializes the hardware (all those sig* calls and forking a process to
act as a I/O intermediatory to the real world.)
4) Runs a bunch of constructors...
5) Including the scheduler which invokes hal_thread_load_context
6) Somewhere at about this point valgrind emits that warning. Is there
any way to force a db-attach at exactly that point?
==15456== Warning: set address range perms: large range 0xBEF5E714-0x8A86463 (noaccess)
--15456:1:mallocfr newSuperblock at 0x63D55000 (pszB 262128) owner VALGRIND/exectxt
--15456:1:mallocfr newSuperblock at 0x63D95000 (pszB 65520) owner VALGRIND/errors
==15456== Invalid read of size 4
==15456== at 0x800EA31: ???
==15456== Address 0x8A86460 is just below the stack ptr. To suppress, use: --workaround-gcc296-bugs=yes
==15456==
==15456== ---- Attach to debugger ? --- [Return/N/n/Y/y/C/c] ---- 7) And emits...
7) If I attach to the debugger I find I'm in hal_thread_load_context just about where
it shoves a value into %esp.
Dump of assembler code for function hal_thread_load_context:
0x0800ea1c <hal_thread_load_context+0>: mov 0x4(%esp),%eax
0x0800ea20 <hal_thread_load_context+4>: mov (%eax),%eax
0x0800ea22 <hal_thread_load_context+6>: mov 0x8(%eax),%ebp
0x0800ea25 <hal_thread_load_context+9>: mov 0xc(%eax),%ebx
0x0800ea28 <hal_thread_load_context+12>: mov 0x10(%eax),%esi
0x0800ea2b <hal_thread_load_context+15>: mov 0x14(%eax),%edi
0x0800ea2e <hal_thread_load_context+18>: mov 0x0(%eax),%esp
0x0800ea31 <hal_thread_load_context+21>: mov 0x18(%eax),%eax
0x0800ea34 <hal_thread_load_context+24>: cmp 0x8a0093c,%eax
0x0800ea3a <hal_thread_load_context+30>: je 0x800ea4a <interrupts_ok>
0x0800ea3c <hal_thread_load_context+32>: cmp $0x0,%eax
0x0800ea3f <hal_thread_load_context+35>: jne 0x800c766 <hal_enable_interrupts>
0x0800ea45 <hal_thread_load_context+41>: mov %eax,0x8a0093c
End of assembler dump.
Current language: auto; currently c++
(gdb) where
#0 0x0800ea31 in hal_thread_load_context ()
at /home/johnc/ttr3/TaitTerm_Base/bld/ecos/synth/MPT_Torso/rom/uninstrumented/install/include/cyg/infra/cyg_trac.h:685
#1 0x08006192 in global constructors keyed to cyg_scheduler_start ()
at /opt/ecos/ecos-2.0/packages/kernel/v2_0/src/common/kapi.cxx:196
Previous frame inner to this frame (corrupt stack?)
To create threads it switches the stack pointer itself whenever a thread
context switch would be appropriate via the following chunks of
assembler...
FUNC_START(hal_thread_switch_context)
movl 4(%esp),%eax # next context ptr
movl 8(%esp),%edx # this context ptr
# Make room on the stack for the context
movl %esp,%ecx # keep original SP
sub $i386reg_context_size,%esp
# Save next context ptr in this context. Necessary because
# hal_thread_load_context expects to find the ptr on the stack,
# not in a register as on PPC.
movl %eax,i386reg_next_context(%esp)
# Save registers
movl %ecx,i386reg_esp(%esp) # original esp
movl %ebp,i386reg_ebp(%esp)
movl %ebx,i386reg_ebx(%esp)
movl %esi,i386reg_esi(%esp)
movl %edi,i386reg_edi(%esp)
# And interrupt state
movl hal_interrupts_enabled,%eax
movl %eax,i386reg_interrupts(%esp)
# Store the context ptr
movl %esp,(%edx)
# Now fall through to hal_thread_load_context
#------------------------------------------------------------------------------
# hal_thread_load_context
# Load thread context
# : 4(%esp) = i386reg_next_context(%esp) = address of sp of thread to execute
# Note that this function is also the second half of hal_thread_switch_context
# and is simply dropped into from it.
#
# %eax, %ecx, and %edx are ours to abuse.
FUNC_START(hal_thread_load_context)
movl i386reg_next_context(%esp),%eax # get new context ptr
movl (%eax),%eax
# Restore registers
movl i386reg_ebp(%eax),%ebp
movl i386reg_ebx(%eax),%ebx
movl i386reg_esi(%eax),%esi
movl i386reg_edi(%eax),%edi
movl i386reg_esp(%eax),%esp
# And see what needs to happen about interrupts
movl i386reg_interrupts(%eax),%eax
cmpl hal_interrupts_enabled,%eax
je interrupts_ok
# The saved interrupt state differs from the current one.
# If interrupts are supposed to be enabled then invoke
# hal_enable_interrupts. That can be done as a tail call.
# If interrupts are supposed to be disabled then just
# update the global variable.
cmpl $0,%eax
jne hal_enable_interrupts
movl %eax,hal_interrupts_enabled
interrupts_ok:
ret
John Carter Phone : (64)(3) 358 6639
Tait Electronics Fax : (64)(3) 359 4632
PO Box 1645 Christchurch Email : joh...@ta...
New Zealand
Carter's Clarification of Murphy's Law.
"Things only ever go right so that they may go more spectacularly wrong later."
>From this principle, all of life and physics may be deduced.
|