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
(6) |
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
1
(1) |
2
(8) |
3
(26) |
4
(14) |
5
(23) |
6
(8) |
7
(6) |
|
8
(1) |
9
(5) |
10
|
11
(7) |
12
|
13
(4) |
14
(2) |
|
15
|
16
(6) |
17
(4) |
18
(18) |
19
(10) |
20
(13) |
21
(2) |
|
22
|
23
(1) |
24
(7) |
25
(13) |
26
(35) |
27
(5) |
28
(2) |
|
29
(3) |
30
(5) |
31
(7) |
|
|
|
|
|
From: Nicholas N. <nj...@ca...> - 2004-08-26 09:56:51
|
On Thu, 26 Aug 2004, Nicholas Nethercote wrote: > If you can prevent your program from using the 2nd form of "enter", that > would be a workaround. Or, as Tom says, you might have buggy code that is jumping to a random location that just happens to look like a nested "enter". N |
|
From: Nicholas N. <nj...@ca...> - 2004-08-26 09:48:59
|
On Thu, 26 Aug 2004, Dimitri Papadopoulos-Orfanos wrote: > But now Valgrind crashes with the following message. Is this a known issue, > or should I file in a bug? I wasn't able to relate this crash to any of the > FAQ items. It's new. > valgrind: vg_to_ucode.c:5285 (disInstr): Assertion `abyte == 0' failed. > ==10615== at 0xB002AA26: vgPlain_skin_assert_fail (vg_mylibc.c:1169) > ==10615== by 0xB002AA25: assert_fail (vg_mylibc.c:1165) > ==10615== by 0xB002AA63: vgPlain_core_assert_fail (vg_mylibc.c:1176) > ==10615== by 0xB00511DA: disInstr (vg_to_ucode.c:7300) Ah, the instruction "enter" has two forms. The common form is: enter $n, $0 which creates a stack frame. Although it's not used very often (eg. gcc doesn't generate it AFAICT). Valgrind supports that fine. But if the second argument is non-zero, eg: enter $n, $1 then it creates a weird "nested stack frame" which involves copying multiple old frame pointers. Valgrind doesn't handle this case because it's (a) a pain to simulate, and (b) so rare -- you're the first person who's come across it, AFAIK. I'll create a bug report for it. Hopefully someone will take it upon themselves to implement it. If you're feeling adventurous, you could try making a patch for it. If you can prevent your program from using the 2nd form of "enter", that would be a workaround. N |
|
From: Tom H. <th...@cy...> - 2004-08-26 09:46:46
|
In message <412...@sh...>
Dimitri Papadopoulos-Orfanos <pap...@sh...> wrote:
> But now Valgrind crashes with the following message. Is this a known
> issue, or should I file in a bug? I wasn't able to relate this crash
> to any of the FAQ items.
Please file a bug.
> valgrind: vg_to_ucode.c:5285 (disInstr): Assertion `abyte == 0' failed.
> ==10615== at 0xB002AA26: vgPlain_skin_assert_fail (vg_mylibc.c:1169)
> ==10615== by 0xB002AA25: assert_fail (vg_mylibc.c:1165)
> ==10615== by 0xB002AA63: vgPlain_core_assert_fail (vg_mylibc.c:1176)
> ==10615== by 0xB00511DA: disInstr (vg_to_ucode.c:7300)
That's an ENTER instruction with a non-zero nesting level. It sounds
like a pretty unusual instruction to be using - are you sure your program
isn't jumping through a bad pointer somewhere?
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Andrew C. <and...@fr...> - 2004-08-26 09:43:08
|
(PS. I thought I sent this the other day, but it didn't show up on the list - excuse me if its a dupe) I've been trying to get valgrind working to debug a plugin (.so dynamically loaded into host app) of mine which is written for Alias' Maya 3D app (www.alias.com). I have the source to my plugin, but only binaries for Maya. Maya is a huge pig of a program, that generally thwarts any debugging attempts, but valgrind is doing excellent things for my standalone apps so I was hoping to get it working. When I run 'valgrind --tool=memcheck /opt/aw/maya6.0/bin/maya.bin' I get the following output ending in a segfault: ==12627== Memcheck, a memory error detector for x86-linux. ==12627== Copyright (C) 2002-2004, and GNU GPL'd, by Julian Seward et al. ==12627== Using valgrind-2.1.2, a program supervision framework for x86-linux. ==12627== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward et al. ==12627== For more details, rerun with: -v ==12627== ==12627== Invalid read of size 4 ==12627== at 0x4F9EECE4: _IO_vfprintf_internal (in /lib/i686/libc-2.3.2.so) ==12627== by 0x4FA0FC5F: _IO_vsnprintf (in /lib/i686/libc-2.3.2.so) ==12627== by 0x2074B08E: AL_vsnprintf (in /opt/aw/maya6.0/lib/libBase.so) ==12627== by 0x20776CB5: awString::CStringImpl::doFormat(char const*, char*, unsigned) (in /opt/aw/maya6.0/lib/libBase.so) ==12627== Address 0x0 is not stack'd, malloc'd or (recently) free'd ==12627== ==12627== Process terminating with default action of signal 11 (SIGSEGV) ==12627== Access not within mapped region at address 0x0 ==12627== at 0x4F9EECE4: _IO_vfprintf_internal (in /lib/i686/libc-2.3.2.so) ==12627== by 0x4FA0FC5F: _IO_vsnprintf (in /lib/i686/libc-2.3.2.so) ==12627== by 0x2074B08E: AL_vsnprintf (in /opt/aw/maya6.0/lib/libBase.so) ==12627== by 0x20776CB5: awString::CStringImpl::doFormat(char const*, char*, unsigned) (in /opt/aw/maya6.0/lib/libBase.so) ==12627== ==12627== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 123 from 1) ==12627== malloc/free: in use at exit: 641217 bytes in 19 blocks. ==12627== malloc/free: 21 allocs, 2 frees, 641225 bytes allocated. ==12627== For a detailed leak analysis, rerun with: --leak-check=yes ==12627== For counts of detected errors, rerun with: -v Segmentation fault The errors it reports I'm not concerned about, just the fact it dies. This is with valgrind v2.1.2 on Fedora Core 1. Interestingly I get the same output with '-tool=none'. Anyone have any ideas? There is a free download version of Maya available from www.alias.com if anyone else was interested in trying valgrind with it. -- Andrew Chapman Senior Technical Director - Framestore CFC |
|
From: Dimitri Papadopoulos-O. <pap...@sh...> - 2004-08-26 09:24:47
|
Hi, I'm running Valgrind 2.1.2 on Red Hat 9. I'm using it to debug some not always reproducible crashes in program distcc 2.17 under high load. I've replaced program distcc by a script that launches distcc under Valgrind. But now Valgrind crashes with the following message. Is this a known issue, or should I file in a bug? I wasn't able to relate this crash to any of the FAQ items. Note that the distcc stack probably gets corrupted: I couldn't get meaningful stack traces from the core files in any debugger. ==10615== Memcheck, a memory error detector for x86-linux. ==10615== Copyright (C) 2002-2004, and GNU GPL'd, by Julian Seward et al. ==10615== Using valgrind-2.1.2, a program supervision framework for x86-linux. ==10615== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward et al. ==10615== For more details, rerun with: -v ==10615== distcc[10615] ERROR: Connect timeout valgrind: vg_to_ucode.c:5285 (disInstr): Assertion `abyte == 0' failed. ==10615== at 0xB002AA26: vgPlain_skin_assert_fail (vg_mylibc.c:1169) ==10615== by 0xB002AA25: assert_fail (vg_mylibc.c:1165) ==10615== by 0xB002AA63: vgPlain_core_assert_fail (vg_mylibc.c:1176) ==10615== by 0xB00511DA: disInstr (vg_to_ucode.c:7300) sched status: Thread 1: status = Runnable, associated_mx = 0x0, associated_cv = 0x0 ==10615== at 0x52BFE0A4: ??? Note: see also the FAQ.txt in the source distribution. It contains workarounds to several common problems. If that doesn't help, please report this bug to: valgrind.kde.org In the bug report, send all the above text, the valgrind version, and what Linux distro you are using. Thanks. Regards, Dimitri |
|
From: Tom H. <th...@cy...> - 2004-08-26 09:19:43
|
In message <Pin...@he...>
Nicholas Nethercote <nj...@ca...> wrote:
> On Thu, 26 Aug 2004, Tom Hughes wrote:
>
>>> Hmm? I would have expected that the simulated environment created by
>>> Valgrind (CPU and parts of Linux/libc) behaves the same as the environment
>>> being simulated. Any deviation may (and hence one day will) make the
>>> program being tested behave differently when run with or without Valgrind,
>>> reducing its effectiveness.
>>
>> The problem is that there is not a one-one (or even a one-many) mapping
>> from instructions in the original program to JITed instructions
>
> Hmm, that's not really true; there is a one-many mapping from
> original-->JITted instructions. The INCEIP UCode instruction marks
> the boundaries.
You are quite right of course. I thought there was some mingling
at the boundaries when we translated back from UCode to x86 but
presumably if there is it doesn't across an INCEIP instruction.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Tom H. <th...@cy...> - 2004-08-26 09:18:04
|
In message <yek...@au...>
Tom Hughes <th...@cy...> wrote:
> In message <254...@we...>
> Jeroen N. Witmond <jn...@xs...> wrote:
>
>> Also, in the case of a SIGSEGV, Valgrind is quite capable to set the
>> user's EIP in fields:
>>
>> - ((ucontext_t*)context)->uc_mcontext.gregs[REG_EIP], where 'void*
>> context' is the third argument to the sa_sigaction in struct sigaction.
>> 'ucontext_t' is declared by '#include <ucontext.h>'. Just now I have
>> verified that this field is also set correctly by Valgrind in the case of
>> a SIGFPE.
>>
>> - ctx.eip, where 'struct sigcontext ctx' is the undocumented second
>> argument to the sa_handler in struct sigaction.
>
> I know all that. Are you saying that valgrind is already doing so? or
> just that it should be doing so?
Sorry. I misread what you wrote. You are saying that valgrind does
fill in the context. In that case filling in si_addr should be easy
to do - please file a bug and I'll sort it out.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Nicholas N. <nj...@ca...> - 2004-08-26 09:14:14
|
On Thu, 26 Aug 2004, Tom Hughes wrote: >> Hmm? I would have expected that the simulated environment created by >> Valgrind (CPU and parts of Linux/libc) behaves the same as the environment >> being simulated. Any deviation may (and hence one day will) make the >> program being tested behave differently when run with or without Valgrind, >> reducing its effectiveness. > > The problem is that there is not a one-one (or even a one-many) mapping > from instructions in the original program to JITed instructions Hmm, that's not really true; there is a one-many mapping from original-->JITted instructions. The INCEIP UCode instruction marks the boundaries. > so it isn't clear which instruction in your program valgrind should make > si_addr point to as it doesn't record which instruction in your program > caused each instruction in the JITed code to be generated, and it might > not even be a single instruction. >> Should I create a bug report for this problem? > > You are welcome to do so, but I don't think it's fixable. It's even > harder than filling in the right FP state (which we don't do) or allowing > the state to be modified (which we don't do). There are already bugs > for those things... It's unclear to me what the right thing to do here is. So here's a question: Jeroen, how did you discover this? Is this behaviour causing problems for you in a real program? If so, can you explain how/why? And would changing the behaviour in the way you say fix the problem? Thanks. N |
|
From: Tom H. <th...@cy...> - 2004-08-26 09:00:31
|
In message <254...@we...>
Jeroen N. Witmond <jn...@xs...> wrote:
> Hmm? I would have expected that the simulated environment created by
> Valgrind (CPU and parts of Linux/libc) behaves the same as the environment
> being simulated. Any deviation may (and hence one day will) make the
> program being tested behave differently when run with or without Valgrind,
> reducing its effectiveness.
The problem is that there is not a one-one (or even a one-many) mapping
from instructions in the original program to JITed instructions so it
isn't clear which instruction in your program valgrind should make si_addr
point to as it doesn't record which instruction in your program caused
each instruction in the JITed code to be generated, and it might not
even be a single instruction.
> Also, in the case of a SIGSEGV, Valgrind is quite capable to set the
> user's EIP in fields:
>
> - ((ucontext_t*)context)->uc_mcontext.gregs[REG_EIP], where 'void*
> context' is the third argument to the sa_sigaction in struct sigaction.
> 'ucontext_t' is declared by '#include <ucontext.h>'. Just now I have
> verified that this field is also set correctly by Valgrind in the case of
> a SIGFPE.
>
> - ctx.eip, where 'struct sigcontext ctx' is the undocumented second
> argument to the sa_handler in struct sigaction.
I know all that. Are you saying that valgrind is already doing so? or
just that it should be doing so?
> [In the case of a SIGSEGV, siginfo->si_addr contains the address of the
> memory that cannot be accessed, not the address of the instruction doing
> the accessing. Not verified under Valgrind.]
Indeed it should, and I believe it will do. There is no translation
done on si_addr so you will get the address the kernel reports, but
for a SEGV that is fine as that is the address in your program.
It won't be the same address as when run outside of valgrind of
course, but that's because your data will probably be laid out
differently in memory. It will be the address your program tried
to read from.
> Should I create a bug report for this problem?
You are welcome to do so, but I don't think it's fixable. It's even
harder than filling in the right FP state (which we don't do) or allowing
the state to be modified (which we don't do). There are already bugs
for those things...
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Jeroen N. W. <jn...@xs...> - 2004-08-26 08:45:42
|
> In message <207...@we...> > "Jeroen N. Witmond" <jn...@xs...> wrote: > >> It looks as if I have stumbled across a bug in the way valgrind (CVS) >> handles signal SIGFPE. To demonstrate this problem, I have created and >> attached file SIGFPEc.c. >> >> The problem: When I run this program stand-alone [output in attached >> file >> SIGFPEc.check.txt], it shows that that siginfo->si_addr points somewhere >> in my executable. But when I run the very same executable under valgrind >> --tool=memcheck [output in attached file SIGFPEc.valgrind.txt], >> siginfo->si_addr points somewhere in valgrind's stage2. > > With SIGFPE si_addr is the address of the faulting instruction. When > running under valgrind all instructions in your program are simulated > by valgrind which does a just in time translation of your code. > > As a result the faulting instruction will always be in a different > place when running under valgrind. In particular in this case the > fault is probably occurring in one of the helper routines which is > used to handle division operations, hence the reason why the address > is inside stage2 as that is where the helper routines are. > Hmm? I would have expected that the simulated environment created by Valgrind (CPU and parts of Linux/libc) behaves the same as the environment being simulated. Any deviation may (and hence one day will) make the program being tested behave differently when run with or without Valgrind, reducing its effectiveness. Also, in the case of a SIGSEGV, Valgrind is quite capable to set the user's EIP in fields: - ((ucontext_t*)context)->uc_mcontext.gregs[REG_EIP], where 'void* context' is the third argument to the sa_sigaction in struct sigaction. 'ucontext_t' is declared by '#include <ucontext.h>'. Just now I have verified that this field is also set correctly by Valgrind in the case of a SIGFPE. - ctx.eip, where 'struct sigcontext ctx' is the undocumented second argument to the sa_handler in struct sigaction. [In the case of a SIGSEGV, siginfo->si_addr contains the address of the memory that cannot be accessed, not the address of the instruction doing the accessing. Not verified under Valgrind.] Should I create a bug report for this problem? Jeroen. |