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
(25) |
2
(24) |
3
(6) |
4
(2) |
5
(4) |
|
6
(5) |
7
(19) |
8
(18) |
9
(7) |
10
(13) |
11
(6) |
12
(8) |
|
13
(4) |
14
(5) |
15
(8) |
16
(4) |
17
(2) |
18
(2) |
19
(6) |
|
20
(14) |
21
(6) |
22
(20) |
23
(13) |
24
(3) |
25
(5) |
26
|
|
27
(4) |
28
(7) |
29
(14) |
30
(6) |
|
|
|
|
From: Tom H. <to...@co...> - 2005-11-02 12:43:53
|
In message <113...@ok...>
Alex Bennee <ker...@be...> wrote:
> I seem to of tripped up an unimplemented bit of the amd64 virtual
> machine:
>
> vex amd64->IR: 0x4 unhandled instruction bytes: 0x67 0x8B 0x8 0x8B
> ==24865==
> ==24865== Process terminating with default action of signal 4 (SIGILL):
> dumping core
> ==24865== Illegal opcode at address 0x118F749644
> ==24865== at 0x118F749644: ???
> <snip>
> Attaching to program: /proc/24870/fd/1015, process 24870
> 0x000000118f749644 in ?? ()
> (gdb) x/i $pc
> 0x118f749644: addr32 mov (%eax),%ecx
That's an address size override prefix which doesn't seem to be
supported at the moment - can you raise a bug for this please.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Tom H. <to...@co...> - 2005-11-02 12:40:11
|
In message <yek...@de...>
Tom Hughes <to...@co...> wrote:
> In message <113...@ok...>
> Alex Bennee <ker...@be...> wrote:
>
>> Thanks. That worked and it moved forward. Unfortunately we set up the fs
>> segment selector to point at the entry. This doesn't seem to be
>> correctly setup under valgrind:
>>
>> setFS(0x3ef)
>
> What instruction(s) is this routine using to set %fs?
>
> It should work - although I think the x86 glibc uses %gs so that
> is probably more thoroughly tested.
>
> You could try setting verboze to True in x86g_use_seg_selector
> in VEX/priv/guest-x86/ghelpers.c and see what it says - that should
> report the segment translations that it does.
One other thing that just occurred to me - make sure you have
done a make in the VEX directory as doing a make at the top level
doesn't always manage to rebuild VEX correctly.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Tom H. <to...@co...> - 2005-11-02 12:36:29
|
In message <113...@ok...>
Alex Bennee <ker...@be...> wrote:
> On Wed, 2005-11-02 at 11:20 +0000, Tom Hughes wrote:
>> In message <113...@ok...>
>> Alex Bennee <ker...@be...> wrote:
>>
>> > I'm trying to run Valgrind across an x86 app that uses the modify_ldt
>> > syscall which seems to get in the way of Valgrind.
>> > <snip>
>>
>> It's not that it is used by valgrind, it is virtualised by valgrind
>> because it needs to alter the LDT for the virtual CPU that your code
>> is running on.
>>
>> <snip>
>>
>> Changing VEX_GUEST_X86_LDT_NENT in VEX/pub/libvex_guest_x86.h to
>> a larger number (8192 to get the full LDT) should allow your code
>> to work I think.
>
> Thanks. That worked and it moved forward. Unfortunately we set up the fs
> segment selector to point at the entry. This doesn't seem to be
> correctly setup under valgrind:
>
> setFS(0x3ef)
What instruction(s) is this routine using to set %fs?
It should work - although I think the x86 glibc uses %gs so that
is probably more thoroughly tested.
You could try setting verboze to True in x86g_use_seg_selector
in VEX/priv/guest-x86/ghelpers.c and see what it says - that should
report the segment translations that it does.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Alex B. <ker...@be...> - 2005-11-02 12:25:25
|
Hi, I seem to of tripped up an unimplemented bit of the amd64 virtual machine: vex amd64->IR: 0x4 unhandled instruction bytes: 0x67 0x8B 0x8 0x8B ==24865== ==24865== Process terminating with default action of signal 4 (SIGILL): dumping core ==24865== Illegal opcode at address 0x118F749644 ==24865== at 0x118F749644: ??? <snip> Attaching to program: /proc/24870/fd/1015, process 24870 0x000000118f749644 in ?? () (gdb) x/i $pc 0x118f749644: addr32 mov (%eax),%ecx I tried the latest SVN build which didn't seem to of changed much in the vex amd64->IR code unfortunately it doesn't even get this far failing to mmap memory. -- Alex, homepage: http://www.bennee.com/~alex/ "To vacillate or not to vacillate, that is the question ... or is it?" |
|
From: Alex B. <ker...@be...> - 2005-11-02 12:20:16
|
On Wed, 2005-11-02 at 11:20 +0000, Tom Hughes wrote: > In message <113...@ok...> > Alex Bennee <ker...@be...> wrote: > > > I'm trying to run Valgrind across an x86 app that uses the modify_ldt > > syscall which seems to get in the way of Valgrind. > > <snip> > > It's not that it is used by valgrind, it is virtualised by valgrind > because it needs to alter the LDT for the virtual CPU that your code > is running on. > > <snip> > > Changing VEX_GUEST_X86_LDT_NENT in VEX/pub/libvex_guest_x86.h to > a larger number (8192 to get the full LDT) should allow your code > to work I think. Thanks. That worked and it moved forward. Unfortunately we set up the fs segment selector to point at the entry. This doesn't seem to be correctly setup under valgrind: setFS(0x3ef) checkFs(0x427ae40) ==14078== ==14078== Process terminating with default action of signal 11 (SIGSEGV): dumping core ==14078== General Protection Fault ==14078== at 0x3808BA9D: peekFs(int) (SegmentSelector.cc:88) <snip> ==14078== starting debugger with cmd: /usr/bin/gdb <snip> 0x3808ba9d in peekFs (offset=0) at SegmentSelector.cc:88 88 __asm__ volatile( (gdb) p $fs $1 = -1342177280 (gdb) p/x $2 = 0xb0000000 Vs running direct under gdb: <snip> Breakpoint 1, peekFs (offset=0) at SegmentSelector.cc:88 88 __asm__ volatile( (gdb) p $fs $1 = 1007 > > Tom -- Alex, homepage: http://www.bennee.com/~alex/ BE ALERT!!!! (The world needs more lerts ...) |
|
From: Tom H. <to...@co...> - 2005-11-02 11:20:17
|
In message <113...@ok...>
Alex Bennee <ker...@be...> wrote:
> I'm trying to run Valgrind across an x86 app that uses the modify_ldt
> syscall which seems to get in the way of Valgrind. I has a look though
> the svn sources and I can see the test case for modify_ldt is commented
> out and has a note that it is used by Valgrind itself. Running outside
> Valgrind gives:
It's not that it is used by valgrind, it is virtualised by valgrind
because it needs to alter the LDT for the virtual CPU that your code
is running on.
> ldt_entry.entry_number = 125
> ldt_entry.base_addr = 427ae40
> ldt_entry.limit = 9944
> ldt_entry.seg_32bit = 1
> ldt_entry.contents = 0
> ldt_entry.read_exec_only = 0
> ldt_entry.limit_in_pages = 0
> ldt_entry.seg_not_present= 0
> ldt_entry.useable = 1
> modify_ldt = -1
> FATAL ERROR: User segment selector installation failed.
> Are user selectors enabled?
>
> I'm assuming the move in base_addr is because memory has been moved
> about a bit. I've tried with both the formal 3.0.1 and the SVN sources.
> Is my attempt to Valgrind this app doomed because of use of the
> modify_ldt?
The problem is that valgrind 3 currently only emulates the
first 64 entries of the LDT because that is all that the thread
local storage stuff in glibc normally uses.
In fact valgrind 2.4 emulates the entire LDT so your code should
work there.
Changing VEX_GUEST_X86_LDT_NENT in VEX/pub/libvex_guest_x86.h to
a larger number (8192 to get the full LDT) should allow your code
to work I think.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Alex B. <ker...@be...> - 2005-11-02 11:07:02
|
Hi, I'm trying to run Valgrind across an x86 app that uses the modify_ldt syscall which seems to get in the way of Valgrind. I has a look though the svn sources and I can see the test case for modify_ldt is commented out and has a note that it is used by Valgrind itself. Running outside Valgrind gives: $: ./mytestprog ldt_entry.entry_number = 125 ldt_entry.base_addr = 3821ec00 ldt_entry.limit = 9944 ldt_entry.seg_32bit = 1 ldt_entry.contents = 0 ldt_entry.read_exec_only = 0 ldt_entry.limit_in_pages = 0 ldt_entry.seg_not_present= 0 ldt_entry.useable = 1 modify_ldt = 0 setFS(1007) libc_nbtest: starting <snip> Whereas under Valgrind: $ /usr/local/bin/valgrind --tool=memcheck ./mytestprog ==9588== Memcheck, a memory error detector. ==9588== Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et al. ==9588== Using LibVEX rev 1426, a library for dynamic binary translation. ==9588== Copyright (C) 2004-2005, and GNU GPL'd, by OpenWorks LLP. ==9588== Using valgrind-3.1.SVN, a dynamic binary instrumentation framework. ==9588== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et al. ==9588== For more details, rerun with: -v ==9588== ldt_entry.entry_number = 125 ldt_entry.base_addr = 427ae40 ldt_entry.limit = 9944 ldt_entry.seg_32bit = 1 ldt_entry.contents = 0 ldt_entry.read_exec_only = 0 ldt_entry.limit_in_pages = 0 ldt_entry.seg_not_present= 0 ldt_entry.useable = 1 modify_ldt = -1 FATAL ERROR: User segment selector installation failed. Are user selectors enabled? I'm assuming the move in base_addr is because memory has been moved about a bit. I've tried with both the formal 3.0.1 and the SVN sources. Is my attempt to Valgrind this app doomed because of use of the modify_ldt? -- Alex, homepage: http://www.bennee.com/~alex/ You might have mail |
|
From: John R.
|
> The executable was compiled on/for 32-bit x86, but we actually generate this > instruction directly. We generate quite a few such NOP instructions. I am a > little confused why would valgrind ever work then. Does the next instruction > matter here? In this case NOP is followed by a "call" instrcution (0xE8). No, the next instruction (CALL in this case) does not matter. 66 66 90 is a NOP that takes the CPU 3 cycles to decode the first time (one cycle for each 66 prefix plus one cycle for the NOP) but at most 1 cycle to execute, and perhaps 0 cycles to execute on some processors. Thus it is useful after an executed JMP in order to force the decoder to slow down (some decoders don't "understand" the full meaning of unconditional JMP: the meaning is enforced by the execution unit), which saves power in contrast to what is required to decode "meaningful" instructions. Because it requires only one cycle to execute but 3 bytes to express, it may be faster than NOP NOP NOP (which might take 3 cycles to execute) while still providing alignment padding for the following instruction of a fall-through sequence. If the target of a branch is 8-byte aligned (or even cache-line aligned), then decoder efficiency often improves. The decoder only fetches 8 bytes (or whole cache lines) at a time from the icache, and must discard those bytes which preceed a branch target. -- |
|
From: Hui <hu...@me...> - 2005-11-02 02:11:56
|
John Reiser <jreiser <at> BitWagon.com> writes: > > > ... however 66 66 90 is a pretty strange sequence. 66 is the > > operand size override and 90 is nop, so you have a 3-byte useless > > instruction. > > It was compiled on/for x86_64, where 66 66 90 is a NOP that stalls the > look-ahead instruction decoder. This is used as alignment filler after > an unconditional JMP, in order to save internal CPU resources and power. > It happens to run on most 32-bit x86, too. > The executable was compiled on/for 32-bit x86, but we actually generate this instruction directly. We generate quite a few such NOP instructions. I am a little confused why would valgrind ever work then. Does the next instruction matter here? In this case NOP is followed by a "call" instrcution (0xE8). Thanks, --Hui |
|
From: Administrator <Adm...@pa...> - 2005-11-01 23:26:36
|
V2FybmluZzogQXR0YWNobWVudCBjb250YWlucyB2aXJ1cyBjb2RlIG9yIG1lZXRzIHRoZSBmaWx0 ZXJpbmcvYmxvY2tpbmcgcnVsZXMuICBVc2UgY2F1dGlvbiB3aGVuIGFjY2Vzc2luZyB0aGUgY29u dGVudHMuIA0KDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIEhlYWRlciAtLS0tLQ0KU3ViamVjdDog UmU6IFtWYWxncmluZC11c2Vyc10gVW5zdXBwb3J0ZWQgY2xvbmUoKSBmbGFncw0KRnJvbTogdmFs Z3JpbmQtdXNlcnMtYWRtaW5AbGlzdHMuc291cmNlZm9yZ2UubmV0DQpUbzoganNld2FyZEBhY20u b3JnDQpDYzogdmFsZ3JpbmQtdXNlcnNAbGlzdHMuc291cmNlZm9yZ2UubmV0DQotLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K |
|
From: Administrator <Adm...@pa...> - 2005-11-01 23:26:19
|
V2FybmluZzogQXR0YWNobWVudCBjb250YWlucyB2aXJ1cyBjb2RlIG9yIG1lZXRzIHRoZSBmaWx0 ZXJpbmcvYmxvY2tpbmcgcnVsZXMuICBVc2UgY2F1dGlvbiB3aGVuIGFjY2Vzc2luZyB0aGUgY29u dGVudHMuIA0KDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIEhlYWRlciAtLS0tLQ0KU3ViamVjdDog UmU6IFtWYWxncmluZC11c2Vyc10gVW5zdXBwb3J0ZWQgY2xvbmUoKSBmbGFncw0KRnJvbTogdmFs Z3JpbmQtdXNlcnMtYWRtaW5AbGlzdHMuc291cmNlZm9yZ2UubmV0DQpUbzogdmFsZ3JpbmQtdXNl cnNAbGlzdHMuc291cmNlZm9yZ2UubmV0DQpDYzogDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0K |
|
From: Administrator <Adm...@pa...> - 2005-11-01 23:25:22
|
V2FybmluZzogQXR0YWNobWVudCBjb250YWlucyB2aXJ1cyBjb2RlIG9yIG1lZXRzIHRoZSBmaWx0 ZXJpbmcvYmxvY2tpbmcgcnVsZXMuICBVc2UgY2F1dGlvbiB3aGVuIGFjY2Vzc2luZyB0aGUgY29u dGVudHMuIA0KDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIEhlYWRlciAtLS0tLQ0KU3ViamVjdDog UmU6IFtWYWxncmluZC11c2Vyc10gVW5zdXBwb3J0ZWQgY2xvbmUoKSBmbGFncw0KRnJvbTogdmFs Z3JpbmQtdXNlcnMtYWRtaW5AbGlzdHMuc291cmNlZm9yZ2UubmV0DQpUbzogdmFsZ3JpbmQtdXNl cnNAbGlzdHMuc291cmNlZm9yZ2UubmV0DQpDYzogDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0K |
|
From: Administrator <Adm...@pa...> - 2005-11-01 23:25:02
|
V2FybmluZzogQXR0YWNobWVudCBjb250YWlucyB2aXJ1cyBjb2RlIG9yIG1lZXRzIHRoZSBmaWx0 ZXJpbmcvYmxvY2tpbmcgcnVsZXMuICBVc2UgY2F1dGlvbiB3aGVuIGFjY2Vzc2luZyB0aGUgY29u dGVudHMuIA0KDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIEhlYWRlciAtLS0tLQ0KU3ViamVjdDog W1ZhbGdyaW5kLXVzZXJzXSB1bmhhbmRsZWQgaW5zdHJ1Y3Rpb24gYnl0ZXM6IDB4NjYgMHhGIDB4 MTEgMHg0NyAob3B0ZXJvbikNCkZyb206IHZhbGdyaW5kLXVzZXJzLWFkbWluQGxpc3RzLnNvdXJj ZWZvcmdlLm5ldA0KVG86IHZhbGdyaW5kLXVzZXJzQGxpc3RzLnNvdXJjZWZvcmdlLm5ldA0KQ2M6 IA0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg== |
|
From: Administrator <Adm...@pa...> - 2005-11-01 23:23:43
|
V2FybmluZzogQXR0YWNobWVudCBjb250YWlucyB2aXJ1cyBjb2RlIG9yIG1lZXRzIHRoZSBmaWx0 ZXJpbmcvYmxvY2tpbmcgcnVsZXMuICBVc2UgY2F1dGlvbiB3aGVuIGFjY2Vzc2luZyB0aGUgY29u dGVudHMuIA0KDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIEhlYWRlciAtLS0tLQ0KU3ViamVjdDog UmU6IFtWYWxncmluZC11c2Vyc10gdW5oYW5kbGVkIGluc3RydWN0aW9uIGJ5dGVzOiAweDY2IDB4 RiAweDExIDB4NDcgKG9wdGVyb24pDQpGcm9tOiB2YWxncmluZC11c2Vycy1hZG1pbkBsaXN0cy5z b3VyY2Vmb3JnZS5uZXQNClRvOiB2YWxncmluZC11c2Vyc0BsaXN0cy5zb3VyY2Vmb3JnZS5uZXQN CkNjOiANCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo= |
|
From: Administrator <Adm...@pa...> - 2005-11-01 23:23:40
|
V2FybmluZzogQXR0YWNobWVudCBjb250YWlucyB2aXJ1cyBjb2RlIG9yIG1lZXRzIHRoZSBmaWx0 ZXJpbmcvYmxvY2tpbmcgcnVsZXMuICBVc2UgY2F1dGlvbiB3aGVuIGFjY2Vzc2luZyB0aGUgY29u dGVudHMuIA0KDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIEhlYWRlciAtLS0tLQ0KU3ViamVjdDog UmU6IFtWYWxncmluZC11c2Vyc10gdW5oYW5kbGVkIGluc3RydWN0aW9uIGJ5dGVzOiAweDY2IDB4 RiAweDExIDB4NDcgKG9wdGVyb24pDQpGcm9tOiB2YWxncmluZC11c2Vycy1hZG1pbkBsaXN0cy5z b3VyY2Vmb3JnZS5uZXQNClRvOiB2YWxncmluZC11c2Vyc0BsaXN0cy5zb3VyY2Vmb3JnZS5uZXQN CkNjOiBhc2hsZXlAcXVhZHJpY3MuY29tOyBydW5lLnNhbmR2aWtAbW9zZWsuY29tDQotLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K |
|
From: Administrator <Adm...@pa...> - 2005-11-01 23:22:06
|
V2FybmluZzogQXR0YWNobWVudCBjb250YWlucyB2aXJ1cyBjb2RlIG9yIG1lZXRzIHRoZSBmaWx0 ZXJpbmcvYmxvY2tpbmcgcnVsZXMuICBVc2UgY2F1dGlvbiB3aGVuIGFjY2Vzc2luZyB0aGUgY29u dGVudHMuIA0KDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIEhlYWRlciAtLS0tLQ0KU3ViamVjdDog UmU6IFtWYWxncmluZC11c2Vyc10gdmV4IHg4Ni0+SVI6IHVuaGFuZGxlZCBpbnN0cnVjdGlvbiBi eXRlczogMHg2NiAweDY2IDB4OTAgMHhFOA0KRnJvbTogdmFsZ3JpbmQtdXNlcnMtYWRtaW5AbGlz dHMuc291cmNlZm9yZ2UubmV0DQpUbzogdmFsZ3JpbmQtdXNlcnNAbGlzdHMuc291cmNlZm9yZ2Uu bmV0DQpDYzogDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K |
|
From: Administrator <Adm...@pa...> - 2005-11-01 23:21:57
|
V2FybmluZzogQXR0YWNobWVudCBjb250YWlucyB2aXJ1cyBjb2RlIG9yIG1lZXRzIHRoZSBmaWx0 ZXJpbmcvYmxvY2tpbmcgcnVsZXMuICBVc2UgY2F1dGlvbiB3aGVuIGFjY2Vzc2luZyB0aGUgY29u dGVudHMuIA0KDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIEhlYWRlciAtLS0tLQ0KU3ViamVjdDog UmU6IFtWYWxncmluZC11c2Vyc10gdmV4IHg4Ni0+SVI6IHVuaGFuZGxlZCBpbnN0cnVjdGlvbiBi eXRlczogMHg2NiAweDY2IDB4OTAgMHhFOA0KRnJvbTogdmFsZ3JpbmQtdXNlcnMtYWRtaW5AbGlz dHMuc291cmNlZm9yZ2UubmV0DQpUbzogdmFsZ3JpbmQtdXNlcnNAbGlzdHMuc291cmNlZm9yZ2Uu bmV0DQpDYzogdG9tQGNvbXB0b24ubnUNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQo= |
|
From: Administrator <Adm...@pa...> - 2005-11-01 23:21:51
|
V2FybmluZzogQXR0YWNobWVudCBjb250YWlucyB2aXJ1cyBjb2RlIG9yIG1lZXRzIHRoZSBmaWx0 ZXJpbmcvYmxvY2tpbmcgcnVsZXMuICBVc2UgY2F1dGlvbiB3aGVuIGFjY2Vzc2luZyB0aGUgY29u dGVudHMuIA0KDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIEhlYWRlciAtLS0tLQ0KU3ViamVjdDog UmU6IFtWYWxncmluZC11c2Vyc10gdmV4IHg4Ni0+SVI6IHVuaGFuZGxlZCBpbnN0cnVjdGlvbiBi eXRlczogMHg2NiAweDY2IDB4OTAgMHhFOA0KRnJvbTogdmFsZ3JpbmQtdXNlcnMtYWRtaW5AbGlz dHMuc291cmNlZm9yZ2UubmV0DQpUbzogdmFsZ3JpbmQtdXNlcnNAbGlzdHMuc291cmNlZm9yZ2Uu bmV0DQpDYzogDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K |
|
From: Zachary D. <za...@si...> - 2005-11-01 22:45:57
|
Tom Hughes wrote: > > >If this is a release (such as RedHat/Fedora) with debuginfo packages >available could you install the glibc debuginfo packages and try it >again? > > > Could you point me to the info where to look for debuginfo packages, how to install and use them? I did not get much from Google and I am afraid of touching the existing (sacred!) glibc. >This log seems to be for a 64 bit program though, not a 32 bit one? > >It is generally better to compare like with like... > >I think this is getting a bit complicated to handle here, and there is >clearly some sort of problem that we need to address before the release >of the new code so you could you open a bug for this please. > > > Sorry for not being crisp. I opened the bug 115496 and provided 2 logs for 32bits. I just built valgrind 1426 on 64bits and it passed the invalid address jump point and is running on my testcase now. Thanks, Zach. |
|
From: John R.
|
> ... however 66 66 90 is a pretty strange sequence. 66 is the > operand size override and 90 is nop, so you have a 3-byte useless > instruction. It was compiled on/for x86_64, where 66 66 90 is a NOP that stalls the look-ahead instruction decoder. This is used as alignment filler after an unconditional JMP, in order to save internal CPU resources and power. It happens to run on most 32-bit x86, too. -- |
|
From: Julian S. <js...@ac...> - 2005-11-01 22:28:23
|
On Tuesday 01 November 2005 22:04, Tom Hughes wrote: > In message > <145...@sv...> > > "Yin, Hui" <hu...@me...> wrote: > > This is seen from valgrind-3.0.1 output. The process received SIGKILL > > afterwards. Is this a known issue? > > It should be SIGILL, not KILL... > > Either way, please raise a bug for this. I'll fix it; however 66 66 90 is a pretty strange sequence. 66 is the operand size override and 90 is nop, so you have a 3-byte useless instruction. Where did you get it from? I've never seen the GNU tools generate such a thing. J |
|
From: Tom H. <to...@co...> - 2005-11-01 22:04:28
|
In message <145...@sv...>
"Yin, Hui" <hu...@me...> wrote:
> This is seen from valgrind-3.0.1 output. The process received SIGKILL
> afterwards. Is this a known issue?
It should be SIGILL, not KILL...
Either way, please raise a bug for this.
Thanks,
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Yin, H. <hu...@me...> - 2005-11-01 22:01:33
|
This is seen from valgrind-3.0.1 output. The process received SIGKILL afterwards. Is this a known issue? =20 Linux bullwinkle 2.4.21-4.EL #1 Fri Oct 3 18:13:58 EDT 2003 i686 i686 i386 GNU/Linux Red Hat Enterprise Linux WS release 3 (Taroon) Thanks, --Hui =20 |
|
From: Julian S. <js...@ac...> - 2005-11-01 19:02:57
|
Ok, svn up (make sure you get vex r1427) and try again. I was too lazy to spark up my amd64 box so the fix is as-yet untested :-) J |
|
From: Julian S. <js...@ac...> - 2005-11-01 18:48:50
|
> vex amd64->IR: unhandled instruction bytes: 0x66 0xF 0x11 0x47 Yeh, this is bug 115116 (see http://bugs.kde.org/show_bug.cgi?id=115116). Will look at it shortly. J |