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
|
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
1
(21) |
2
(16) |
3
(3) |
4
(8) |
5
(9) |
6
(9) |
|
7
(14) |
8
(16) |
9
(21) |
10
(39) |
11
(29) |
12
(23) |
13
(9) |
|
14
(5) |
15
(8) |
16
(17) |
17
(30) |
18
(8) |
19
(35) |
20
(2) |
|
21
|
22
(2) |
23
(8) |
24
(15) |
25
(6) |
26
(20) |
27
(4) |
|
28
(1) |
29
(4) |
30
(8) |
31
(19) |
|
|
|
|
From: John R.
|
>>vex x86->IR: unhandled instruction bytes: 0xF0 0xF 0xC7 0xE >>Process terminating with default action of signal 4 (SIGILL): dumping core > > > That's a "mov Ez, Iz" instruction (with lock prefix). Please raise > a bug for it so we can fix it for the next release. No. The 0xF means 2-byte opcode, which makes 0xC7 /1 into 'cmpxchg8b', which is a fundamental operation for mutual exclusion. Vex is just going to have to learn it, or else quit pretending to support threads. -- |
|
From: John R.
|
> please tell me *HOW* to disassemble instructions
(gdb) x/i <address> # see "help data": x/FMT ADDR 'i'==>instruction
If you don't have a running program, or the address, handy,
then create one:
$ cat foo.S
.byte 0xF0,0xF,0xC7,0xE,0,0,0,0,0,0,0,0
$ gcc -c foo.S
$ gdb foo.o
(gdb) x/i 0
0x0: lock cmpxchg8b (%esi)
--
|
|
From: Tom H. <to...@co...> - 2005-08-19 12:47:43
|
In message <200...@gm...>
Dirk Mueller <dm...@gm...> wrote:
> On Friday 19 August 2005 05:53, Christian Parpart wrote:
>
>> I don't know wether this is easily achievable by RHEL/FC too. But this way
>> I tested my apps being 32bit compiled (on a 64bit host)
>
> Most serious Linux distributions allow usage of 32bit applications in the same
> system like 64bit applications, but for this valgrind needs to be compiled
> with 32 and 64 bit mode enabled. Thats currently impossible.
It's not impossible, just a little tricky ;-)
If you have a 32 bit machine available you can build on that which
gives you a 32 bit valgrind (in /usr/lib) then build on a 64 bit
machine which gives you a 64 bit valgrind (in /usr/lib64) then install
them both on a 64 bit machine, rename /usr/bin/valgrind from each to
something else and write a shell script to decide which one to start.
That's what I did for our local RPMs anyway. It isn't ideal though and
has certain problems so we do need a better solution.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Dirk M. <dm...@gm...> - 2005-08-19 11:54:41
|
On Friday 19 August 2005 05:53, Christian Parpart wrote: > I don't know wether this is easily achievable by RHEL/FC too. But this way > I tested my apps being 32bit compiled (on a 64bit host) Most serious Linux distributions allow usage of 32bit applications in the same system like 64bit applications, but for this valgrind needs to be compiled with 32 and 64 bit mode enabled. Thats currently impossible. Dirk |
|
From: Tom H. <to...@co...> - 2005-08-19 06:21:51
|
In message <200...@ge...>
Christian Parpart <tr...@ge...> wrote:
> Tom (or someone else who knows), when you read this, and know *HOW* to
> disassemble the binary instructions, just like the one above, please tell me
> so. I knew how to do with MS-DOS's debugger, but this is tooo long ago, nor
> available ;)
I do it by hand using appendix A of volume 3 of the AMD reference
manual, or the equivalent in volume 2 of the Intel reference manual.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Tom H. <to...@co...> - 2005-08-19 06:21:01
|
In message <58743620D2C0D9439C627C064581E252010C6B06@PA-ECLUSTER2.vmware.com> "Sree Oggu" <so...@vm...> wrote: > When I used this valgrind on a simple file (valgrind ls). it worked fine. But > when I tried to use it on our product (a MT server that loads shared > libraries using dlopen) it crashes with the following message. > > vex x86->IR: unhandled instruction bytes: 0xF0 0xF 0xC7 0xE > Process terminating with default action of signal 4 (SIGILL): dumping core That's a "mov Ez, Iz" instruction (with lock prefix). Please raise a bug for it so we can fix it for the next release. Tom -- Tom Hughes (to...@co...) http://www.compton.nu/ |
|
From: Yeshurun, M. <mei...@in...> - 2005-08-19 06:15:11
|
Hi, For me, the problem was resolved with Tom's help. He told me to increase the space between info.exe_base and info.exe_end in coregrind/stage1.c (which, with a non-PIE build, can be done by changing KICKSTART_BASE at configure time). I got the error as a result of loading large so's (happens more often when the so's contain debug info) Regards, Meir -----Original Message----- From: Nicholas Nethercote [mailto:nj...@cs...]=20 Sent: Thursday, August 18, 2005 7:48 PM To: Christoph Bartoschek; Yeshurun, Meir; prashantha a.s Cc: Valgrind Developers Subject: Valgrind: newSuperblock's request for N bytes failed Hi, Christoph, Meir and Prashantha all recently encountered Valgrind dying=20 with this message: VG_(get_memory_from_mmap): newSuperblock's request for N bytes failed. VG_(get_memory_from_mmap): M bytes already allocated. with various values for N and M. I've just committed some code to print more information when this happens.=20 If you three are still having this problem, can you try the latest code in=20 the repository (see http://www.valgrind.org/devel/cvs_svn.html) and send the results? That might make it more obvious what it happening. Thanks. Nick |
|
From: Christian P. <tr...@ge...> - 2005-08-19 03:13:24
|
On Friday 19 August 2005 02:01, Sree Oggu wrote: [...] > vex x86->IR: unhandled instruction bytes: 0xF0 0xF 0xC7 0xE > Process terminating with default action of signal 4 (SIGILL): dumping core If nothing went wrong withing your code, it then is an unimplemented=20 instruction. However, I don't even know what instruction that is, nor can I= =20 verify this (I'm just a valgrind user :-) > Is there a known work around for this ? In case it's really an unimplemented instruction, than just wait for 3.0.1,= or=20 if you can't wait, head up with the svn repository ASAP it's implemented in= =20 there (valgrind-dev mailinglist will tell you / or just svn log). Tom (or someone else who knows), when you read this, and know *HOW* to=20 disassemble the binary instructions, just like the one above, please tell m= e=20 so. I knew how to do with MS-DOS's debugger, but this is tooo long ago, nor= =20 available ;) Regards, Christian Parpart. =2D-=20 05:00:51 up 148 days, 18:08, 1 user, load average: 1.07, 0.72, 0.84 |
|
From: Christian P. <tr...@ge...> - 2005-08-19 03:13:22
|
On Thursday 18 August 2005 00:15, Victor Secarin wrote: [...] > =3D=3D=3D valgrind: wrong ELF executable class (eg. 32-bit instead of 64-= bit) > =3D=3D=3D valgrind: do_exec(linux/SeisX) failed: Exec format error > > Is there a command line flag for 32/64 ? > =3Dor=3D > Can I build and install two valgrinds on the same machine? What I did on my Opteron (in 64bit mode) bevore 3.0 became stable, was, to= =20 setup a 32bit chroot environment in /mnt/linux32, installing a linux in=20 there, and then invoking `linux32 /mnt/linux32/bin/sh` I don't know wether this is easily achievable by RHEL/FC too. But this way = I=20 tested my apps being 32bit compiled (on a 64bit host) Regards, Christian Parpart. =2D-=20 05:08:45 up 148 days, 18:16, 1 user, load average: 1.04, 1.15, 1.03 |
|
From: Sree O. <so...@vm...> - 2005-08-19 00:03:45
|
# Platform on which valgrind is built $ uname -a Linux soggu-bld.vmware.com 2.4.20-8smp #1 SMP Thu Mar 13 17:45:54 EST = 2003 i686 i686 i386 GNU/Linux # compiler version $ gcc -v Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.2.2/specs Configured with: ../configure --prefix=3D/usr --mandir=3D/usr/share/man --infodir=3D/usr/share/info --enable-shared --enable-threads=3Dposix --disable-checking --with-system-zlib --enable-__cxa_atexit --host=3Di386-redhat-linux Thread model: posix gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5) When I used this valgrind on a simple file (valgrind ls). it worked = fine. But when I tried to use it on our product (a MT server that loads shared libraries using dlopen) it crashes with the following message. vex x86->IR: unhandled instruction bytes: 0xF0 0xF 0xC7 0xE Process terminating with default action of signal 4 (SIGILL): dumping = core Is there a known work around for this ? Sree |