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
(13) |
2
|
|
3
(2) |
4
(7) |
5
(6) |
6
(6) |
7
(4) |
8
|
9
(2) |
|
10
(3) |
11
(5) |
12
(5) |
13
(5) |
14
(5) |
15
(3) |
16
|
|
17
(1) |
18
(8) |
19
(2) |
20
(7) |
21
(1) |
22
|
23
|
|
24
|
25
(6) |
26
(4) |
27
(3) |
28
|
29
(7) |
30
(4) |
|
From: Bart V. A. <bva...@ac...> - 2012-06-06 14:24:23
|
On 06/06/12 13:44, Christoph Bartoschek wrote:
> Am 06.06.2012 15:12, schrieb Bart Van Assche:
>
>>> It is just a thin wrapper around glibc malloc.
>>>
>>> at 0x4C2CD6F: malloc (vg_replace_malloc.c:267)
>>> by 0x1D78D377: st_opt_l1_wrap (st_opt_wrap.c:46)
>>>
>>>
>>> indicates that Valgrind sees the malloc call.
>>
>>
>> Please tell us what that wrapper does. Does it e.g. do any caching of
>> recently freed blocks ?
>
> No. It does nothing. I explicitly disabled all advanced memory managers
> for the valgrind runs. The active one is now the DefaultMem that calls
> malloc directly:
>
> inline void *DefaultMem::alloc(std::size_t size)
> {
> if( size )
> {
> void *p = malloc(size);
> if( ! p ) BN_XCP_MALLOC(size);
> return p;
> }
> return NULL;
> }
>
> inline void DefaultMem::free(void *p, std::size_t size)
> {
> if( size ) ::free(p);
> }
OK, I'll start digging in the DRD implementation. That might take some
time though.
Bart.
|
|
From: Christoph B. <bar...@or...> - 2012-06-06 13:44:18
|
Am 06.06.2012 15:12, schrieb Bart Van Assche:
>> It is just a thin wrapper around glibc malloc.
>>
>> at 0x4C2CD6F: malloc (vg_replace_malloc.c:267)
>> by 0x1D78D377: st_opt_l1_wrap (st_opt_wrap.c:46)
>>
>>
>> indicates that Valgrind sees the malloc call.
>
>
> Please tell us what that wrapper does. Does it e.g. do any caching of
> recently freed blocks ?
No. It does nothing. I explicitly disabled all advanced memory managers
for the valgrind runs. The active one is now the DefaultMem that calls
malloc directly:
inline void *DefaultMem::alloc(std::size_t size)
{
if( size )
{
void *p = malloc(size);
if( ! p ) BN_XCP_MALLOC(size);
return p;
}
return NULL;
}
inline void DefaultMem::free(void *p, std::size_t size)
{
if( size ) ::free(p);
}
|
|
From: Bart V. A. <bva...@ac...> - 2012-06-06 13:12:29
|
On 06/06/12 13:01, Christoph Bartoschek wrote: > Am 06.06.2012 14:41, schrieb Bart Van Assche: >> On 06/06/12 07:56, Christoph Bartoschek wrote: >> >>> Am 05.06.2012 20:12, schrieb Christoph Bartoschek: >>>>>> >>>>>> How can this happen? >>>>> >>>>> >>>>> Was that output produced by Valgrind 3.7.0 ? If so, do you get the >>>>> same >>>>> output if you build Valgrind from the SVN trunk ? >>>> >>>> >>>> Yes it was from 3.7.0. I start a run with SVN trunk. It takes about 20 >>>> hours. >>> >>> The first errors show up and I see the same problem. A race is reported >>> for memory that has just been allocated and is now filled. >> >> It would help if you could have a look at the assembly code generated by >> the compiler to see if the compiler really calls malloc at that point - >> maybe some header file has redefined malloc such that it allocates >> memory from a memory pool that has not been instrumented for Valgrind. >> Also, which memory allocator are you using ? The one in glibc, tcmalloc >> or even another one ? > > It is just a thin wrapper around glibc malloc. > > at 0x4C2CD6F: malloc (vg_replace_malloc.c:267) > by 0x1D78D377: st_opt_l1_wrap (st_opt_wrap.c:46) > > > indicates that Valgrind sees the malloc call. Please tell us what that wrapper does. Does it e.g. do any caching of recently freed blocks ? Bart. |
|
From: Christoph B. <bar...@or...> - 2012-06-06 13:01:32
|
Am 06.06.2012 14:41, schrieb Bart Van Assche: > On 06/06/12 07:56, Christoph Bartoschek wrote: > >> Am 05.06.2012 20:12, schrieb Christoph Bartoschek: >>>>> >>>>> How can this happen? >>>> >>>> >>>> Was that output produced by Valgrind 3.7.0 ? If so, do you get the same >>>> output if you build Valgrind from the SVN trunk ? >>> >>> >>> Yes it was from 3.7.0. I start a run with SVN trunk. It takes about 20 >>> hours. >> >> The first errors show up and I see the same problem. A race is reported >> for memory that has just been allocated and is now filled. > > It would help if you could have a look at the assembly code generated by > the compiler to see if the compiler really calls malloc at that point - > maybe some header file has redefined malloc such that it allocates > memory from a memory pool that has not been instrumented for Valgrind. > Also, which memory allocator are you using ? The one in glibc, tcmalloc > or even another one ? It is just a thin wrapper around glibc malloc. at 0x4C2CD6F: malloc (vg_replace_malloc.c:267) by 0x1D78D377: st_opt_l1_wrap (st_opt_wrap.c:46) indicates that Valgrind sees the malloc call. Christoph |
|
From: Bart V. A. <bva...@ac...> - 2012-06-06 12:41:24
|
On 06/06/12 07:56, Christoph Bartoschek wrote: > Am 05.06.2012 20:12, schrieb Christoph Bartoschek: >>>> >>>> How can this happen? >>> >>> >>> Was that output produced by Valgrind 3.7.0 ? If so, do you get the same >>> output if you build Valgrind from the SVN trunk ? >> >> >> Yes it was from 3.7.0. I start a run with SVN trunk. It takes about 20 >> hours. > > The first errors show up and I see the same problem. A race is reported > for memory that has just been allocated and is now filled. It would help if you could have a look at the assembly code generated by the compiler to see if the compiler really calls malloc at that point - maybe some header file has redefined malloc such that it allocates memory from a memory pool that has not been instrumented for Valgrind. Also, which memory allocator are you using ? The one in glibc, tcmalloc or even another one ? Bart. |
|
From: Christoph B. <bar...@or...> - 2012-06-06 07:56:21
|
Am 05.06.2012 20:12, schrieb Christoph Bartoschek:
>>>
>>> How can this happen?
>>
>>
>> Was that output produced by Valgrind 3.7.0 ? If so, do you get the same
>> output if you build Valgrind from the SVN trunk ?
>
>
> Yes it was from 3.7.0. I start a run with SVN trunk. It takes about 20
> hours.
The first errors show up and I see the same problem. A race is reported
for memory that has just been allocated and is now filled.
Is it possible that DRD thinks that the memory still belongs to a
different allocation?
I see also another strange thing:
Other segment end (thread 7)
at 0x4C32042: pthread_spin_init (drd_pthread_intercepts.c:813)
by 0x7A4719: spin_np_t::unlock(legos::spin_np_t*) (legos_spin.C:117)
The line legos_spin.C:117 is:
int rc = pthread_spin_unlock( &s->_spin );
So why is DRD reporting pthread_spin_init?
Thanks
Christoph
|
|
From: Philippe W. <phi...@sk...> - 2012-06-05 20:40:44
|
On Tue, 2012-06-05 at 18:03 +0200, Christoph Bartoschek wrote:
> I am sure that the spin lock is not used recursively because the code
> basically looks like this:
>
> mutex m;
> int data = 0;
>
> int func()
> {
> m.lock();
> int ret = ++data;
> m.unlock();
> return ret;
> }
>
> This is the only occurence of the lock.
Well, then that looks like a real bug in the pthread lib
(or a bug in the Valgrind simulation e.g. of atomic instructions use
by the pthread lib ?).
If you have a small reproducer, that will help to dig into the problem.
Otherwise, gdb on Valgrind and/or Valgrind gdbserver might help
you to see what is going (wrong).
Philippe
|
|
From: Christoph B. <bar...@or...> - 2012-06-05 18:12:41
|
>> >> How can this happen? > > > Was that output produced by Valgrind 3.7.0 ? If so, do you get the same > output if you build Valgrind from the SVN trunk ? Yes it was from 3.7.0. I start a run with SVN trunk. It takes about 20 hours. Christoph |
|
From: Bart V. A. <bva...@ac...> - 2012-06-05 17:02:05
|
On 06/05/12 16:13, Christoph Bartoschek wrote:
> I get the following race from DRD:
>
> Conflicting store by thread 7 at 0x55fe8aa0 size 8
> by 0x5CCD8750: func() (inv_utils.C:1711)
> by 0x4C2C0C1: ??? (in /usr/lib64/valgrind/vgpreload_drd-amd64-linux.so)
> by 0x5047F04: start_thread (in /lib64/libpthread-2.14.1.so)
> by 0x5CB710C: clone (in /lib64/libc-2.14.1.so)
> Address 0x55fe8aa0 is at offset 0 from 0x55fe8aa0. Allocation context:
> at 0x4C2BC9D: malloc (in
> /usr/lib64/valgrind/vgpreload_drd-amd64-linux.so)
> by 0x5CCD849F: func() (inv_utils.C:1690)
> by 0x4C2C0C1: ??? (in /usr/lib64/valgrind/vgpreload_drd-amd64-linux.so)
> by 0x5047F04: start_thread (in /lib64/libpthread-2.14.1.so)
> by 0x5CB710C: clone (in /lib64/libc-2.14.1.so)
> Other segment start (thread 6)
> at 0x4C31712: pthread_spin_lock (in
> /usr/lib64/valgrind/vgpreload_drd-amd64-linux.so)
> by 0x22C031FD: hunc (bn_thread.C:43)
> by 0x4C2C0C1: ??? (in /usr/lib64/valgrind/vgpreload_drd-amd64-linux.so)
> by 0x5047F04: start_thread (in /lib64/libpthread-2.14.1.so)
> by 0x5CB710C: clone (in /lib64/libc-2.14.1.so)
> Other segment end (thread 6)
> at 0x4C30EC2: pthread_spin_init (in
> /usr/lib64/valgrind/vgpreload_drd-amd64-linux.so)
> by 0x22C032AD: hunc (bn_thread.C:47)
> by 0x4C2C0C1: ??? (in /usr/lib64/valgrind/vgpreload_drd-amd64-linux.so)
> by 0x5047F04: start_thread (in /lib64/libpthread-2.14.1.so)
> by 0x5CB710C: clone (in /lib64/libc-2.14.1.so)
>
>
>
> The function func() is in essence:
>
> {
> int * data = malloc(100);
> for (int i = 0; i != 100; ++i) {
> data[i] = 0; <------- Line 1711
> }
>
> // Some small calculations
>
> free(data);
> }
>
>
> So I wonder how there can be a data race for writting to data. The
> memory has been just allocated and no other thread knows about it.
>
> How can this happen?
Was that output produced by Valgrind 3.7.0 ? If so, do you get the same
output if you build Valgrind from the SVN trunk ?
Bart.
|
|
From: Christoph B. <bar...@or...> - 2012-06-05 16:15:26
|
Hi,
I get the following race from DRD:
Conflicting store by thread 7 at 0x55fe8aa0 size 8
by 0x5CCD8750: func() (inv_utils.C:1711)
by 0x4C2C0C1: ??? (in /usr/lib64/valgrind/vgpreload_drd-amd64-linux.so)
by 0x5047F04: start_thread (in /lib64/libpthread-2.14.1.so)
by 0x5CB710C: clone (in /lib64/libc-2.14.1.so)
Address 0x55fe8aa0 is at offset 0 from 0x55fe8aa0. Allocation context:
at 0x4C2BC9D: malloc (in
/usr/lib64/valgrind/vgpreload_drd-amd64-linux.so)
by 0x5CCD849F: func() (inv_utils.C:1690)
by 0x4C2C0C1: ??? (in /usr/lib64/valgrind/vgpreload_drd-amd64-linux.so)
by 0x5047F04: start_thread (in /lib64/libpthread-2.14.1.so)
by 0x5CB710C: clone (in /lib64/libc-2.14.1.so)
Other segment start (thread 6)
at 0x4C31712: pthread_spin_lock (in
/usr/lib64/valgrind/vgpreload_drd-amd64-linux.so)
by 0x22C031FD: hunc (bn_thread.C:43)
by 0x4C2C0C1: ??? (in /usr/lib64/valgrind/vgpreload_drd-amd64-linux.so)
by 0x5047F04: start_thread (in /lib64/libpthread-2.14.1.so)
by 0x5CB710C: clone (in /lib64/libc-2.14.1.so)
Other segment end (thread 6)
at 0x4C30EC2: pthread_spin_init (in
/usr/lib64/valgrind/vgpreload_drd-amd64-linux.so)
by 0x22C032AD: hunc (bn_thread.C:47)
by 0x4C2C0C1: ??? (in /usr/lib64/valgrind/vgpreload_drd-amd64-linux.so)
by 0x5047F04: start_thread (in /lib64/libpthread-2.14.1.so)
by 0x5CB710C: clone (in /lib64/libc-2.14.1.so)
The function func() is in essence:
{
int * data = malloc(100);
for (int i = 0; i != 100; ++i) {
data[i] = 0; <------- Line 1711
}
// Some small calculations
free(data);
}
So I wonder how there can be a data race for writting to data. The
memory has been just allocated and no other thread knows about it.
How can this happen?
Thanks
Christoph
|
|
From: Christoph B. <bar...@or...> - 2012-06-05 16:05:23
|
Am 04.06.2012 20:44, schrieb Philippe Waroquiers:
> On Mon, 2012-06-04 at 14:14 +0200, Christoph Bartoschek wrote:
>> Am 04.06.2012 14:00, schrieb Tom Hughes:
>>> On 04/06/12 12:27, Christoph Bartoschek wrote:
>>>
>>>> how should one interpret the following report:
>>>>
>>>> Thread #11: Bug in libpthread: recursive write lock granted on
>>>> mutex/wrlock which does not support recursion
>>>> ==00:13:17:12.428 20623== at 0x4C2D18D: pthread_spin_lock (in
>>>> /usr/lib64/valgrind/vgpreload_helgrind-amd64-linux.so)
>>>>
>>>>
>>>> Is there a bug in libpthread that does something strange? Or is there a
>>>> bug in my program that tries to lock a lock twice?
>>>
>>> It's saying that the program is trying to lock a mutex which is (a)
>>> already locked and (b) not marked as a recursive mutex.
>>>
>>> So yes, something is trying to lock the same mutex twice.
>>>
>>> Whether it is your program at fault is hard to say for sure without
>>> seeing the rest of the stack trace.
> The pthread_mutex_lock manual says:
> "If the mutex type is PTHREAD_MUTEX_DEFAULT, attempting to recursively
> lock the mutex results in undefined behavior."
> So, one of the possible outcome of the undefined behaviour is to give
> the lock. Valgrind then reports this as a bug in the pthread library
> (even if this is not formally a bug, according to the manual).
I am sure that the spin lock is not used recursively because the code
basically looks like this:
mutex m;
int data = 0;
int func()
{
m.lock();
int ret = ++data;
m.unlock();
return ret;
}
This is the only occurence of the lock.
> But of course, the above is only ok if your program effectively
> tries to lock recursively a non recursive mutex.
>
>> however I wonder that the message does not mention where the lock was
>> aquired for the first time.
> You might try --tool=drd --trace-mutex=yes --trace-rwlock=yes
> to have more details about what is happening.
I am afraid of the billions of lines in the logfile before the problem
occurs.
Christoph
|
|
From: Julian S. <js...@ac...> - 2012-06-05 00:50:10
|
On Monday, June 04, 2012, Eliot Moss wrote:
> unhandled here). A quick look suggests that this is a PADDB instruction.
Yes, 64-bit (MMX) PADDB. Problem is it has a redundant REX prefix
(IPP is very strong on those, for some reason), and Valgrind pretty
much rejects all redundant REX prefixes.
Marc, in guest_amd64_toIR.c find this
case 0xFC:
case 0xFD:
case 0xFE: /* PADDgg (src)mmxreg-or-mem, (dst)mmxreg */
if (sz != 4)
goto mmx_decode_failure;
delta = dis_MMXop_regmem_to_reg ( vbi, pfx, delta, opc, "padd", True
);
break;
and change (sz != 4) to (sz != 4 && sz != 8). That might help.
J
> I think someone has been working on adding some of those instructions
> latelt; it *might* be covered if you grab and build from svn head.
>
> Regards -- Eliot Moss (a fellow user and occasional patch contributor)
>
> ---------------------------------------------------------------------------
> --- Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
|
|
From: Philippe W. <phi...@sk...> - 2012-06-04 18:43:49
|
On Mon, 2012-06-04 at 14:14 +0200, Christoph Bartoschek wrote:
> Am 04.06.2012 14:00, schrieb Tom Hughes:
> > On 04/06/12 12:27, Christoph Bartoschek wrote:
> >
> >> how should one interpret the following report:
> >>
> >> Thread #11: Bug in libpthread: recursive write lock granted on
> >> mutex/wrlock which does not support recursion
> >> ==00:13:17:12.428 20623== at 0x4C2D18D: pthread_spin_lock (in
> >> /usr/lib64/valgrind/vgpreload_helgrind-amd64-linux.so)
> >>
> >>
> >> Is there a bug in libpthread that does something strange? Or is there a
> >> bug in my program that tries to lock a lock twice?
> >
> > It's saying that the program is trying to lock a mutex which is (a)
> > already locked and (b) not marked as a recursive mutex.
> >
> > So yes, something is trying to lock the same mutex twice.
> >
> > Whether it is your program at fault is hard to say for sure without
> > seeing the rest of the stack trace.
The pthread_mutex_lock manual says:
"If the mutex type is PTHREAD_MUTEX_DEFAULT, attempting to recursively
lock the mutex results in undefined behavior."
So, one of the possible outcome of the undefined behaviour is to give
the lock. Valgrind then reports this as a bug in the pthread library
(even if this is not formally a bug, according to the manual).
But of course, the above is only ok if your program effectively
tries to lock recursively a non recursive mutex.
> however I wonder that the message does not mention where the lock was
> aquired for the first time.
You might try --tool=drd --trace-mutex=yes --trace-rwlock=yes
to have more details about what is happening.
Philippe
|
|
From: Eliot M. <mo...@cs...> - 2012-06-04 17:32:33
|
On 6/4/2012 1:23 PM, Amstoutz Marc wrote: > Hi valgrind experts, > > I’m facing an unhandled instruction issue when valgrinding ing intel-ipp libraries. > > ~/valgrind-3.7.0/bin/valgrind --tool=memcheck --leak-check=full --show-reachable=yes > --error-limit=no --log-file=valgrnd.txt --gen-suppressions=all … > > vex amd64->IR: unhandled instruction bytes: 0x48 0xF 0xFC 0xD 0x37 0xBB 0x22 0x0 > > ==12078== valgrind: Unrecognised instruction at address 0x4cacf71. > > ==12078== at 0x4CACF71: ??? (in …) > > ==12078== by 0x4CA3282: y8_ippiFilterDeblockingLuma_VerEdge_H264_8u_C1IR (in …) > > I have tried to disable error reporting using VALGRIND_DISABLE_ERROR_REPORTING/ > VALGRIND_ENABLE_ERROR_REPORTING macros without success. > > Could you help me to disable error reporting for this error ? > > In addition, do you think such error should be reported as a bug (I’ve noticed similar bugs into the > bugbase) ? Dear Marc -- You can't disable that. It means that valgrind encountered instructions that it does not know what to do with. There is no way for it to continue sensibly (beyond causing a signal, which presumably is unhandled here). A quick look suggests that this is a PADDB instruction. I think someone has been working on adding some of those instructions latelt; it *might* be covered if you grab and build from svn head. Regards -- Eliot Moss (a fellow user and occasional patch contributor) |
|
From: Amstoutz M. <Mar...@th...> - 2012-06-04 17:23:30
|
Hi valgrind experts, I'm facing an unhandled instruction issue when valgrinding ing intel-ipp libraries. ~/valgrind-3.7.0/bin/valgrind --tool=memcheck --leak-check=full --show-reachable=yes --error-limit=no --log-file=valgrnd.txt --gen-suppressions=all ... vex amd64->IR: unhandled instruction bytes: 0x48 0xF 0xFC 0xD 0x37 0xBB 0x22 0x0 ==12078== valgrind: Unrecognised instruction at address 0x4cacf71. ==12078== at 0x4CACF71: ??? (in ...) ==12078== by 0x4CA3282: y8_ippiFilterDeblockingLuma_VerEdge_H264_8u_C1IR (in ...) I have tried to disable error reporting using VALGRIND_DISABLE_ERROR_REPORTING/ VALGRIND_ENABLE_ERROR_REPORTING macros without success. Could you help me to disable error reporting for this error ? In addition, do you think such error should be reported as a bug (I've noticed similar bugs into the bugbase) ? Regards, Marc |
|
From: Christoph B. <bar...@or...> - 2012-06-04 12:16:33
|
Am 04.06.2012 14:00, schrieb Tom Hughes:
> On 04/06/12 12:27, Christoph Bartoschek wrote:
>
>> how should one interpret the following report:
>>
>> Thread #11: Bug in libpthread: recursive write lock granted on
>> mutex/wrlock which does not support recursion
>> ==00:13:17:12.428 20623== at 0x4C2D18D: pthread_spin_lock (in
>> /usr/lib64/valgrind/vgpreload_helgrind-amd64-linux.so)
>>
>>
>> Is there a bug in libpthread that does something strange? Or is there a
>> bug in my program that tries to lock a lock twice?
>
> It's saying that the program is trying to lock a mutex which is (a)
> already locked and (b) not marked as a recursive mutex.
>
> So yes, something is trying to lock the same mutex twice.
>
> Whether it is your program at fault is hard to say for sure without
> seeing the rest of the stack trace.
Thanks,
however I wonder that the message does not mention where the lock was
aquired for the first time.
This is how the complete message looks like:
Thread #14: Bug in libpthread: recursive write lock granted on
mutex/wrlock which does not support recursion
at 0x4C2D18D: pthread_spin_lock (in
/usr/lib64/valgrind/vgpreload_helgrind-amd64-linux.so)
by 0x67B8E9: legos::spin_np_t::lock__default(legos::spin_np_t*) (in
nutsh-O)
by 0xE1E7F30: IJMQueue::remove(IJMPropertyOwner*, int) (in src-O.dll)
by 0xE1E4CD5: IJMTimingPoint::removeATQ() (in src-O.dll)
by 0x105D3577: IJMHierBox::theATQueueThreadFunc(void*) (in engine-O.dll)
by 0x4C2C03D: ??? (in
/usr/lib64/valgrind/vgpreload_helgrind-amd64-linux.so)
by 0x503DF04: start_thread (in /lib64/libpthread-2.14.1.so)
by 0x5CAD10C: clone (in /lib64/libc-2.14.1.so)
Christoph
|
|
From: Tom H. <to...@co...> - 2012-06-04 12:01:04
|
On 04/06/12 12:27, Christoph Bartoschek wrote: > how should one interpret the following report: > > Thread #11: Bug in libpthread: recursive write lock granted on > mutex/wrlock which does not support recursion > ==00:13:17:12.428 20623== at 0x4C2D18D: pthread_spin_lock (in > /usr/lib64/valgrind/vgpreload_helgrind-amd64-linux.so) > > > Is there a bug in libpthread that does something strange? Or is there a > bug in my program that tries to lock a lock twice? It's saying that the program is trying to lock a mutex which is (a) already locked and (b) not marked as a recursive mutex. So yes, something is trying to lock the same mutex twice. Whether it is your program at fault is hard to say for sure without seeing the rest of the stack trace. Tom -- Tom Hughes (to...@co...) http://compton.nu/ |
|
From: Christoph B. <bar...@or...> - 2012-06-04 11:49:52
|
Hi, how should one interpret the following report: Thread #11: Bug in libpthread: recursive write lock granted on mutex/wrlock which does not support recursion ==00:13:17:12.428 20623== at 0x4C2D18D: pthread_spin_lock (in /usr/lib64/valgrind/vgpreload_helgrind-amd64-linux.so) Is there a bug in libpthread that does something strange? Or is there a bug in my program that tries to lock a lock twice? Thanks Christoph |
|
From: <pa...@fr...> - 2012-06-04 10:09:33
|
----- Original Message ----- > On Sunday, June 03, 2012, Paul Floyd wrote: > > I'll try adding it and confirm either tonight or tomorrow. > > Please do. Hi Just done the test, and the problem is fixed. A+ Paul |
|
From: Julian S. <js...@ac...> - 2012-06-03 09:11:36
|
On Sunday, June 03, 2012, Paul Floyd wrote: > I'll try adding it and confirm either tonight or tomorrow. Please do. J |
|
From: Paul F. <pa...@fr...> - 2012-06-03 07:22:47
|
Hi We just switched our reference platform to RHEL 6.2, using Valgrind 3.7.0 Now we're getting loads of errors in __GI___strncasecmp_l I see that in "memcheck/mc_replace_strmem.c" line 680 of 1585 [head svn version] there is STRCASECMP_L(VG_Z_LIBC_SONAME, strcasecmp_l) STRCASECMP_L(VG_Z_LIBC_SONAME, __GI_strcasecmp_l) STRCASECMP_L(VG_Z_LIBC_SONAME, __GI___strcasecmp_l) but at "memcheck/mc_replace_strmem.c" line 645 of 1585 STRNCASECMP_L(VG_Z_LIBC_SONAME, strncasecmp_l) STRNCASECMP_L(VG_Z_LIBC_SONAME, __GI_strncasecmp_l) There seems to be a STRNCASECMP_L(VG_Z_LIBC_SONAME, __GI___strncasecmp_l) missing. I'll try adding it and confirm either tonight or tomorrow. A+ Paul |
|
From: Julian S. <js...@ac...> - 2012-06-01 11:34:51
|
> So, a 10x slowdown is *good*, not bad, given what is going on > under the covers. A 10x slowdown is actually pretty bad for --tool=none, especially after transation chaining landed last month. If the system is steady-stating at 10x slowdown with --tool=none, that's a bug that I'd like to know about. Starting large apps (apache, etc) requires jitting tens or hundreds of thousands of basic blocks and can take several seconds, which makes these short-running tests unrepresentative of the steady state performance. Because of that, qi...@12..., you might get a better result by arranging your tests to do more useful work per process-startup. J |
|
From: Eliot M. <mo...@cs...> - 2012-06-01 11:23:33
|
On 6/1/2012 6:34 AM, 齐玉华 wrote: > Thanks for your detail account. In the manual the program degradation is relatively 5 times slower > than native execution with the "--tool=none" flag. And "valgrind --tool=none -q date" takes about > 0.370 seconds. Thus, i assume that the valgrind start time is no more than 0.370 seconds. But I am > confused to the following program degradation(~about 10 times): --tool=none still rewrites code and in effect emulates your cpu's semantics on your same cpu. This emulation will indeed slow things down quite a bit. You can kind of think of it as like a somewhat optimized interpreter for your machine -- but it is still at some level an interpreter. So, a 10x slowdown is *good*, not bad, given what is going on under the covers. Eliot Moss |
|
From: 齐玉华 <qi...@12...> - 2012-06-01 10:34:16
|
Thanks for your detail account. In the manual the program degradation is relatively 5 times slower than native execution with the "--tool=none" flag. And "valgrind --tool=none -q date" takes about 0.370 seconds. Thus, i assume that the valgrind start time is no more than 0.370 seconds. But I am confused to the following program degradation(~about 10 times): ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ grace@grace:~/software/WAutoRepair/experiment/php/php_null$ time /home/grace/software/WAutoRepair/experiment/php/php_null/php-src-5.3/sapi/cli/php good2.php 6 real 0m4.764s user 0m4.756s sys 0m0.004s grace@grace:~/software/WAutoRepair/experiment/php/php_null$ time valgrind --tool=none -q /home/grace/software/WAutoRepair/experiment/php/php_null/php-src-5.3/sapi/cli/php good2.php 6 real 0m44.110s user 0m43.971s sys 0m0.140s ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ than, what has happened? At 2012-06-01 17:20:33,"Dallman, John" <joh...@si...> wrote: > Because the recompilation time of one patched php is nearly 20 seconds, so if the > sum of degradation time is more than 20 seconds, then our method of indirecting > function will perorm worse than native regression testing. You must expect performance under Valgrind to be worse than any normal kind of test harness for regression testing. Valgrind is not a substitute for normal kinds of testing, or is it a general-purpose testing framework. Its value is that it can find errors that normal testing won't, errors that leave the code producing correct results most of the time, but wasting memory, using uninitialized variables whose contents are unpredictable, or other errors depending on the tool that you use. For example, the products I work on have slowdowns of x20 to x30 under Valgrind. I don't attempt to run daily testing with Valgrind, because it would be far too slow. Instead, as the development phase of each release comes (there are two per year) to an end, and pre-release maintenance gets under way, I run all of the appropriate testing once under Valgrind. This takes several weeks, and finds (some types of) coding errors made by the developers during the development of the release. Those get fixed in the release. This method is not perfect — running all the testing every day under Valgrind would be preferable. But the amount of hardware it would require (perhaps 50 modern Linux machines) compared to the number of problem it would find (perhaps one per moth) makes the perfect solution quite impractical. Using Valgrind has considerably reduced the numbers of errors reported by users that we can't reproduce, which is well worthwhile. That has been achieved using one or two machines. -- John Dallman |
|
From: Baurzhan I. <ib...@ra...> - 2012-06-01 10:24:15
|
Hello Gnanasekar, On Fri, Jun 01, 2012 at 01:49:21PM +0530, Gnanasekar R wrote: > I followed the instruction as mentioned in the below link and patched > Valgrind 3.7.0 for armv5. ... > ==907== Process terminating with default action of signal 4 (SIGILL) > ==907== Illegal opcode at address 0x61D20004 > ==907== at 0x40007C0: ??? (in /lib/ld-2.9.so) I've experienced the same problem (http://thread.gmane.org/gmane.comp.debugging.valgrind/11478/focus=11794), but didn't have time to dig into that. You may want to provide disassembly up to 0x40007C0. If it's also svc, provide also the data John Reiser asked for in the thread above. With kind regards, Baurzhan. |