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
(5) |
2
(2) |
3
(9) |
4
(2) |
|
5
(2) |
6
(1) |
7
(2) |
8
(11) |
9
(13) |
10
(3) |
11
(1) |
|
12
|
13
(5) |
14
(18) |
15
(5) |
16
(10) |
17
|
18
|
|
19
|
20
(2) |
21
|
22
(10) |
23
(4) |
24
(8) |
25
(2) |
|
26
|
27
(10) |
28
(17) |
|
|
|
|
|
From: Julian S. <js...@ac...> - 2006-02-14 16:06:15
|
Hi Graydon. Apologies for very slow reply. It sounds like a plausible idea. I guess you need to make friends with the leak checker, which pretty self-contained and is in memcheck/mac_leakcheck.c. I'm not clear how the leak checker works now (JeremyF added some cycle-detecting cleverness, but I don't know exactly how it works). J > I believe that *most* of the machinery for this task is present already > in memcheck. I wonder if anyone has any advice about how to "finish the > job", and make this functionality real. I'm happy to do all the work > myself, but I figure some valgrind old hands might be able to reply with > a helpful suggestion or two which might save me a few weeks of dead-ends > while tying it all together. |
|
From: Julian S. <js...@ac...> - 2006-02-14 16:00:37
|
Michael, what is the status of this now? If you want it fixed please can you file a bug report. J On Tuesday 24 January 2006 14:41, Tom Hughes wrote: > In message > <8858BFBCB86F8D4BA996BEA6FF05F3DAA94D6E@US01WEMBX2.internal.synopsys.com> > > Michael Wang <Mic...@sy...> wrote: > > I got this msg when running callgrind with valgrind and program exits > > with fatal: > > > > x amd64->IR: unhandled instruction bytes: 0xDB 0xD9 0xDD 0xD9 > > > > Just want to quickly check what is the instruction and if it is a > > known issue. > > It's FCMOVNU which is an x87 instruction and it doesn't appear to > be implemented in the current code, so please raise a bug for this. > > Tom |
|
From: Dirk M. <dm...@gm...> - 2006-02-14 15:18:59
|
On Tuesday, 14. February 2006 16:06, Julian Seward wrote: > So I'm confused. Dirk: did you see Valgrind missing an underflow of > a malloc area by 1 byte? Or was it 36 bytes? It IIRC writes several times outside the range of the bitmap buffer. The first write is most likely the mentioned 1 byte underflow, the next one is 1 byte + width_of_image, the next one is 1 byte + 2*width_of_image and so on. Insure apparently managed to capture the first write successfully. I didn't, because I couldn't find a tool that does so, and I only found the offending wrong coordinate which later then caused the out of bounds write. I didn't actually tracked down which particular write was the first one corrupting memory. I just found one of the offenders and that was enough :) Dirk |
|
From: Julian S. <js...@ac...> - 2006-02-14 15:06:58
|
So I'm confused. Dirk: did you see Valgrind missing an underflow of a malloc area by 1 byte? Or was it 36 bytes? J On Tuesday 14 February 2006 14:44, Dirk Mueller wrote: > On Tuesday, 14. February 2006 15:29, Paul Pluzhnikov wrote: > > > Did you use the Chaperon tool or did you recompile with purify? > > > > Both Chaperon and Insure instrumentation (which is different from > > Purify) do find the bug. > > Sorry, mixed up the product name :) Ok, if Chaperon catches it then there > is something seriously wrong for the valgrind case. > > > > > - The bug is an underflow of malloc area by 1 byte -- VG > > > > should have no trouble finding this bug (but VG 3.1.0 doesn't). > > > > > > I'm aware. > > > > That's not how you described the bug originally: > > I'm aware that VG 3.1.0 does not catch the underflow. I stopped at some > place finding out which particular write corrupted the memory, because it > was obvious that the coordinates were off the buffer boundaries. > > > Dirk > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log > files for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: Dirk M. <dm...@gm...> - 2006-02-14 14:42:46
|
On Tuesday, 14. February 2006 15:29, Paul Pluzhnikov wrote: > > Did you use the Chaperon tool or did you recompile with purify? > Both Chaperon and Insure instrumentation (which is different from > Purify) do find the bug. Sorry, mixed up the product name :) Ok, if Chaperon catches it then there is something seriously wrong for the valgrind case. > > > - The bug is an underflow of malloc area by 1 byte -- VG > > > should have no trouble finding this bug (but VG 3.1.0 doesn't). > > I'm aware. > That's not how you described the bug originally: I'm aware that VG 3.1.0 does not catch the underflow. I stopped at some place finding out which particular write corrupted the memory, because it was obvious that the coordinates were off the buffer boundaries. Dirk |
|
From: Paul P. <ppl...@gm...> - 2006-02-14 14:29:12
|
On 2/14/06, Dirk Mueller <dm...@gm...> wrote: > On Saturday, 11. February 2006 00:52, Paul Pluzhnikov wrote: > > > - It took me 10 minutes to find the bug with Insure++ > > (www.parasoft.com), report below > > Did you use the Chaperon tool or did you recompile with purify? Both Chaperon and Insure instrumentation (which is different from Purify) do find the bug. > > - The bug is an underflow of malloc area by 1 byte -- VG > > should have no trouble finding this bug (but VG 3.1.0 doesn't). > > I'm aware. That's not how you described the bug originally: DM> It did a write DM> afaik 36 bytes in front of the allocated bitmap buffer, which valgrind= was DM> unable to catch. On 2/14/06, Julian Seward <js...@ac...> wrote: > If you can come up with a test case - even a large one - I'll be > happy to chase it from there. The test case was described in Dirk's message from Feb 1, 2006: build xpdf-3.00 and run it against page 12 of=20 http://www.marantz.com/pdfs/g_sr7500_man.pdf: xpdf-3.00/xpdf/xpdf g_sr7500_man.pdf 12 VG3.1.0 remains silent (on RH-9 and FC4), but without VG the program crashe= s. Cheers, |
|
From: Julian S. <js...@ac...> - 2006-02-14 12:36:44
|
On Tuesday 14 February 2006 11:54, Dirk Mueller wrote: > > - The bug is an underflow of malloc area by 1 byte -- VG > > should have no trouble finding this bug (but VG 3.1.0 doesn't). > > I'm aware. The question is how to deduce a testcase from it... to see why > valgrind fails. This is the hard part. If you can come up with a test case - even a large one - I'll be happy to chase it from there. J |
|
From: Dirk M. <dm...@gm...> - 2006-02-14 11:52:36
|
On Saturday, 11. February 2006 00:52, Paul Pluzhnikov wrote: > - It took me 10 minutes to find the bug with Insure++ > (www.parasoft.com), report below Did you use the Chaperon tool or did you recompile with purify? > - The bug is an underflow of malloc area by 1 byte -- VG > should have no trouble finding this bug (but VG 3.1.0 doesn't). I'm aware. The question is how to deduce a testcase from it... to see why valgrind fails. This is the hard part. Dirk |
|
From: Jelte W. <Jel...@cr...> - 2006-02-14 09:54:49
|
At a glance, you need to initialize your hostent structures. =20 Jelte -----Oorspronkelijk bericht----- Van: yashwant pinge [mailto:yas...@re...]=20 Verzonden: dinsdag 14 februari 2006 10:46 Aan: val...@li... Onderwerp: [Valgrind-users] meaning of error =09 =09 =09 hi, =09 =09 Anybody tell me ............. =09 I am stucked in a one position. =09 I run my binary with valgrind.... =09 valgrind shows the following logs. =09 =09 =3D=3D24238=3D=3D Conditional jump or move depends on uninitialised value(s) =3D=3D24238=3D=3D at 0x1B90A9BC: getanswer_r (in /lib/libnss_dns.so.2) =3D=3D24238=3D=3D by 0x1B90B327: _nss_dns_gethostbyname3_r (in /lib/libnss_dns.so.2) =3D=3D24238=3D=3D by 0x1B90B512: _nss_dns_gethostbyname2_r (in /lib/libnss_dns.so.2) =3D=3D24238=3D=3D by 0x1B90B57B: _nss_dns_gethostbyname_r (in /lib/libnss_dns.so.2) =3D=3D24238=3D=3D by 0x1BB39275: gethostbyname_r@@GLIBC_2.1.2 (in /lib/tls/libc.so.6) =3D=3D24238=3D=3D by 0x8078C13: p_gethostbyname(char const*) (compat.c:30) =3D=3D24238=3D=3D by 0x806308B: net_dns(char const*) (network.c:750) =3D=3D24238=3D=3D by 0x8064499: net_connect(char const*, int, in_addr, int) (network.c:251) =3D=3D24238=3D=3D by 0x807500C: protocol_start(CONNECTION_T*) (protocol.c:123) =3D=3D24238=3D=3D by 0x806005C: handle_request(CONNECTION_T*) (main.c:1372) =3D=3D24238=3D=3D by 0x8060472: process_entry(CONNECTION_T*) (main.c:743) =3D=3D24238=3D=3D by 0x1B9287F2: start_thread (in /lib/tls/libpthread.so.0) =09 my code is :----- =09 int ret, err; char buf[1024]; HOSTENT *hostent; struct hostent h, *hp; =09 ret =3D gethostbyname_r(host, &h, buf, sizeof(buf), &hp, &err);//this is a 30th line in compact.c =09 any body tell me that what the valgrind says...? =09 yashwant=20 =09 <http://adworks.rediff.com/cgi-bin/AdWorks/sigclick.cgi/www.rediff.com/s ignature-home.htm/1507191490@Middle5?PARTNER=3D3> =20 |
|
From: yashwant p. <yas...@re...> - 2006-02-14 09:46:44
|
=0Ahi,=0A=0A=0AAnybody tell me .............=0A=0AI am stucked in a one p= osition.=0A=0AI run my binary with valgrind....=0A=0Avalgrind shows the fol= lowing logs.=0A=0A=0A=3D=3D24238=3D=3D Conditional jump or move depends on = uninitialised value(s)=0A=3D=3D24238=3D=3D at 0x1B90A9BC: getanswer_r (in /= lib/libnss_dns.so.2)=0A=3D=3D24238=3D=3D by 0x1B90B327: _nss_dns_gethostbyn= ame3_r (in /lib/libnss_dns.so.2)=0A=3D=3D24238=3D=3D by 0x1B90B512: _nss_dn= s_gethostbyname2_r (in /lib/libnss_dns.so.2)=0A=3D=3D24238=3D=3D by 0x1B90B= 57B: _nss_dns_gethostbyname_r (in /lib/libnss_dns.so.2)=0A=3D=3D24238=3D=3D= by 0x1BB39275: gethostbyname_r@@GLIBC_2.1.2 (in /lib/tls/libc.so.6)=0A=3D= =3D24238=3D=3D by 0x8078C13: p_gethostbyname(char const*) (compat.c:30)=0A= =3D=3D24238=3D=3D by 0x806308B: net_dns(char const*) (network.c:750)=0A=3D= =3D24238=3D=3D by 0x8064499: net_connect(char const*, int, in_addr, int) (n= etwork.c:251)=0A=3D=3D24238=3D=3D by 0x807500C: protocol_start(CONNECTION_T= *) (protocol.c:123)=0A=3D=3D24238=3D=3D by 0x806005C: handle_request(CONNEC= TION_T*) (main.c:1372)=0A=3D=3D24238=3D=3D by 0x8060472: process_entry(CONN= ECTION_T*) (main.c:743)=0A=3D=3D24238=3D=3D by 0x1B9287F2: start_thread (in= /lib/tls/libpthread.so.0)=0A=0Amy code is :-----=0A=0Aint ret, err;=0Achar= buf[1024];=0AHOSTENT *hostent;=0Astruct hostent h, *hp;=0A=0Aret =3D getho= stbyname_r(host, &h, buf, sizeof(buf), &hp, &err);//this is a 30th line in = compact.c=0A=0Aany body tell me that what the valgrind says...?=0A=0Ayashwa= nt |
|
From: Tom H. <to...@co...> - 2006-02-13 11:37:17
|
In message <E08...@cn...uisetravel.local>
Jelte Werkhoven <Jel...@cr...> wrote:
> I'm using the valgrind-3.0.0 package included with my distro, so I'll
> give upgrading a shot. Thanks for the tip!
Well according to the output you posted it was an SVN build from
somewhere between 3.0.0 and 3.0.1 actually.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Jelte W. <Jel...@cr...> - 2006-02-13 11:00:22
|
Thanks Tom, solved the problem perfectly.
Jelte
-----Oorspronkelijk bericht-----
Van: Jelte Werkhoven=20
Verzonden: maandag 13 februari 2006 11:46
Aan: Tom Hughes; val...@li...
Onderwerp: RE: [Valgrind-users] Illegal opcode in shared lib causes
SIGILL
I'm using the valgrind-3.0.0 package included with my distro, so I'll
give upgrading a shot. Thanks for the tip!
cheers,=20
Jelte
-----Oorspronkelijk bericht-----
Van: Tom Hughes [mailto:to...@co...]=20
Verzonden: maandag 13 februari 2006 11:42
Aan: val...@li...
Onderwerp: Re: [Valgrind-users] Illegal opcode in shared lib causes
SIGILL
In message
<E08...@cn...uisetravel.local>
Jelte Werkhoven <Jel...@cr...> wrote:
> I am trying to debug my application with valgrind. It uses some
> third-party supplied binary libraries for which I have no source code.
> It seems one of these calls an illegal opcode. Does anyone know of a
> way to circumvent this problem?
Use the latest version of valgrind?
> vex x86->IR: unhandled instruction bytes: 0x1C 0xFF 0xF 0xB6
That is "sbb Ib, Al" which is implemented in valgrind 3.1.0 so you need
to upgrade.
Tom
--=20
Tom Hughes (to...@co...)
http://www.compton.nu/
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log
files for problems? Stop! Download the new AJAX search engine that
makes searching your log files as easy as surfing the web. DOWNLOAD
SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D103432&bid=3D230486&dat=3D=
121642
_______________________________________________
Valgrind-users mailing list Val...@li...
https://lists.sourceforge.net/lists/listinfo/valgrind-users
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log
files for problems? Stop! Download the new AJAX search engine that
makes searching your log files as easy as surfing the web. DOWNLOAD
SPLUNK! =
http://sel.as-us.falkag.net/sel?cmd=3Dk&kid=103432&bid#0486&dat=121642
_______________________________________________
Valgrind-users mailing list Val...@li...
https://lists.sourceforge.net/lists/listinfo/valgrind-users
|
|
From: Jelte W. <Jel...@cr...> - 2006-02-13 10:46:27
|
I'm using the valgrind-3.0.0 package included with my distro, so I'll
give upgrading a shot. Thanks for the tip!
cheers,=20
Jelte
-----Oorspronkelijk bericht-----
Van: Tom Hughes [mailto:to...@co...]=20
Verzonden: maandag 13 februari 2006 11:42
Aan: val...@li...
Onderwerp: Re: [Valgrind-users] Illegal opcode in shared lib causes
SIGILL
In message
<E08...@cn...uisetravel.local>
Jelte Werkhoven <Jel...@cr...> wrote:
> I am trying to debug my application with valgrind. It uses some=20
> third-party supplied binary libraries for which I have no source code.
> It seems one of these calls an illegal opcode. Does anyone know of a=20
> way to circumvent this problem?
Use the latest version of valgrind?
> vex x86->IR: unhandled instruction bytes: 0x1C 0xFF 0xF 0xB6
That is "sbb Ib, Al" which is implemented in valgrind 3.1.0 so you need
to upgrade.
Tom
--=20
Tom Hughes (to...@co...)
http://www.compton.nu/
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log
files for problems? Stop! Download the new AJAX search engine that
makes searching your log files as easy as surfing the web. DOWNLOAD
SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D103432&bid=3D230486&dat=3D=
121642
_______________________________________________
Valgrind-users mailing list Val...@li...
https://lists.sourceforge.net/lists/listinfo/valgrind-users
|
|
From: Tom H. <to...@co...> - 2006-02-13 10:41:45
|
In message <E08...@cn...uisetravel.local>
Jelte Werkhoven <Jel...@cr...> wrote:
> I am trying to debug my application with valgrind. It uses some
> third-party supplied binary libraries for which I have no source code.
> It seems one of these calls an illegal opcode. Does anyone know of a way
> to circumvent this problem?
Use the latest version of valgrind?
> vex x86->IR: unhandled instruction bytes: 0x1C 0xFF 0xF 0xB6
That is "sbb Ib, Al" which is implemented in valgrind 3.1.0 so you
need to upgrade.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Jelte W. <Jel...@cr...> - 2006-02-13 10:24:27
|
Hello, =20 I am trying to debug my application with valgrind. It uses some third-party supplied binary libraries for which I have no source code. It seems one of these calls an illegal opcode. Does anyone know of a way to circumvent this problem? =20 Find below the full output of valgrind. =20 TIA, =20 Jelte Werkhoven =20 =20 =20 =3D=3D15913=3D=3D Memcheck, a memory error detector. =3D=3D15913=3D=3D Copyright (C) 2002-2005, and GNU GPL'd, by Julian = Seward et al. =3D=3D15913=3D=3D Using LibVEX rev 1313, a library for dynamic binary translation. =3D=3D15913=3D=3D Copyright (C) 2004-2005, and GNU GPL'd, by OpenWorks = LLP. =3D=3D15913=3D=3D Using valgrind-3.0.1.SVN, a dynamic binary = instrumentation framework. =3D=3D15913=3D=3D Copyright (C) 2000-2005, and GNU GPL'd, by Julian = Seward et al. --15913-- Valgrind library directory: /usr/lib/valgrind --15913-- Command line --15913-- ./amadeus_proxyd --15913-- start --15913-- Startup, with flags: --15913-- --tool=3Dmemcheck --15913-- -v --15913-- Contents of /proc/version: --15913-- Linux version 2.6.13-15.7-default (geeko@buildhost) (gcc version 4.0.2 20050901 (prerelease) (SUSE Linux)) #1 Tue Nov 29 14:32:29 UTC 2005 --15913-- Reading syms from /home/jelte/devel/amadeus/chroot/bin/amadeus_proxyd (0x8048000) --15913-- Reading syms from /lib/ld-2.3.5.so (0x1B8E4000) --15913-- Reading syms from /usr/lib/valgrind/stage2 (0xB0000000) --15913-- object doesn't have a symbol table --15913-- Reading suppressions file: /usr/lib/valgrind/default.supp =3D=3D15913=3D=3D=20 --15913-- Reading syms from /usr/lib/valgrind/vg_preload_core.so (0x1B8FB000) --15913-- object doesn't have a symbol table --15913-- Reading syms from /usr/lib/valgrind/vgpreload_memcheck.so (0x1B8FE000) --15913-- object doesn't have a symbol table --15913-- REDIR: 0x1B8F5440 (index) redirected to 0x1B9011F0 (index) --15913-- REDIR: 0x1B8F55E0 (strlen) redirected to 0x1B9012A0 (strlen) --15913-- Reading syms from /home/jelte/devel/amadeus/lib/libapi_v2_Core.so. (0x1B925000) --15913-- Reading syms from /home/jelte/devel/amadeus/lib/libedi.so.3.13 (0x1B96B000) --15913-- Reading syms from /home/jelte/devel/amadeus/lib/libedixml.so.2.8 (0x1B98F000) --15913-- Reading syms from /home/jelte/devel/amadeus/lib/libedicont.so.1.17 (0x1B99E000) --15913-- Reading syms from /home/jelte/devel/amadeus/lib/libexpat.so.1.10 (0x1B9A8000) --15913-- Reading syms from /home/jelte/devel/amadeus/lib/libgrammarsXML.so.2_1_31_0 (0x1B9CA000) --15913-- Reading syms from /home/jelte/devel/amadeus/lib/libgrammarsCNT.so.2_1_31_0 (0x1BEF0000) --15913-- Reading syms from /home/jelte/devel/amadeus/lib/libzlib.so.3.0 (0x1C43B000) --15913-- Reading syms from /home/jelte/devel/amadeus/lib/libCryptoLib.so.2.0 (0x1C44D000) --15913-- Reading syms from /home/jelte/devel/amadeus/lib/libcontainer.so.2.3 (0x1C454000) --15913-- Reading syms from /home/jelte/devel/amadeus/lib/libtcpsocket.so.3_2 (0x1C45B000) --15913-- Reading syms from /lib/tls/libpthread-2.3.5.so (0x1C468000) --15913-- Reading syms from /lib/tls/libc-2.3.5.so (0x1C47A000) --15913-- Reading syms from /lib/libdl-2.3.5.so (0x1C599000) --15913-- Reading syms from /usr/lib/libstdc++.so.6.0.6 (0x1C59E000) --15913-- object doesn't have a symbol table --15913-- Reading syms from /lib/tls/libm-2.3.5.so (0x1C67A000) --15913-- Reading syms from /lib/libgcc_s.so.1 (0x1C6A0000) --15913-- object doesn't have a symbol table --15913-- REDIR: 0x1B8E47A0 (_dl_sysinfo_int80) redirected to 0xB002303B (???) --15913-- REDIR: 0x1C4E50A0 (memset) redirected to 0x1B9015B0 (memset) --15913-- REDIR: 0x1C4E5570 (memcpy) redirected to 0x1B901690 (memcpy) --15913-- REDIR: 0x1C4E4220 (rindex) redirected to 0x1B9010D0 (rindex) --15913-- REDIR: 0x1C4E3D90 (strlen) redirected to 0x1B901280 (strlen) --15913-- REDIR: 0x1C4E3FB0 (strncmp) redirected to 0x1B9012E0 (strncmp) --15913-- REDIR: 0x1C4DFE20 (malloc) redirected to 0x1B8FF827 (malloc) --15913-- REDIR: 0x1C4DE170 (free) redirected to 0x1B900346 (free) --15913-- REDIR: 0x1C4E3880 (strcpy) redirected to 0x1B9018F0 (strcpy) --15913-- REDIR: 0x1C4E3810 (strcmp) redirected to 0x1B901350 (strcmp) --15913-- REDIR: 0x1C4E0410 (realloc) redirected to 0x1B900BAD (realloc) --15913-- REDIR: 0x1C4E4140 (strncpy) redirected to 0x1B901C00 (strncpy) --15913-- REDIR: 0x1C4E5EB0 (rawmemchr) redirected to 0x1B901670 (rawmemchr) --15913-- REDIR: 0x1C4E4BA0 (memchr) redirected to 0x1B9013F0 (memchr) --15913-- REDIR: 0x1C4E5F80 (strchrnul) redirected to 0x1B901640 (strchrnul) --15913-- REDIR: 0x1C4E5290 (stpcpy) redirected to 0x1B9019A0 (stpcpy) --15913-- REDIR: 0x1C4E36A0 (index) redirected to 0x1B9011C0 (index) --15913-- REDIR: 0x1C4DFAD0 (calloc) redirected to 0x1B900B02 (calloc) --15913-- Reading syms from /lib/libnss_files-2.3.5.so (0x1B905000) vex x86->IR: unhandled instruction bytes: 0x1C 0xFF 0xF 0xB6 =3D=3D15913=3D=3D=20 =3D=3D15913=3D=3D Process terminating with default action of signal 4 = (SIGILL) =3D=3D15913=3D=3D Illegal opcode at address 0x1C462D9D =3D=3D15913=3D=3D at 0x1C462D9D: TCP_Recv (in /home/jelte/devel/amadeus/lib/libtcpsocket.so.3_2) =3D=3D15913=3D=3D by 0x1B93BAAE: CAS_receive (in /home/jelte/devel/amadeus/lib/libapi_v2_Core.so.) =3D=3D15913=3D=3D by 0x1B9435B7: CAS_getAccessToServer (in /home/jelte/devel/amadeus/lib/libapi_v2_Core.so.) =3D=3D15913=3D=3D by 0x1B949D83: CAS_configureConversationFactory (in /home/jelte/devel/amadeus/lib/libapi_v2_Core.so.) =3D=3D15913=3D=3D by 0x1B94A2FE: CAI_createConversationFactory_SI (in /home/jelte/devel/amadeus/lib/libapi_v2_Core.so.) =3D=3D15913=3D=3D by 0x804AD3D: convfac_createConversationFactory (conversationfactory.c:38) =3D=3D15913=3D=3D by 0x804E48F: startServer (proxyd.c:500) =3D=3D15913=3D=3D by 0x804E6EE: main (proxyd.c:590) --15913-- discard syms at 0x1B905000-0x1B910000 in /lib/libnss_files-2.3.5.so due to munmap() =3D=3D15913=3D=3D=20 =3D=3D15913=3D=3D ERROR SUMMARY: 0 errors from 0 contexts (suppressed: = 50 from 4) --15913--=20 --15913-- supp: 3 index-not-intercepted-early-enough-HACK-1 --15913-- supp: 1 strlen-not-intercepted-early-enough-HACK-4 --15913-- supp: 1 strlen-not-intercepted-early-enough-HACK-3 --15913-- supp: 45 dl_relocate_object =3D=3D15913=3D=3D malloc/free: in use at exit: 83037 bytes in 83 blocks. =3D=3D15913=3D=3D malloc/free: 146 allocs, 63 frees, 91663 bytes = allocated. =3D=3D15913=3D=3D=20 =3D=3D15913=3D=3D searching for pointers to 83 not-freed blocks. =3D=3D15913=3D=3D checked 6779916 bytes. =3D=3D15913=3D=3D=20 =3D=3D15913=3D=3D LEAK SUMMARY: =3D=3D15913=3D=3D definitely lost: 0 bytes in 0 blocks. =3D=3D15913=3D=3D possibly lost: 0 bytes in 0 blocks. =3D=3D15913=3D=3D still reachable: 83037 bytes in 83 blocks. =3D=3D15913=3D=3D suppressed: 0 bytes in 0 blocks. =3D=3D15913=3D=3D Reachable blocks (those to which a pointer was found) = are not shown. =3D=3D15913=3D=3D To see them, rerun with: --show-reachable=3Dyes --15913-- memcheck: sanity checks: 29 cheap, 2 expensive --15913-- memcheck: auxmaps: 0 auxmap entries (0k, 0M) in use --15913-- memcheck: auxmaps: 0 searches, 0 comparisons --15913-- memcheck: secondaries: 104 issued (6656k, 6M) --15913-- memcheck: secondaries: 134 accessible and distinguished (8576k, 8M) --15913-- tt/tc: 10318 tt lookups requiring 10932 probes --15913-- tt/tc: 10318 fast-cache updates, 5 flushes --15913-- translate: new 4990 (113946 -> 1830368; ratio 160:10) [0 scs] --15913-- translate: dumped 0 (0 -> ??) --15913-- translate: discarded 121 (2236 -> ??) --15913-- scheduler: 1463672 jumps (bb entries). --15913-- scheduler: 29/5925 major/minor sched events. --15913-- sanity: 30 cheap, 2 expensive checks. --15913-- exectx: 4999 lists, 129 contexts (avg 0 per list) --15913-- exectx: 259 searches, 131 full compares (505 per 1000) --15913-- exectx: 0 cmp2, 142 cmp4, 0 cmpAll Illegal instruction =20 =20 |
|
From: Igmar P. <mai...@jd...> - 2006-02-11 15:56:51
|
> I am using 3.0.1-r1 Valgrind on Gentoo. Bitch at Gentoo for providing an old VG version. > FIX IT IN THE FUTURE, PLEASE!!!!!!!!!!!!!!!!!!! It IS fixed. Igmar |
|
From: Paul P. <ppl...@gm...> - 2006-02-10 23:52:26
|
On 2/1/06, Dirk Mueller <dm...@gm...> wrote: > > https://bugzilla.novell.com/show_bug.cgi?id=3D141242, or run xpdf/kpdf ag= ainst > page 12 of http://www.marantz.com/pdfs/g_sr7500_man.pdf). It did a write > afaik 36 bytes in front of the allocated bitmap buffer, which valgrind wa= s > unable to catch. Just for the record: - It took me 10 minutes to find the bug with Insure++ (www.parasoft.com), report below - The bug is an underflow of malloc area by 1 byte -- VG should have no trouble finding this bug (but VG 3.1.0 doesn't). - Unlike in the case that started this thread, the corrupted area is smack in the middle of heap (there have been thousands of malloc()s performed before that point), so I don't think guard pages around "whole heap" would have helped. - I also tested xpdf-3.01pl2, which came "clean", except for the new read-uninit issue, report below. Cheers, =3D=3D=3D xpdf-3.00 =3D=3D=3D [Splash.cc:817] **WRITE_OVERFLOW** >> *mono8 =3D color.mono8; Writing overflows memory: mono8 bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb | 1 | 25 | wwwww Writing (w) : 0x088fd74f thru 0x088fd74f (1 byte) To block (b) : 0x088fd750 thru 0x088fd768 (25 bytes) block allocated at gmem.c, 89 malloc() pc: 0x00cf72fe (interface) gmalloc() pc: 0x08457085 gmem.c, 89 SplashBitmap::SplashBitmap() pc: 0x084787cf SplashBitmap.cc, 34 SplashOutputDev::type3D1() pc: 0x083127b8 SplashOutputDev.cc, 108= 6 Gfx::opSetCacheDevice() pc: 0x080f88f8 Gfx.cc, 3008 Gfx::execOp() pc: 0x080e49fa Gfx.cc, 660 Gfx::go() pc: 0x08104818 Gfx.cc, 551 Gfx::display() pc: 0x08105fcb Gfx.cc, 523 Gfx::doShowText() pc: 0x08119699 Gfx.cc, 2382 Gfx::opShowText() pc: 0x0811dd32 Gfx.cc, 2238 Gfx::execOp() pc: 0x080e49fa Gfx.cc, 660 Gfx::go() pc: 0x08104818 Gfx.cc, 551 Gfx::display() pc: 0x08105fcb Gfx.cc, 523 Page::displaySlice() pc: 0x082a4390 Page.cc, 319 Page::display() pc: 0x082a52f5 Page.cc, 226 PDFDoc::displayPage() pc: 0x082b526b PDFDoc.cc, 218 XPDFCore::displayPage() pc: 0x083c696a XPDFCore.cc, 513 XPDFViewer::displayPage() pc: 0x083e1a8b XPDFViewer.cc, 272 XPDFViewer::pageNumCbk() pc: 0x083fb84b XPDFViewer.cc, 1516 XtCallCallbackList() pc: 0x00d8f91c _XmTextFieldSetDestination() pc: 0x00664703 _XtMatchAtom() pc: 0x00dc1caa _XtMatchAtom() pc: 0x00dc227a _XtTranslateEvent() pc: 0x00dc27fc XtDispatchEventToWidget() pc: 0x00d9d2d0 _XtOnGrabList() pc: 0x00d9db9c XtDispatchEvent() pc: 0x00d9dd6a XtAppMainLoop() pc: 0x00d9e186 XPDFApp::run() pc: 0x083b56d9 XPDFApp.cc, 290 main() pc: 0x0844190f xpdf.cc, 288 Stack trace where the error occurred: Splash::drawSpan() pc: 0x08460049 Splash.cc, 817 Splash::fillWithPattern() pc: 0x0846110f Splash.cc, 649 Splash::fill() pc: 0x084769ad Splash.cc, 621 SplashOutputDev::fill() pc: 0x0830f92d SplashOutputDev.cc, 735 Gfx::opFill() pc: 0x08116de4 Gfx.cc, 1140 Gfx::execOp() pc: 0x080e49fa Gfx.cc, 660 Gfx::go() pc: 0x08104818 Gfx.cc, 551 Gfx::display() pc: 0x08105fcb Gfx.cc, 523 Gfx::doShowText() pc: 0x08119699 Gfx.cc, 2382 Gfx::opShowText() pc: 0x0811dd32 Gfx.cc, 2238 Gfx::execOp() pc: 0x080e49fa Gfx.cc, 660 Gfx::go() pc: 0x08104818 Gfx.cc, 551 Gfx::display() pc: 0x08105fcb Gfx.cc, 523 Page::displaySlice() pc: 0x082a4390 Page.cc, 319 Page::display() pc: 0x082a52f5 Page.cc, 226 PDFDoc::displayPage() pc: 0x082b526b PDFDoc.cc, 218 XPDFCore::displayPage() pc: 0x083c696a XPDFCore.cc, 513 XPDFViewer::displayPage() pc: 0x083e1a8b XPDFViewer.cc, 272 XPDFViewer::pageNumCbk() pc: 0x083fb84b XPDFViewer.cc, 1516 XtCallCallbackList() pc: 0x00d8f91c _XmTextFieldSetDestination() pc: 0x00664703 _XtMatchAtom() pc: 0x00dc1caa _XtMatchAtom() pc: 0x00dc227a _XtTranslateEvent() pc: 0x00dc27fc XtDispatchEventToWidget() pc: 0x00d9d2d0 _XtOnGrabList() pc: 0x00d9db9c XtDispatchEvent() pc: 0x00d9dd6a XtAppMainLoop() pc: 0x00d9e186 XPDFApp::run() pc: 0x083b56d9 XPDFApp.cc, 290 main() pc: 0x0844190f xpdf.cc, 288 =3D=3D=3D xpdf-3.00 =3D=3D=3D =3D=3D=3D xpdf-3.01pl2 =3D=3D=3D [Splash.cc:515] **READ_UNINIT_MEM(read)** >> if (nClipRes[splashClipPartial] || Reading uninitialized memory: nClipRes[splashClipPartial] Stack trace where the error occurred: Splash::strokeNarrow() Splash.cc, 515 Splash::stroke() Splash.cc, 413 SplashOutputDev::stroke() SplashOutputDev.cc, 1259 Gfx::opStroke() Gfx.cc, 1168 Gfx::execOp() Gfx.cc, 675 Gfx::go() Gfx.cc, 566 Gfx::display() Gfx.cc, 538 Page::displaySlice() Page.cc, 317 PDFDoc::displayPageSlice() PDFDoc.cc, 361 PDFCore::needTile() PDFCore.cc, 790 PDFCore::update() PDFCore.cc, 615 XPDFCore::update() XPDFCore.cc, 305 PDFCore::displayPage() PDFCore.cc, 257 XPDFViewer::displayPage() XPDFViewer.cc, 263 XPDFViewer::XPDFViewer() XPDFViewer.cc, 170 XPDFApp::open() XPDFApp.cc, 224 main() xpdf.cc, 294 =3D=3D=3D xpdf-3.01pl2 =3D=3D=3D |
|
From: Nicholas N. <nj...@cs...> - 2006-02-10 20:46:56
|
On Fri, 10 Feb 2006, Jacek Poplawski wrote: > Is there any way to speed up valgrind (memcheck tool) to run programs faster? Try the code in the repository (see valgrind.org), it has some improvements over 3.1.0. And 3.2.0 will hopefully have some more. Nick |
|
From: Jacek P. <ja...@s3...> - 2006-02-10 09:59:44
|
Is there any way to speed up valgrind (memcheck tool) to run programs faster? Only thing I found in doc is to set smc to none. Is it possible to disable something else? The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s). Please direct any additional queries to: com...@s3.... Thank You. |
|
From: Julian S. <js...@ac...> - 2006-02-09 23:46:40
|
> Yes , getting rid of that code and adding just the have_fp =have_vmx = > False; works. > It seems that the test in the original code is taking the wrong path and > it fails. No; signal handling in your Linux distro, or cross-compiling arrangement, or something, is broken. This code works fine on multiple different PowerPC platforms we test on. > Where is the __builtin_setjmp defined???? I could not find it). It's a function that gcc 'knows' about without needing a prototype. > Also, are you trying to defect if you have fp or not at runtime?? Yes, also trying to detect presence/absence of Altivec. J |
|
From: Dennis L. <pla...@in...> - 2006-02-09 23:33:40
|
Am Donnerstag, den 09.02.2006, 23:04 +0000 schrieb Tom Hughes: > These should already be found and used by valgrind automatically. I've > never tried it with SuSE but it certainly works with Fedora. If you run > with -v then you should see something like this: > > --20714-- Reading syms from /lib/libc-2.3.5.so (0x2B6000) > --20714-- Reading debug info from /usr/lib/debug/lib/libc-2.3.5.so.debug... > > Showing that it has read debug information from the debug files installed > from the debuginfo package. Wow, I didnt even thought about that valgrind could already support it :) From failing to use them I errenously inferred that it doesnt. So now that I know it does, I will further look what went wrong, and if its Vs fault will come back :) greets Dennis |
|
From: Nicholas N. <nj...@cs...> - 2006-02-09 23:10:13
|
On Thu, 9 Feb 2006 Brian_Howell@PlayStation.Sony.Com wrote: > Sorry for getting upset, just seems there are way too many complaints in > the valgrind-user list, and always seem to run into this problem. > Redoing my kernel is not an option. As several people said: try the latest version of Valgrind. > I just want the KICKSTART_BASE I should try. I have worked around this in > past without complaining, but when I keep on having to work around and you > have several other complaints in your list something is wrong. > > You scold me for getting upset, but are not giving me fix to the problem. As several people said: try the latest version of Valgrind. > I thought I saw a message that you fixed this in your 2.4 version, but > guess not. > > I will try 3.10 when I update my gentoo portage hopefully I will see it > and can upgrade. Excellent idea. > Instead of scolding ME just give me the memory workaround, don't want > to guess. As several people said: try the latest version of Valgrind. Nick |
|
From: Nicholas N. <nj...@cs...> - 2006-02-09 23:07:56
|
On Thu, 9 Feb 2006, Julian Seward wrote: >> I have recently discovered on the SuSE 10.0 Linux Distribution that >> there are "debuginfo" packages for lots of installed packages. After >> installing it for one of the apps I have installed, the ?? in the >> stacktrace of gdb disappeared and I actually got usefuly output. I have >> looke a bit further in it, and it installed the sources and some special >> looking files. Now the question is, if its possible to get those >> external infos somehow into valgrind too? Sorry to give so few >> information about how its working, I couldnt really figure out. > > So I thought we have had the ability to read debuginfo packages for > ages (Tom H will know for sure). Maybe it got broken by recent hacking. > (if so, we should regression-test it somehow). What V version are > you using? If the debuginfo packages are not installed for the app then Valgrind can't take advantage of them... this seems like an issue with the app and its installation rather than Valgrind. Nick |
|
From: Tom H. <to...@co...> - 2006-02-09 23:04:18
|
In message <1139522500.27095.6.camel@speedy>
Dennis Lubert <pla...@in...> wrote:
> I have recently discovered on the SuSE 10.0 Linux Distribution that
> there are "debuginfo" packages for lots of installed packages. After
> installing it for one of the apps I have installed, the ?? in the
> stacktrace of gdb disappeared and I actually got usefuly output. I have
> looke a bit further in it, and it installed the sources and some special
> looking files. Now the question is, if its possible to get those
> external infos somehow into valgrind too? Sorry to give so few
> information about how its working, I couldnt really figure out.
These should already be found and used by valgrind automatically. I've
never tried it with SuSE but it certainly works with Fedora. If you run
with -v then you should see something like this:
--20714-- Reading syms from /lib/libc-2.3.5.so (0x2B6000)
--20714-- Reading debug info from /usr/lib/debug/lib/libc-2.3.5.so.debug...
Showing that it has read debug information from the debug files installed
from the debuginfo package.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Dennis L. <pla...@in...> - 2006-02-09 22:25:14
|
Am Donnerstag, den 09.02.2006, 22:21 +0000 schrieb Julian Seward: > So I thought we have had the ability to read debuginfo packages for > ages (Tom H will know for sure). Maybe it got broken by recent hacking. > (if so, we should regression-test it somehow). What V version are > you using? SVN |