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: Julian S. <js...@ac...> - 2005-08-19 16:52:54
|
> I did try the release candidate 3.0 SVN as of 2005-07-27. In fact, I was > ambitious enough to attempt running all the glibc internal testcases under > memcheck. Alas, failure: http://bugs.kde.org/show_bug.cgi?id=109744 > "memcheck loses track of mmap from direct ld-linux.so.2". This was a > showstopper for a while. > > When the 3.0 release appeared just a few days later at the beginning of > August, I isolated the cause: http://bugs.kde.org/show_bug.cgi?id=110183 > "tail of page with _end[] is initialized, but not for memcheck". > I modified glibc to avoid the problem, which lead to more reports: > 110201 x86 'fxtract' opcode unhandled > 110202 x86 'waitpid' syscall unhandled > 110203 clock_getres(,0) does not store to 0 > 110204 strlen from fmemopen > 110205 sigcancel_handler fails > 110207 wrong answers from mpn ## user error [but ...] > 110208 wrong answer for failing execve > 110209 --show-emwarns vs default floating point fixups 110203 has already been fixed and will appear in 3.0.1. 110201 may get fixed for 3.0.1. 110205 is serious and investigations have already begun, but it is unclear how soon we can arrive at a fix. The rest are quite obscure and it is unlikely that they will affect more than a tiny number of users. If duplicates of them appear, then of course we will bump their priority. While we certainly appreciate advanced users who push Valgrind to the limit, like everyone else we have limited development resources and so we have to concentrate on making Valgrind work well for the 99% of the user base who are not "pushing the envelope". Sometimes that means that bugs get fixed in a different order than one might like. > I am glad to see progress in valgrind. I also expect better systemmatic > testing in the development process. It would be great to have a more thorough testing process. Since this is an open-source project, please feel free to enhance/extend the automatic test system and/or add more test cases. J |
|
From: Robert W. <rj...@du...> - 2005-08-19 16:46:12
|
> Aim higher. What? You mean, don't release the thing until it's completely done? Come on - that's just a stupid idea. Valgrind is a hobby for a lot of people, not a day job. It would never get released if we set such high standards. If you have a problem with the software, quit your belly-aching and fix it yourself. There will always be bugs. Get used to it. --=20 Robert Walsh Amalgamated Durables, Inc. - "We don't make the things you buy." Email: rj...@du... |
|
From: John R.
|
Julian Seward wrote: > We do have exacting users, they do communicate extensively with us > when stuff doesn't work, and we do our best to accommodate. What you > say doesn't square with the feedback we get. If we hadn't listened to > the needs of our users, Valgrind would have been a great deal less > successful than it has been. Aim higher. I have tried valgrind several times over the last 4 years, and the result of each trial has been, "memcheck cannot handle my code." The outstanding example is memcheck cannot run the internal testcases of glibc. Complete coverage of i686 user-mode opcodes also matters to me. Both of these areas have readily-available specifications. The manual and/or release notes for valgrind should list the failing cases. -- |
|
From: John R.
|
> We did put out a release candidate which you could have tried if you > had wanted, and we plan to release a 3.0.1 fairly soon to address some > of the issues (including those you have raised) in the 3.0.0 release. I did try the release candidate 3.0 SVN as of 2005-07-27. In fact, I was ambitious enough to attempt running all the glibc internal testcases under memcheck. Alas, failure: http://bugs.kde.org/show_bug.cgi?id=109744 "memcheck loses track of mmap from direct ld-linux.so.2". This was a showstopper for a while. When the 3.0 release appeared just a few days later at the beginning of August, I isolated the cause: http://bugs.kde.org/show_bug.cgi?id=110183 "tail of page with _end[] is initialized, but not for memcheck". I modified glibc to avoid the problem, which lead to more reports: 110201 x86 'fxtract' opcode unhandled 110202 x86 'waitpid' syscall unhandled 110203 clock_getres(,0) does not store to 0 110204 strlen from fmemopen 110205 sigcancel_handler fails 110207 wrong answers from mpn ## user error [but ...] 110208 wrong answer for failing execve 110209 --show-emwarns vs default floating point fixups I am glad to see progress in valgrind. I also expect better systemmatic testing in the development process. -- |
|
From: Julian S. <js...@ac...> - 2005-08-19 15:44:08
|
> reflects poorly on the development process for Valgrind. It's part > of a vicious circle: valgrind has not fully supported some features > (floating point, threads, mutual exclusion) needed by exacting users, > so those users tend to stay away, so valgrind gets less feedback > from those users. Maybe Valgrind 3.1 will "just work" :-) We do have exacting users, they do communicate extensively with us when stuff doesn't work, and we do our best to accommodate. What you say doesn't square with the feedback we get. If we hadn't listened to the needs of our users, Valgrind would have been a great deal less successful than it has been. J |
|
From: John R.
|
Rob Holland wrote: > Can't be that fundamental if it's only just cropped up, imho. Go back to school and learn about mutual exclusion. cmpxchg8b appears in glibc-2.3.x/sysdeps/i386/i486/bits/atomic.h . The "just cropped up" reflects poorly on the development process for Valgrind. It's part of a vicious circle: valgrind has not fully supported some features (floating point, threads, mutual exclusion) needed by exacting users, so those users tend to stay away, so valgrind gets less feedback from those users. Maybe Valgrind 3.1 will "just work" :-) -- |
|
From: Daniel V. <vei...@re...> - 2005-08-19 14:50:35
|
On Fri, Aug 19, 2005 at 07:10:02AM -0700, John Reiser wrote: > >>Vex is just going to have to learn it, or else quit pretending to > >>support threads. > > > > > > I would refer you to bugs 109313 and 110505 where the lack of this > > instruction was previously reported and SVN revisions 1331 and 1337 > > where it was fixed. > > It is exceedingly reasonable to expect a product with version number 3.0 > to support *fundamental* operations. Valgrind disappoints. Don't let a temporary frustration blinds you, this is part of the model "Release early, release often", the mantra still holds, and hitting new bugs in a .0 release after a rewrite is to be expected. What would be serious would be if bugs were not fixed, and as it was pointed out fixes are there already, which to me is a clear proof that there is nothing to be disapointed with ! At worse rollback to the previous release and wait for the new one which you can expect shortly precisely because the model is to release often. Daniel -- Daniel Veillard | Red Hat Desktop team http://redhat.com/ vei...@re... | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ |
|
From: Tom H. <to...@co...> - 2005-08-19 14:39:04
|
In message <4305E83A.3070609@BitWagon.com>
John Reiser <jreiser@BitWagon.com> wrote:
>>>Vex is just going to have to learn it, or else quit pretending to
>>>support threads.
>>
>>
>> I would refer you to bugs 109313 and 110505 where the lack of this
>> instruction was previously reported and SVN revisions 1331 and 1337
>> where it was fixed.
>
> It is exceedingly reasonable to expect a product with version number 3.0
> to support *fundamental* operations. Valgrind disappoints.
You can expect a lot of things, but when you're using free software
I'm afraid you're going to get what you pay for.
As I'm sure you're aware version 3.0 includes a complete rewrite of
the core translation engine so it's hardly surprising if there was a
small backwards step in terms of instruction support.
I can say that many people ran large amounts of code using the new
engine before it was released but yes, a number of instructions are
missing and sometimes a compiler on a different system or compiling
some different code manages to use one.
We did put out a release candidate which you could have tried if you
had wanted, and we plan to release a 3.0.1 fairly soon to address some
of the issues (including those you have raised) in the 3.0.0 release.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Rob H. <ti...@ge...> - 2005-08-19 14:25:30
|
On Fri, 2005-08-19 at 07:10 -0700, John Reiser wrote: > It is exceedingly reasonable to expect a product with version number 3.0 > to support *fundamental* operations. Valgrind disappoints. So use something else (and if there is nothing else, consider why that might be). Can't be that fundamental if it's only just cropped up, imho. --=20 |
|
From: Tom H. <to...@co...> - 2005-08-19 14:19:14
|
In message <200...@gm...>
Dirk Mueller <dm...@gm...> wrote:
> On Friday 19 August 2005 14:46, Tom Hughes wrote:
>
>> 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.
>
> Yeah, once again we're back to a valgrind shell wrapper ;)
It's not a proper solution though, as you can't exec 32 bit
from 64 bit and vice versa to start with.
> so the valgrind binary itself should move to libdir as well. I don't see any
> other solution right now.
I actually moved it to $libdir/stage1 ;-)
I think we can do better in the long term base don the work Julian has
been doing on the address space branch and having a simple binary
loader that decides which combined stage2/tool binary to load.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: John R.
|
>>Vex is just going to have to learn it, or else quit pretending to >>support threads. > > > I would refer you to bugs 109313 and 110505 where the lack of this > instruction was previously reported and SVN revisions 1331 and 1337 > where it was fixed. It is exceedingly reasonable to expect a product with version number 3.0 to support *fundamental* operations. Valgrind disappoints. -- |
|
From: Dirk M. <dm...@gm...> - 2005-08-19 13:48:24
|
On Friday 19 August 2005 14:46, Tom Hughes wrote: > 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. Yeah, once again we're back to a valgrind shell wrapper ;) so the valgrind binary itself should move to libdir as well. I don't see any other solution right now. Dirk |
|
From: Tom H. <to...@co...> - 2005-08-19 13:38:41
|
In message <4305DCB2.2040003@BitWagon.com>
John Reiser <jreiser@BitWagon.com> wrote:
>>>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.
I know what 0xF means thanks. I just managed to get confused and read
the wrong table when I was decoding that instruction.
> Vex is just going to have to learn it, or else quit pretending to
> support threads.
I would refer you to bugs 109313 and 110505 where the lack of this
instruction was previously reported and SVN revisions 1331 and 1337
where it was fixed.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Michael S. <mlr...@gm...> - 2005-08-19 13:33:15
|
On 8/19/05, John Reiser <jr...@bi...> wrote: > >>vex x86->IR: unhandled instruction bytes: 0xF0 0xF 0xC7 0xE > >>Process terminating with default action of signal 4 (SIGILL): dumping c= ore > > > > > > 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. >=20 > 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. Julian implemented it last weekend, following a couple of bug reports from people (including me) hitting this. So I guess it'll be in the next release; it's been backported (r1337) into the 3.0 branch. Mike |
|
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 |
|
From: Rob H. <ti...@ge...> - 2005-08-18 23:03:18
|
On Thu, 2005-08-18 at 23:26 +0100, Rob Holland wrote: > It does work :) Or not.... The source is at: http://dev.gentoo.org/~tigger/formatcheck.tar.bz2 in case anyone has any ideas. I can't see what's up unless it's the second libc load that's annoying cli_malloc in some way. It's the VG_(cli_malloc) in fc_main.c:new_block() that's causing the segfault. =3D=3D27492=3D=3D formatcheck, format string check. =3D=3D27492=3D=3D Copyright (C) 2005, and GNU GPL'd, by Rob Holland. =3D=3D27492=3D=3D Using LibVEX rev 1338, a library for dynamic binary translation. =3D=3D27492=3D=3D Copyright (C) 2004-2005, and GNU GPL'd, by OpenWorks LLP. =3D=3D27492=3D=3D Using valgrind-3.1.SVN, a dynamic binary instrumentation framework. =3D=3D27492=3D=3D Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward = et al. =3D=3D27492=3D=3D For more details, rerun with: -v =3D=3D27492=3D=3D=20 =3D=3D27492=3D=3D Format string is not a literal (appears to be from heap):= '%d' =3D=3D27492=3D=3D at 0x2571B8BE: sprintf (fc_replace_format_functions.c:= 135) =3D=3D27492=3D=3D by 0x25978FE7: tparm (in /lib64/libncurses.so.5.4) =3D=3D27492=3D=3D by 0x402FA9: capsmk (top.c:523) =3D=3D27492=3D=3D by 0x408065: main (top.c:2395) =3D=3D27492=3D=3D=20 =3D=3D27492=3D=3D Format string is not a literal (appears to be from heap):= '%d' =3D=3D27492=3D=3D at 0x2571B8BE: sprintf (fc_replace_format_functions.c:= 135) =3D=3D27492=3D=3D by 0x25978FE7: tparm (in /lib64/libncurses.so.5.4) =3D=3D27492=3D=3D by 0x402FA9: capsmk (top.c:523) =3D=3D27492=3D=3D by 0x408065: main (top.c:2395) --27492-- INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV) - exiting --27492-- si_code=3D1; Faulting address: 0x4BB82F10; sp: 0x7015CDD0 valgrind: the 'impossible' happened: Killed by fatal signal =3D=3D27492=3D=3D at 0x70023B18: ??? sched status: running_tid=3D1 Thread 1: status =3D VgTs_Runnable =3D=3D27492=3D=3D at 0x25719B86: malloc (vg_replace_malloc.c:149) =3D=3D27492=3D=3D by 0x25507EF4: _dl_new_object (in /lib64/ld-2.3.5.so) =3D=3D27492=3D=3D by 0x255047B9: _dl_map_object_from_fd (in /lib64/ld-2.3.5.so) =3D=3D27492=3D=3D by 0x25505FAE: _dl_map_object (in /lib64/ld-2.3.5.so) =3D=3D27492=3D=3D by 0x25508FFC: openaux (in /lib64/ld-2.3.5.so) =3D=3D27492=3D=3D by 0x2550A46F: _dl_catch_error (in /lib64/ld-2.3.5.so) =3D=3D27492=3D=3D by 0x255092F1: _dl_map_object_deps (in /lib64/ld-2.3.5= .so) =3D=3D27492=3D=3D by 0x25B7C382: (within /lib64/tls/libc-2.3.5.so) =3D=3D27492=3D=3D by 0x2550A46F: _dl_catch_error (in /lib64/ld-2.3.5.so) =3D=3D27492=3D=3D by 0x25B7CB99: _dl_open (in /lib64/tls/libc-2.3.5.so) =3D=3D27492=3D=3D by 0x25B7DF37: (within /lib64/tls/libc-2.3.5.so) =3D=3D27492=3D=3D by 0x2550A46F: _dl_catch_error (in /lib64/ld-2.3.5.so) =3D=3D27492=3D=3D by 0x25B7DEFA: (within /lib64/tls/libc-2.3.5.so) =3D=3D27492=3D=3D by 0x25B7DFC7: __libc_dlopen_mode (in /lib64/tls/libc-2.3.5.so) =3D=3D27492=3D=3D by 0x25B5BA5A: __nss_lookup_function (in /lib64/tls/libc-2.3.5.so) =3D=3D27492=3D=3D by 0x25B5BB53: (within /lib64/tls/libc-2.3.5.so) =3D=3D27492=3D=3D by 0x25B225A0: getpwuid_r (in /lib64/tls/libc-2.3.5.so= ) =3D=3D27492=3D=3D by 0x25B21E6C: getpwuid (in /lib64/tls/libc-2.3.5.so) =3D=3D27492=3D=3D by 0x2582FAD6: user_from_uid (pwcache.c:42) =3D=3D27492=3D=3D by 0x25830960: simple_readproc (readproc.c:531) =3D=3D27492=3D=3D by 0x25831025: readproc (readproc.c:743) =3D=3D27492=3D=3D by 0x403DD8: procs_refresh (top.c:1107) =3D=3D27492=3D=3D by 0x406CE9: frame_make (top.c:2848) =3D=3D27492=3D=3D by 0x40811F: main (top.c:3259) 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: www.valgrind.org In the bug report, send all the above text, the valgrind version, and what Linux distro you are using. Thanks. --=20 |