|
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: 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: 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: 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: Christian P. <tr...@ge...> - 2005-08-19 22:55:11
|
On Friday 19 August 2005 15:15, John Reiser wrote: > > please tell me *HOW* to disassemble instructions > > (gdb) x/i <address> # see "help data": x/FMT ADDR 'i'=3D=3D>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) Yeah, that's what I have been looking for. Thx. (As I don't seem to get the specs somehow) Regards, Christian Parpart. =2D-=20 00:53:40 up 149 days, 14:01, 5 users, load average: 0.48, 0.37, 0.34 |
|
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: 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: 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: 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: 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: 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: Andy <val...@th...> - 2005-08-20 02:51:57
|
On Fri, 2005-08-19 at 07:10 -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. Maybe the Valgrind developers would consider using a non-floating point versioning scheme, which wouldn't lead to people implying the maturity of the software. Valgrind 95, Valgrind ME, Valgrind XP. Dates are popular, but developers have a nasty habit of specifying dates to 14 significant digits, being of the "release often" school. Valgrind-20050819214835 is hard to say. Although "Valgrind 2003 Datacenter Edition" has a nice ring to it. -- Andy <val...@th...> |
|
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: 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: 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.
|
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: 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: Tom S. <to...@pl...> - 2005-08-19 18:48:59
|
On Fri, 2005-08-19 at 09:25 -0700, John Reiser wrote: > 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. I have run valgrind on a weekly basis over the last 3 years, and the result of each run has been the finding of memory leaks and bugs in my code. Only occasionaly has valgrind not been able to handle my code. By releasing this "incomplete" tool to me, the valgrind developers have saved me countless days of debugging time. Thank you valgrind developers! -- Tom Schutter (mailto:to...@pl...) Platte River Associates, Inc. (http://www.platte.com) |
|
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: 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 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: Madhu M K. <mm...@ya...> - 2005-08-20 16:17:14
|
Folks, To reiterate what other users have been saying, valgrind since the early yyyymmdd.tar.bz2 releases has been a tremendous resource for me. When I have come across issues, they have either been fixed soon or since I had access to code, I was able to develop functionality for them (re: automatic generation of suppressions into a file). I am very grateful to all of you for your time and effort. > 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. While some of the email on this thread has been pretty inflammatory and one is tempted to talk about expectations from open source, the $$ one pays for using valgrind, the presumption involved in "fundamental" operations and silly ad hominem comments about school, but I digress. I'd like to bring to the discussion this article: http://www.jwz.org/doc/worse-is-better.html "Completeness-the design must cover as many important situations as is practical. All reasonably expected cases should be covered. Completeness can be sacrificed in favor of any other quality. In fact, completeness must sacrificed whenever implementation simplicity is jeopardized. Consistency can be sacrificed to achieve completeness if simplicity is retained; especially worthless is consistency of interface." Cheerio, M Madhu M Kurup /* Nemo Me Impune Lacessit */ mmk at yahoo-inc dt com |
|
From: Nicholas N. <nj...@cs...> - 2005-08-23 15:50:46
|
On Fri, 19 Aug 2005, John Reiser wrote: > Complete coverage of i686 user-mode opcodes also matters to me. Why? Nick |
|
From: John R.
|
>> Complete coverage of i686 user-mode opcodes also matters to me. > Why? Because I have my own compilers. Also, even when clients use gcc, I could then recommend valgrind without having to add the caveat, "you might see some unhandled instruction bytes, which means that progress stops for some time while either valgrind adjusts its code or you adjust yours." And it's hard when the offending opcode is in glibc, such as 'fxtract' for *logb(). -- |
|
From: Christian P. <tr...@ge...> - 2005-08-23 19:43:32
|
On Tuesday 23 August 2005 20:20, John Reiser wrote: > >> Complete coverage of i686 user-mode opcodes also matters to me. > > > > Why? > > Because I have my own compilers.=20 Huh? you've your *own* compilerS? interesting? Any way to look at them? I'm= =20 curious :D Regards, Christian Parpart. |