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
(17) |
2
(15) |
3
(36) |
4
(24) |
5
(36) |
|
6
(18) |
7
(16) |
8
(18) |
9
(19) |
10
(18) |
11
(37) |
12
(18) |
|
13
(13) |
14
(21) |
15
(27) |
16
(10) |
17
(16) |
18
(25) |
19
(21) |
|
20
(11) |
21
(14) |
22
(6) |
23
(15) |
24
(27) |
25
(3) |
26
(9) |
|
27
(16) |
28
(24) |
29
(21) |
30
(43) |
31
(42) |
|
|
|
From: Jeremy F. <je...@go...> - 2005-03-17 17:58:32
|
Julian Seward wrote:
>
>
>>I wonder if this is another instance of a strange vendor-special
>>LinuxThreads/NPTL hybrid? The full trace will be interesting, to see
>>how the threads are created.
>>
>>
>
>Maybe. I was surprised to find recently that SuSE 9.1 (x86) didn't seem
>to be a 'normal' NPTL system; I thought it was. MichaelM, can you clarify?
>
>
If it were really expecting exit_group() to kill all the threads, then
I'd expect to see a lot more MT programs fail to exit on this system.
Or perhaps programs mostly clean up their threads before calling exit()?
J
|
|
From: Julian S. <js...@ac...> - 2005-03-17 17:51:17
|
On Thursday 17 March 2005 17:24, Nicholas Nethercote wrote: > On Thu, 17 Mar 2005, Jeremy Fitzhardinge wrote: > >> I'd prefer not to ship 2.4.0 with this bug in, if we can resolve it > >> relatively quickly. What else can I do to help you repro it? > > > > This doesn't strike me as a showstopper bug: it seems easy to work > > around (you can just ^C the process, yes?), it doesn't crash and it > > doesn't seem to be affecting many people. > > Does it preclude leak checking OOo? No, you can do control-C and then it moves onto leak checking. Still, it's a bit disconcerting. J |
|
From: Julian S. <js...@ac...> - 2005-03-17 17:40:49
|
> >I'd prefer not to ship 2.4.0 with this bug in, if we can resolve it > >relatively quickly. What else can I do to help you repro it? > > Also, a full --trace-syscalls=yes --trace-signals=yes output would be > useful. Done. I'll send it seperately as the mailing list doesn't like messages over 50k. > I wonder if this is another instance of a strange vendor-special > LinuxThreads/NPTL hybrid? The full trace will be interesting, to see > how the threads are created. Maybe. I was surprised to find recently that SuSE 9.1 (x86) didn't seem to be a 'normal' NPTL system; I thought it was. MichaelM, can you clarify? J |
|
From: Nicholas N. <nj...@cs...> - 2005-03-17 17:25:38
|
On Thu, 17 Mar 2005, Jeremy Fitzhardinge wrote: >> I'd prefer not to ship 2.4.0 with this bug in, if we can resolve it >> relatively quickly. What else can I do to help you repro it? >> > This doesn't strike me as a showstopper bug: it seems easy to work > around (you can just ^C the process, yes?), it doesn't crash and it > doesn't seem to be affecting many people. Does it preclude leak checking OOo? N |
|
From: Jeremy F. <je...@go...> - 2005-03-17 16:53:19
|
Julian Seward wrote:
>Is FC3 LinuxThreads or NPTL ? If NPTL, do you have a LinuxThreads
>system you can try reproducing this on? Is setting LD_ASSUME_KERNEL=2.4.1
>really exactly the same as running it on a LinuxThreads-only system?
>
>
>
>
>>Hard to tell, really. To be honest, it looks like an application bug.
>>Two threads remain; thread 2 is the LinuxThreads manager thread, so it
>>isn't going to go away until the other thread, thread 5, dies. Thread 5
>>seems to just be looping waiting for an FD which never happens. It
>>would be interesting to attach strace to thread 5 in this state to see
>>what FD it is actually waiting on.
>>
>>
>
>It looks like fd 12.
>
> poll([{fd=12, events=POLLIN}], 1, 1000) = 0
> rt_sigprocmask(SIG_SETMASK, ~[ILL TRAP BUS FPE KILL SEGV STOP], NULL, 8) = 0
> gettid() = 10505
> read(1017, "T", 2) = 1
> getpid() = 10505
> write(1016, "SYSCALL[10505,5](168) --> 0 (0x0"..., 34) = 34
> getpid() = 10505
> write(1016, "SYSCALL[10505,5]( 78):", 22) = 22
> write(1016, "sys_gettimeofday ( 0xAEFFFA04, 0"..., 36) = 36
> gettimeofday({1111060117, 380070}, NULL) = 0
> write(1016, " --> 0 (0x0)\n", 13) = 13
> getpid() = 10505
> write(1016, "SYSCALL[10505,5](168) mayBlock:", 31) = 31
> write(1016, "sys_poll ( 0xAEFFF94C, 1, 1000 )"..., 33) = 33
> write(1016, " --> ...\n", 9) = 9
> gettid() = 10505
> write(1018, "T", 1) = 1
> rt_sigprocmask(SIG_SETMASK, [RTMIN RT_31], ~[ILL TRAP BUS FPE KILL SEGV
>STOP], 8) = 0
> poll(
>
>In the (non-truncated version of the) log I sent yesterday,
>fd 12 is used many times (open, mmap, close). The last
>place it appears to have been *created* is
>
>SYSCALL[4719,1](102) mayBlock:sys_socketcall ( 1, 0xAFEFCD40 ) --> ...
>SYSCALL[4719,1](102) --> 12 (0xC)
>
>The last place I can see it referenced is:
>
>SYSCALL[4743,5]( 54) mayBlock:sys_ioctl ( 12, 0x541B (type=54, nr=1B, size=0),
>0x2D ) --> ...
>SYSCALL[4743,5]( 54) --> 0 (0x0)
>SYSCALL[4743,5]( 3) mayBlock:sys_read ( 12, 0xAEFFF0F4, 128 ) --> ...
>SYSCALL[4743,5]( 3) --> 128 (0x80)
>SYSCALL[4743,5]( 54) mayBlock:sys_ioctl ( 12, 0x541B (type=54, nr=1B, size=0),
>0x2D ) --> ...
>SYSCALL[4743,5]( 54) --> 0 (0x0)
>
>So I'm none the wiser.
>
>Ioctl 0x541B is FIONREAD.
>
>I'd prefer not to ship 2.4.0 with this bug in, if we can resolve it
>relatively quickly. What else can I do to help you repro it?
>
>
Also, a full --trace-syscalls=yes --trace-signals=yes output would be
useful.
Something strange is definitely happening on your system. I'm pretty
sure fd 12 is the connection to the X server; it's a red herring.
What's suppose to happen is that thread 1 is supposed to tell the
manager to shut everything down. In your trace, it just exits quietly:
SYSCALL[4719,1](174) special:sys_rt_sigaction ( 3, 0xAFEFDB70, 0x0, 8 )
--> 0 (0x0)
SYSCALL[4719,1](174) special:sys_rt_sigaction ( 2, 0xAFEFDB70, 0x0, 8 )
--> 0 (0x0)
SYSCALL[4719,1](174) special:sys_rt_sigaction ( 1, 0xAFEFDB70, 0x0, 8 )
--> 0 (0x0)
SYSCALL[4719,1]( 91):sys_munmap ( 0x3DA0E000, 65536 ) --> 0 (0x0)
SYSCALL[4719,1]( 6):sys_close ( 18 ) --> 0 (0x0)
SYSCALL[4719,1]( 6):sys_close ( 13 ) --> 0 (0x0)
SYSCALL[4719,1](252) special:exit_group( 0 ) --> 252 (0xFC)
In my trace, thread 1 sends messages to the manager who in turn kills
off the other thread and itself before thread 1 finally exits.
I wonder if this is another instance of a strange vendor-special
LinuxThreads/NPTL hybrid? The full trace will be interesting, to see
how the threads are created.
J
|
|
From: Bryan O'S. <bo...@se...> - 2005-03-17 16:50:52
|
On Thu, 2005-03-17 at 16:08 +0000, Julian Seward wrote: > However, if one of the bits of extra knowledge happens to be a copy > of the function's body, then at least there is the possibility that > it can inline the fn. Yes. It's unfortunately very difficult to figure out which functions are candidates for inlining, and which are going to be merely decorated in the IR. You can't simply grep for something in builtins.def. We've ended up just tracking each inlined case down by hand in our compiler as we've needed to reproduce something gcc does. <b -- Bryan O'Sullivan <bo...@se...> |
|
From: Jeremy F. <je...@go...> - 2005-03-17 16:21:58
|
Julian Seward wrote:
>But it exits normally when run natively, and it also works fine on 2.2.0.
>
>
That doesn't preclude a race or some timing problem in their code. Does
it happen with other tools?
>Is FC3 LinuxThreads or NPTL ? If NPTL, do you have a LinuxThreads
>system you can try reproducing this on? Is setting LD_ASSUME_KERNEL=2.4.1
>really exactly the same as running it on a LinuxThreads-only system?
>
>
Well, it uses the same libpthread.so. The big difference is that it's
using a 2.6 kernel. I assume SuSE 9.1 is using some 2.4 kernel.
>>> Hard to tell, really. To be honest, it looks like an application bug.
>>> Two threads remain; thread 2 is the LinuxThreads manager thread, so it
>>> isn't going to go away until the other thread, thread 5, dies. Thread 5
>>> seems to just be looping waiting for an FD which never happens. It
>>> would be interesting to attach strace to thread 5 in this state to see
>>> what FD it is actually waiting on.
>>
>>
>
>It looks like fd 12.
>
> poll([{fd=12, events=POLLIN}], 1, 1000) = 0
> rt_sigprocmask(SIG_SETMASK, ~[ILL TRAP BUS FPE KILL SEGV STOP], NULL, 8) = 0
> gettid() = 10505
> read(1017, "T", 2) = 1
> getpid() = 10505
> write(1016, "SYSCALL[10505,5](168) --> 0 (0x0"..., 34) = 34
> getpid() = 10505
> write(1016, "SYSCALL[10505,5]( 78):", 22) = 22
> write(1016, "sys_gettimeofday ( 0xAEFFFA04, 0"..., 36) = 36
> gettimeofday({1111060117, 380070}, NULL) = 0
> write(1016, " --> 0 (0x0)\n", 13) = 13
> getpid() = 10505
> write(1016, "SYSCALL[10505,5](168) mayBlock:", 31) = 31
> write(1016, "sys_poll ( 0xAEFFF94C, 1, 1000 )"..., 33) = 33
> write(1016, " --> ...\n", 9) = 9
> gettid() = 10505
> write(1018, "T", 1) = 1
> rt_sigprocmask(SIG_SETMASK, [RTMIN RT_31], ~[ILL TRAP BUS FPE KILL SEGV
>STOP], 8) = 0
> poll(
>
>In the (non-truncated version of the) log I sent yesterday,
>fd 12 is used many times (open, mmap, close). The last
>place it appears to have been *created* is
>
>SYSCALL[4719,1](102) mayBlock:sys_socketcall ( 1, 0xAFEFCD40 ) --> ...
>SYSCALL[4719,1](102) --> 12 (0xC)
>
>The last place I can see it referenced is:
>
>SYSCALL[4743,5]( 54) mayBlock:sys_ioctl ( 12, 0x541B (type=54, nr=1B, size=0),
>0x2D ) --> ...
>SYSCALL[4743,5]( 54) --> 0 (0x0)
>SYSCALL[4743,5]( 3) mayBlock:sys_read ( 12, 0xAEFFF0F4, 128 ) --> ...
>SYSCALL[4743,5]( 3) --> 128 (0x80)
>SYSCALL[4743,5]( 54) mayBlock:sys_ioctl ( 12, 0x541B (type=54, nr=1B, size=0),
>0x2D ) --> ...
>SYSCALL[4743,5]( 54) --> 0 (0x0)
>
>So I'm none the wiser.
>
>Ioctl 0x541B is FIONREAD.
>
>
I guess we need to find out what's at the other end of the socket. Just
after its creation, what other socket operations happen on it? It would
be useful to have strace output, since it gives more detail about what
the syscall args are.
Are there any other processes sitting around which it might be trying to
talk to? "lsof" might give a clue.
>I'd prefer not to ship 2.4.0 with this bug in, if we can resolve it
>relatively quickly. What else can I do to help you repro it?
>
>
This doesn't strike me as a showstopper bug: it seems easy to work
around (you can just ^C the process, yes?), it doesn't crash and it
doesn't seem to be affecting many people. If we can track it down in
the near future and the fix is a one-liner then OK, but otherwise I
think 2.4.0 is cooked.
J
|
|
From: Julian S. <js...@ac...> - 2005-03-17 16:09:01
|
> Not every builtin results in inlined code. There's a built-in version > of malloc because malloc has some interesting properties. For > example, the returned pointer can never alias anything else, and it > has maximum alignment. What you and Bryan seem to be saying is: a gcc builtin is a fn that the compiler has some extra knowledge about, beyond the standard prototype. That doesn't imply that it will inline that function. However, if one of the bits of extra knowledge happens to be a copy of the function's body, then at least there is the possibility that it can inline the fn. J |
|
From: Florian W. <fw...@de...> - 2005-03-17 15:59:32
|
* Nicholas Nethercote: > Hmm, that's weird -- strcpy() is in that file on my installation, but it > doesn't get inlined. More alarmingly, malloc() is also in that file... if > gcc inlined that (how on earth could it?) that would be a disaster for > Valgrind. Not every builtin results in inlined code. There's a built-in version of malloc because malloc has some interesting properties. For example, the returned pointer can never alias anything else, and it has maximum alignment. |
|
From: Julian S. <js...@ac...> - 2005-03-17 13:45:33
|
CVS commit by jseward: Bring a bit more up to date. M +43 -25 ACKNOWLEDGEMENTS 1.2 --- valgrind/ACKNOWLEDGEMENTS #1.1.1.1:1.2 @@ -1,26 +1,44 @@ -The following people contributed in some way to valgrind, during its -long journey over the past two years or so. Here's a list. If I have -forgotten you, I do apologise; let me know (js...@ac...) and I'll -fix it. - -Donna Robinson <do...@mu...> - for many reasons, including endless encouragement, and - persuading me I wasn't crazy to try doing this - -Rob Noble <rob...@an...> - for early encouragement, support, suggestions, and asking of - many questions - -Reuben Thomas <rr...@sc...> - for discussions about value tag operations, and making me - laugh - -Various KDE folks, for suffering recent versions of valgrind, - providing many patches, questions and helpful feedback - Dirk Mueller <mu...@kd...> - Stephan Kulow <co...@kd...> - Michael Matz <ma...@kd...> - Simon Hausmann <hau...@kd...> - David Faure <da...@ma...> - Ellis Whitehead <kd...@el...> +Julian Seward, ju...@va... + +Julian was the original designer and author of Valgrind, created the +dynamic translation framework, wrote Memcheck and Addrcheck, and did +lots of other things. + +Nicholas Nethercote, nj...@va... + +Nick did the core/tool generalisation, wrote Cachegrind and Massif, +and tons of other stuff. + +Jeremy Fitzhardinge, je...@va... + +Jeremy wrote Helgrind and totally overhauled low-level syscall/signal +and address space layout stuff, among many other improvements. + +Tom Hughes, to...@va... + +Tom did a vast number of bug fixes, and helped out with support for +more recent Linux/glibc versions. + +Robert Walsh, rj...@va... + +Robert added file descriptor leakage checking, new library +interception machinery, support for client allocation pools, and minor +other tweakage. + +Dirk Mueller, dm...@gm... + +Dirk contributed the malloc-free mismatch checking stuff and various +other bits and pieces, and acted as our KDE liaison. + +Donna Robinson, do...@te... + +Keeper of the very excellent http://www.valgrind.org. + +Frederic Gobry helped with autoconf and automake. Daniel Berlin +modified readelf's dwarf2 source line reader, written by Nick Clifton, +for use in Valgrind. Michael Matz and Simon Hausmann modified the GNU +binutils demangler(s) for use in Valgrind. + +And lots and lots of other people sent bug reports, patches, and very +helpful feedback. |
|
From: Julian S. <js...@ac...> - 2005-03-17 12:25:57
|
Is FC3 LinuxThreads or NPTL ? If NPTL, do you have a LinuxThreads
system you can try reproducing this on? Is setting LD_ASSUME_KERNEL=2.4.1
really exactly the same as running it on a LinuxThreads-only system?
> Hard to tell, really. To be honest, it looks like an application bug.
> Two threads remain; thread 2 is the LinuxThreads manager thread, so it
> isn't going to go away until the other thread, thread 5, dies. Thread 5
> seems to just be looping waiting for an FD which never happens. It
> would be interesting to attach strace to thread 5 in this state to see
> what FD it is actually waiting on.
It looks like fd 12.
poll([{fd=12, events=POLLIN}], 1, 1000) = 0
rt_sigprocmask(SIG_SETMASK, ~[ILL TRAP BUS FPE KILL SEGV STOP], NULL, 8) = 0
gettid() = 10505
read(1017, "T", 2) = 1
getpid() = 10505
write(1016, "SYSCALL[10505,5](168) --> 0 (0x0"..., 34) = 34
getpid() = 10505
write(1016, "SYSCALL[10505,5]( 78):", 22) = 22
write(1016, "sys_gettimeofday ( 0xAEFFFA04, 0"..., 36) = 36
gettimeofday({1111060117, 380070}, NULL) = 0
write(1016, " --> 0 (0x0)\n", 13) = 13
getpid() = 10505
write(1016, "SYSCALL[10505,5](168) mayBlock:", 31) = 31
write(1016, "sys_poll ( 0xAEFFF94C, 1, 1000 )"..., 33) = 33
write(1016, " --> ...\n", 9) = 9
gettid() = 10505
write(1018, "T", 1) = 1
rt_sigprocmask(SIG_SETMASK, [RTMIN RT_31], ~[ILL TRAP BUS FPE KILL SEGV
STOP], 8) = 0
poll(
In the (non-truncated version of the) log I sent yesterday,
fd 12 is used many times (open, mmap, close). The last
place it appears to have been *created* is
SYSCALL[4719,1](102) mayBlock:sys_socketcall ( 1, 0xAFEFCD40 ) --> ...
SYSCALL[4719,1](102) --> 12 (0xC)
The last place I can see it referenced is:
SYSCALL[4743,5]( 54) mayBlock:sys_ioctl ( 12, 0x541B (type=54, nr=1B, size=0),
0x2D ) --> ...
SYSCALL[4743,5]( 54) --> 0 (0x0)
SYSCALL[4743,5]( 3) mayBlock:sys_read ( 12, 0xAEFFF0F4, 128 ) --> ...
SYSCALL[4743,5]( 3) --> 128 (0x80)
SYSCALL[4743,5]( 54) mayBlock:sys_ioctl ( 12, 0x541B (type=54, nr=1B, size=0),
0x2D ) --> ...
SYSCALL[4743,5]( 54) --> 0 (0x0)
So I'm none the wiser.
Ioctl 0x541B is FIONREAD.
I'd prefer not to ship 2.4.0 with this bug in, if we can resolve it
relatively quickly. What else can I do to help you repro it?
J
|
|
From: Julian S. <js...@ac...> - 2005-03-17 11:40:56
|
> Hard to tell, really. To be honest, it looks like an application bug. But it exits normally when run natively, and it also works fine on 2.2.0. > Which tool? How are you starting OOo? I can't reproduce it with the > FC3 1.1.3 OOo: ~/Vg240/valgrind/Inst/bin/valgrind --trace-children=yes --tool=none ~/OpenOffice.org1.1.3/soffice J |
|
From: Julian S. <js...@ac...> - 2005-03-17 11:22:52
|
CVS commit by jseward: Reword somewhat. M +66 -59 NEWS 1.32 --- valgrind/NEWS #1.31:1.32 @@ -1,54 +1,60 @@ Stable release 2.4.0 (March 2005) -- CHANGES RELATIVE TO 2.2.0 -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -2.4.0 represents another architectural change for Valgrind. The most -significant user-visible change is that we no longer emulate -libpthread; this has both pluses and minuses. - -* Memcheck is now the default tool - -* The default stack backtrace is now 12 call frames - -* Suppressions can have up to 25 call frame matches, rather than - just 4 - -* libpthread has gone along with all the bugs associated with it. - Instead, Valgrind now emulates the kernel's threading syscalls - (clone, etc), and lets you use your standard system libpthread. - This means: - - - There should be many fewer system dependencies and strange - library-related bugs. There is a small performance improvement, - and a large stability improvement. - - - On the downside, this means that Valgrind can no longer report - on problems with how your program uses threads. It also means - that Helgrind is currently non-functional. We're hoping to - fix these for a (near) future release. - -* Addrcheck and memcheck use a lot less memory for many programs. - These tools no longer need to allocate shadow memory if there are - large regions of memory with the same A/V states - such as an - mmaped file. - -* Addrcheck and memcheck's leak-detector has been improved. It now - reports many more types of memory leak, including leaked cycles. - When reporting leaked memory, it can distinguish between directly - leaked memory (memory with no references), and indirectly leaked - memory (memory only referred to by other leaked memory). - -* Memcheck's confusion over the effect of mprotect() has been fixed; - previously mprotect could erroneously make undefined data defined. - -* State passed to signal handlers may be modified so that it will take - effect when the signal returns. You will need run with --single-step=yes - to make this useful. - -* In general, signal handling should now be indistinguishable from - running natively. +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +2.4.0 brings many significant changes and bug fixes. The most +significant user-visible change is that we no longer supply our own +pthread implementation. Instead, Valgrind is finally capable of +running the native thread library, either LinuxThreads or NPTL. + +This means our libpthread has gone, along with the bugs associated +with it. Valgrind now supports the kernel's threading syscalls, and +lets you use your standard system libpthread. As a result: + +* There are many fewer system dependencies and strange library-related + bugs. There is a small performance improvement, and a large + stability improvement. + +* On the downside, Valgrind can no longer report misuses of the POSIX + PThreads API. It also means that Helgrind currently does not work. + We hope to fix these problems in a future release. + +Note that running the native thread libraries does not mean Valgrind +is able to provide genuine concurrent execution on SMPs. We still +impose the restriction that only one thread is running at any given +time. + +There are many other significant changes too: + +* Memcheck is (once again) the default tool. + +* The default stack backtrace is now 12 call frames, rather than 4. + +* Suppressions can have up to 25 call frame matches, rather than 4. + +* Memcheck and Addrcheck use less memory. Under some circumstances, + they no longer allocate shadow memory if there are large regions of + memory with the same A/V states - such as an mmaped file. + +* The memory-leak detector in Memcheck and Addrcheck has been + improved. It now reports more types of memory leak, including + leaked cycles. When reporting leaked memory, it can distinguish + between directly leaked memory (memory with no references), and + indirectly leaked memory (memory only referred to by other leaked + memory). + +* Memcheck's confusion over the effect of mprotect() has been fixed: + previously mprotect could erroneously mark undefined data as + defined. + +* Signal handling is much improved and should be very close to what + you get when running natively. + + One result of this is that Valgrind observes changes to sigcontexts + passed to signal handlers. Such modifications will take effect when + the signal returns. You will need to run with --single-step=yes to + make this useful. * Valgrind is built in Position Independent Executable (PIE) format if - the toolchain supports it. This allows it to take advantage of all + your toolchain supports it. This allows it to take advantage of all the available address space on systems with 4Gbyte user address spaces. @@ -56,15 +62,15 @@ * Valgrind can now run itself (requires PIE support). -* Syscall arguments are now checked for validity. Previously all memory - used by syscalls was checked, but now the actual values passed - are also checked. - -* Syscall wrappers are now more robust against bad addresses being - passed to syscalls; they will fail with EFAULT rather than killing - Valgrind with SIGSEGV. - -* Because clone() is directly supported, many non-pthread uses of - it will work. Partial sharing (where some resources are shared, - and some are not) is not supported. +* Syscall arguments are now checked for validity. Previously all + memory used by syscalls was checked, but now the actual values + passed are also checked. + +* Syscall wrappers are more robust against bad addresses being passed + to syscalls: they will fail with EFAULT rather than killing Valgrind + with SIGSEGV. + +* Because clone() is directly supported, some non-pthread uses of it + will work. Partial sharing (where some resources are shared, and + some are not) is not supported. * open() and readlink() on /proc/self/exe are supported. @@ -158,4 +164,5 @@ 101562 valgrind massif dies on SIGINT even with signal handler r... + Stable release 2.2.0 (31 August 2004) -- CHANGES RELATIVE TO 2.0.0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
|
From: <js...@ac...> - 2005-03-17 04:02:30
|
Nightly build on phoenix ( SuSE 9.1 ) started at 2005-03-17 03:50:00 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow insn_mmx: valgrind ./insn_mmx insn_mmxext: (skipping, prereq failed: ../../../tests/cputest x86-mmxext) insn_sse: valgrind ./insn_sse insn_sse2: (skipping, prereq failed: ../../../tests/cputest x86-sse2) int: valgrind ./int pushpopseg: valgrind ./pushpopseg rcl_assert: valgrind ./rcl_assert seg_override: valgrind ./seg_override -- Finished tests in none/tests/x86 ------------------------------------ yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 201 tests, 5 stderr failures, 0 stdout failures ================= memcheck/tests/pth_once (stderr) memcheck/tests/scalar (stderr) memcheck/tests/threadederrno (stderr) memcheck/tests/writev (stderr) corecheck/tests/fdleak_fcntl (stderr) make: *** [regtest] Error 1 |
|
From: Jeremy F. <je...@go...> - 2005-03-17 01:10:04
|
Paul Mackerras wrote:
>Jeremy Fitzhardinge writes:
>
>
>
>>Hard to tell, really. To be honest, it looks like an application bug.
>>Two threads remain; thread 2 is the LinuxThreads manager thread, so it
>>isn't going to go away until the other thread, thread 5, dies. Thread 5
>>seems to just be looping waiting for an FD which never happens. It
>>would be interesting to attach strace to thread 5 in this state to see
>>what FD it is actually waiting on.
>>
>>
>
>Ummm, hasn't some other thread done an exit_group()? That is supposed
>to kill all the threads in the current process. We shouldn't expect
>every thread to do exit_group.
>
This is LinuxThreads, so each thread is in its own thread group as far
as the kernel is concerned. NPTL threads are all killed by exit_group().
J
|
|
From: Paul M. <pa...@sa...> - 2005-03-17 00:29:07
|
Jeremy Fitzhardinge writes: > Hard to tell, really. To be honest, it looks like an application bug. > Two threads remain; thread 2 is the LinuxThreads manager thread, so it > isn't going to go away until the other thread, thread 5, dies. Thread 5 > seems to just be looping waiting for an FD which never happens. It > would be interesting to attach strace to thread 5 in this state to see > what FD it is actually waiting on. Ummm, hasn't some other thread done an exit_group()? That is supposed to kill all the threads in the current process. We shouldn't expect every thread to do exit_group. Paul. |