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
(6) |
2
(8) |
3
(9) |
4
(4) |
|
5
(2) |
6
(9) |
7
(8) |
8
(3) |
9
(3) |
10
|
11
|
|
12
(3) |
13
(8) |
14
(2) |
15
(10) |
16
(6) |
17
(2) |
18
(4) |
|
19
(1) |
20
(1) |
21
(8) |
22
(10) |
23
|
24
(5) |
25
(2) |
|
26
|
27
(4) |
28
(17) |
29
(3) |
30
(19) |
|
|
|
From: Dennis L. <pla...@gm...> - 2004-09-17 20:22:15
|
Hello People, how far are the plans for porting valgrind to AMD64 ? Is there already some branch for it ? What are the main reasons why its not yet ported ? If its hardware, maybe I could be able to give shell access to a 4CPU Opteron... greets Dennis Carpe quod tibi datum est |
|
From: Betty W. <gre...@ho...> - 2004-09-16 17:37:00
|
I want to follow up with the last message. To be more specific, Valgrind can check dynamic memory allocation by following the memory allocation and deallocation functions like, malloc, free, new, delete... But what about static memory allocation? Such as the example that I listed below, just declaring an array statically? is the the size of memory allocated statically can also be reported by Valgrind? Thanks! Betty >Betty Wang wrote: >>Hi, Dimitri, >>Thanks for your reply. What I want to measure using Valgrind is that >>how much (computation) data is allocated in memory by the application. >>There is no read/written into/from FILES involved in my case. >> >>For example, >>A simple matrix multiplication, >> >>double matrixA[SIZE][SIZE], matrixB[SIZE][SIZE], matrixC[SIZE][SIZE]; >> >>for ( i = 0; i < SIZE; i ++) >> for ( j = 0; j < SIZE; j ++) >> for ( k = 0; k < SIZE; k ++) >> matrixC[i][j] += matrixA[i][k] * matrixB[k][j] >> >>The (computation) data allocated in memory is the size of >>(matrixA + matrixB + matrixC). >>i.e., 3 x (SIZE x SIZE) x sizeof(double). The size of the computation >>data that need to used by this application, matrix multiplication is what >>I want to know by using valgrind. >>Of cause, matrix multiplication is a simple example. We can caculate >>manually by knowing how much data needs to be allocated in memory. But >>for more complex applications, it would be handy by using some tools, such >>as valgrind to know how much data is allocated in memory. >> >>So my question is if I have an application, would Valgrind tell me how >>much data is used/accessed/allocated by this application? >> >>I hope I made myself clear. If not, please let me know. >>And thanks again for your kind help. >> >>Betty >> >> >> >>>-------- Original Message -------- >>>Subject: Re: [Valgrind-users] how to use valgrind to check data size? >>>Date: Thu, 16 Sep 2004 10:00:09 +0200 >>>From: Dimitri Papadopoulos-Orfanos <pap...@sh...> >>>To: val...@li... >>>References: <414...@wm...> >>> >>>Hi, >>> >>>>I am new to valgrind. I have a question regarding to use valgrind to >>>>check data size. Suppose I have an application, would it be possible to >>>>use valgrind to check how much data this application is accessed? If >>>>so, how would I do this? >>> >>> >>>What do you mean exactly by "how much data"? >>> >>>How much data is read/written to/from files? >>>How much memory is allocated? >>> >>>Dimitri >>> >>> >> >>_________________________________________________________________ >>Dont just search. Find. Check out the new MSN Search! >>http://search.msn.click-url.com/go/onm00200636ave/direct/01/ >> >> >> >>------------------------------------------------------- >>This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 >>Project Admins to receive an Apple iPod Mini FREE for your judgement on >>who ports your project to Linux PPC the best. Sponsored by IBM. >>Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php >>_______________________________________________ >>Valgrind-users mailing list >>Val...@li... >>https://lists.sourceforge.net/lists/listinfo/valgrind-users _________________________________________________________________ FREE pop-up blocking with the new MSN Toolbar get it now! http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/ |
|
From: Betty W. <gre...@ho...> - 2004-09-16 16:14:12
|
Hi, Dimitri,
Thanks for your reply. What I want to measure using Valgrind is that
how much (computation) data is allocated in memory by the application. There
is no read/written into/from FILES involved in my case.
For example,
A simple matrix multiplication,
double matrixA[SIZE][SIZE], matrixB[SIZE][SIZE], matrixC[SIZE][SIZE];
for ( i = 0; i < SIZE; i ++)
for ( j = 0; j < SIZE; j ++)
for ( k = 0; k < SIZE; k ++)
matrixC[i][j] += matrixA[i][k] * matrixB[k][j]
The (computation) data allocated in memory is the size of
(matrixA + matrixB + matrixC).
i.e., 3 x (SIZE x SIZE) x sizeof(double). The size of the computation data
that need to used by this application, matrix multiplication is what I want
to know by using valgrind.
Of cause, matrix multiplication is a simple example. We can caculate
manually by knowing how much data needs to be allocated in memory. But for
more complex applications, it would be handy by using some tools, such as
valgrind to know how much data is allocated in memory.
So my question is if I have an application, would Valgrind tell me how much
data is used/accessed/allocated by this application?
I hope I made myself clear. If not, please let me know.
And thanks again for your kind help.
Betty
>-------- Original Message --------
>Subject: Re: [Valgrind-users] how to use valgrind to check data size?
>Date: Thu, 16 Sep 2004 10:00:09 +0200
>From: Dimitri Papadopoulos-Orfanos <pap...@sh...>
>To: val...@li...
>References: <414...@wm...>
>
>Hi,
>
>>I am new to valgrind. I have a question regarding to use valgrind to
>>check data size. Suppose I have an application, would it be possible to
>>use valgrind to check how much data this application is accessed? If so,
>>how would I do this?
>
>What do you mean exactly by "how much data"?
>
>How much data is read/written to/from files?
>How much memory is allocated?
>
>Dimitri
>
>
_________________________________________________________________
Dont just search. Find. Check out the new MSN Search!
http://search.msn.click-url.com/go/onm00200636ave/direct/01/
|
|
From: Duzlevski, O. <duz...@mi...> - 2004-09-16 14:02:55
|
Hi all, I am trying to debug a multithreaded C app I wrote. When running through = valgrind, it crashes with the following: =3D=3D31036=3D=3D --31036-- INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV) - = exiting --31036-- si_code=3D2 Fault EIP: 0xB002D3C2; Faulting address: = 0xB126EFF8 valgrind: the `impossible' happened: Killed by fatal signal Basic block ctr is approximately 254200000 =3D=3D31036=3D=3D at 0xB002FFDF: vgPlain_core_panic = (vg_mylibc.c:1156) =3D=3D31036=3D=3D by 0xB002FFDE: panic (vg_mylibc.c:1152) =3D=3D31036=3D=3D by 0xB002FFFF: vgPlain_core_panic = (vg_mylibc.c:1157) =3D=3D31036=3D=3D by 0xB00374B0: vg_sync_signalhandler = (vg_signals.c:2191) I am using Valgrind 2.2.0, --tool=3Dmemcheck --leak-check=3Dyes = --show-reachable=3Dyes --error-limit=3Dno Is this an internal valgrind problem? When I run my application without = valgrind it does not crash and produces expected results. Ognen |
|
From: Jose <zel...@gm...> - 2004-09-16 08:21:32
|
Hi, I'm new to valgrind. I've just started using it right now and I've got this error: vg_libpthread.c:2303 (fcntl): Assertion `fcntl_ptr != ((void *)0) && fcntl_ptr != fcntl' failed. My program is running on Linux version 2.4.5, gcc version 2.96 and the distribution is Red Hat Linux 7.1 Could anyone please help me? Thanks a lot. Jose. |
|
From: Dimitri Papadopoulos-O. <pap...@sh...> - 2004-09-16 08:00:12
|
Hi, > I am new to valgrind. I have a qustion regarding to use valgrind to > check data size. Suppose I have an application, would it be possible to > use valgrind to check how much data this application is accessed? If > so, how would I do this? What do you mean exactly by "how much data"? How much data is read/written to/from files? How much memory is allocated? Dimitri |
|
From: Betty W. <tx...@wm...> - 2004-09-16 03:18:37
|
Hello, all, I am new to valgrind. I have a qustion regarding to use valgrind to check data size. Suppose I have an application, would it be possible to use valgrind to check how much data this application is accessed? If so, how would I do this? Thanks! -- Betty |
|
From: Robert W. <rj...@du...> - 2004-09-15 22:52:34
|
Oops - forgot to CC the list. -------- Forwarded Message -------- From: Robert Walsh <rj...@du...> To: Naveen Kumar <g_n...@ya...> Subject: Re: [Valgrind-users] Re: Calling popen() in a pthread = valgrind assertion failure? Date: Wed, 15 Sep 2004 15:51:43 -0700 > /*Later ... it appears we cannot call file-related stuff in libc here, > perhaps fair enough. Be careful what you call from here. Even exit() > doesn't work (gives infinite recursion and then stack overflow); hence > myexit(). Also fprintf doesn't seem safe.*/ This is regarding calling fprintf from within a function in the libpthread replacement library, not from within a client program. > I did use fprintf in one of my apps(multi-threaded) > and valgrind didn't work. Can you be more specific? I suspect this isn't related. Regards, Robert. |
|
From: Naveen K. <g_n...@ya...> - 2004-09-15 22:48:20
|
Oops maybe I spoke too soon about the particular program in question but I think there is a problem with fprintf. Look at the header in vg_libpthread.c. It says /*Later ... it appears we cannot call file-related stuff in libc here, perhaps fair enough. Be careful what you call from here. Even exit() doesn't work (gives infinite recursion and then stack overflow); hence myexit(). Also fprintf doesn't seem safe.*/ I did use fprintf in one of my apps(multi-threaded) and valgrind didn't work. Naveen --- Robert Walsh <rj...@du...> wrote: > On Wed, 2004-09-15 at 10:53 -0700, Naveen Kumar > wrote: > > valgrind seems to have a problem with fprintf, so > you > > might need to take that out. > > Valgrind doesn't have any problems with fprintf that > we're aware of. > > Regards, > Robert. > > --- Tom Hughes <th...@cy...> wrote: > In message > <200...@we...> > Naveen Kumar <g_n...@ya...> wrote: > > > valgrind seems to have a problem with fprintf, so > you > > might need to take that out. > > It has no problems with fprintf that we are aware > of, so if you > think you know otherwise I suggest you report it. > > Tom > > -- > Tom Hughes (th...@cy...) > Software Engineer, Cyberscience Corporation > http://www.cyberscience.com/ > > > ------------------------------------------------------- > This SF.Net email is sponsored by: thawte's Crypto > Challenge Vl > Crack the code and win a Sony DCRHC40 MiniDV Digital > Handycam > Camcorder. More prizes in the weekly Lunch Hour > Challenge. > Sign up NOW > http://ad.doubleclick.net/clk;10740251;10262165;m > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > __________________________________ Do you Yahoo!? Yahoo! Mail - You care about security. So do we. http://promotions.yahoo.com/new_mail |
|
From: Tom H. <th...@cy...> - 2004-09-15 18:35:02
|
In message <200...@we...>
Naveen Kumar <g_n...@ya...> wrote:
> valgrind seems to have a problem with fprintf, so you
> might need to take that out.
It has no problems with fprintf that we are aware of, so if you
think you know otherwise I suggest you report it.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Scott K. <val...@ke...> - 2004-09-15 18:09:34
|
Perfect! Thanks, Tom. Scott. On 16/09/2004, at 12:22 AM, Tom Hughes wrote: > In message <5E4...@ke...> > Scott Kevill <val...@ke...> wrote: > >> got signal 17 in LWP 8794 (8794) >> >> valgrind: vg_signals.c:1997 (vg_async_signalhandler): Assertion >> `vgPlain_ksigismember(&uc->uc_sigmask, sigNo)' failed. >> ....................... >> >> /usr/sbin/sendmail is actually a just a wrapper for qmail here. >> >> Signal 17 is SIGCHLD (child process has stopped or exited, changed). >> If >> valgrind doesn't support this, is there anyway I can get it to ignore >> it? > > You've got a kernel with a bit of a misfeature. Earlier and later > kernels will both work fine. See bug 82114 for the details and a > fairly horrible patch that will workaround the problem. > > Tom > > -- > Tom Hughes (th...@cy...) > Software Engineer, Cyberscience Corporation > http://www.cyberscience.com/ > > > ------------------------------------------------------- > This SF.Net email is sponsored by: thawte's Crypto Challenge Vl > Crack the code and win a Sony DCRHC40 MiniDV Digital Handycam > Camcorder. More prizes in the weekly Lunch Hour Challenge. > Sign up NOW http://ad.doubleclick.net/clk;10740251;10262165;m > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > > -- Scott Kevill scott@GameRanger.com http://www.GameRanger.com the Macintosh multiplayer online gaming service |
|
From: Naveen K. <g_n...@ya...> - 2004-09-15 17:54:03
|
valgrind seems to have a problem with fprintf, so you
might need to take that out.
--- Scott Kevill <val...@ke...> wrote:
> Oops, it's even simpler than that. Doesn't even need
> to involve
> pthreads:
>
> #include <stdio.h>
> #include <stdlib.h>
>
> int main(int argc, char **argv)
> {
> FILE *mailer;
>
> mailer = popen("/usr/sbin/sendmail -t", "w");
> if (mailer) {
> fprintf(mailer, "To: %s\n",
> getenv("USER"));
> fprintf(mailer, "Subject: Test email\n");
> fprintf(mailer, "\n");
> fprintf(mailer, "This is a test!\n");
>
> pclose(mailer);
> }
>
> return 0;
> }
>
> .......................
> [scott@localhost scott]$ valgrind --tool=memcheck
> --num-callers=40
> ./test
> ==8794== Memcheck, a memory error detector for
> x86-linux.
> ==8794== Copyright (C) 2002-2004, and GNU GPL'd, by
> Julian Seward et al.
> ==8794== Using valgrind-2.2.0, a program supervision
> framework for
> x86-linux.
> ==8794== Copyright (C) 2000-2004, and GNU GPL'd, by
> Julian Seward et al.
> ==8794== For more details, rerun with: -v
> ==8794==
> got signal 17 in LWP 8794 (8794)
>
> valgrind: vg_signals.c:1997
> (vg_async_signalhandler): Assertion
> `vgPlain_ksigismember(&uc->uc_sigmask, sigNo)'
> failed.
> .......................
>
> /usr/sbin/sendmail is actually a just a wrapper for
> qmail here.
>
> Signal 17 is SIGCHLD (child process has stopped or
> exited, changed). If
> valgrind doesn't support this, is there anyway I can
> get it to ignore
> it?
>
> Thanks,
> Scott.
>
>
>
>
-------------------------------------------------------
> This SF.Net email is sponsored by: thawte's Crypto
> Challenge Vl
> Crack the code and win a Sony DCRHC40 MiniDV Digital
> Handycam
> Camcorder. More prizes in the weekly Lunch Hour
> Challenge.
> Sign up NOW
> http://ad.doubleclick.net/clk;10740251;10262165;m
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
>
https://lists.sourceforge.net/lists/listinfo/valgrind-users
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
|
|
From: Tom H. <th...@cy...> - 2004-09-15 16:22:16
|
In message <5E4...@ke...>
Scott Kevill <val...@ke...> wrote:
> got signal 17 in LWP 8794 (8794)
>
> valgrind: vg_signals.c:1997 (vg_async_signalhandler): Assertion
> `vgPlain_ksigismember(&uc->uc_sigmask, sigNo)' failed.
> .......................
>
> /usr/sbin/sendmail is actually a just a wrapper for qmail here.
>
> Signal 17 is SIGCHLD (child process has stopped or exited, changed). If
> valgrind doesn't support this, is there anyway I can get it to ignore
> it?
You've got a kernel with a bit of a misfeature. Earlier and later
kernels will both work fine. See bug 82114 for the details and a
fairly horrible patch that will workaround the problem.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Scott K. <val...@ke...> - 2004-09-15 15:34:28
|
Oops, it's even simpler than that. Doesn't even need to involve
pthreads:
#include <stdio.h>
#include <stdlib.h>
int main(int argc, char **argv)
{
FILE *mailer;
mailer = popen("/usr/sbin/sendmail -t", "w");
if (mailer) {
fprintf(mailer, "To: %s\n", getenv("USER"));
fprintf(mailer, "Subject: Test email\n");
fprintf(mailer, "\n");
fprintf(mailer, "This is a test!\n");
pclose(mailer);
}
return 0;
}
.......................
[scott@localhost scott]$ valgrind --tool=memcheck --num-callers=40
./test
==8794== Memcheck, a memory error detector for x86-linux.
==8794== Copyright (C) 2002-2004, and GNU GPL'd, by Julian Seward et al.
==8794== Using valgrind-2.2.0, a program supervision framework for
x86-linux.
==8794== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward et al.
==8794== For more details, rerun with: -v
==8794==
got signal 17 in LWP 8794 (8794)
valgrind: vg_signals.c:1997 (vg_async_signalhandler): Assertion
`vgPlain_ksigismember(&uc->uc_sigmask, sigNo)' failed.
.......................
/usr/sbin/sendmail is actually a just a wrapper for qmail here.
Signal 17 is SIGCHLD (child process has stopped or exited, changed). If
valgrind doesn't support this, is there anyway I can get it to ignore
it?
Thanks,
Scott.
|
|
From: Swami N.
|
Hi, I have a multithreaded daemon (called ased) that runs ok when started without valgrind. The daemon forks a child process and the parent exits soon afterwards. The child runs forever. When started with valgrind 2.1.2 the process comes up for a few secs and then quietly exits (see below). I tried with valgrind 2.2.0 and got the same results. Gcc : 3.2.2 Linux : 2.4.20 Valgrind used to work for an old version of ased. The new version adds more threads and also uses a custom pthread library. I modified LD_LIBRARY_PATH so as to use the regular thread library thinking it may have something to do with the problem. Again, I got the same results. =20 Appreciate if anyone can help me. The information is probably insufficient to pinpoint the problem, but even pointers on where to look would help. Thanks, SN. ************************************************** [root@localhost etc]# ps -ef |grep ased root 32245 12087 0 17:43 pts/65 00:00:00 grep ased [root@localhost etc]# ps -ef |grep ased ^[[Aroot 32246 22393 91 17:43 pts/70 00:00:00 /usr/local/bin/valgrind --tool=3Dmemcheck --trace-children=3Dyes --logfile=3D/valgrind = ../bin/ased -d root 32249 12087 0 17:43 pts/65 00:00:00 grep ased ^^^^^^^^^^^ 1 process [root@localhost etc]# ps -ef |grep ased root 32246 22393 75 17:43 pts/70 00:00:02 /usr/local/bin/valgrind --tool=3Dmemcheck --trace-children=3Dyes --logfile=3D/valgrind = ../bin/ased -d root 32253 12087 0 17:43 pts/65 00:00:00 grep ased root 32254 32246 0 17:43 pts/70 00:00:00 /usr/local/bin/valgrind --tool=3Dmemcheck --trace-children=3Dyes --logfile=3D/valgrind = ../bin/ased -d ^^^^^^^^^^^ 2 processes [root@localhost etc]# ps -ef |grep ased root 32260 12087 0 17:43 pts/65 00:00:00 grep ased [root@localhost etc]# ^^^^^^^^^^ processes gone! ************************************************** The following is the tail of the log file generated by valgrind. =3D=3D24267=3D=3D TRANSLATE: 0x1BA7FFD0 redirected to 0x1B90404E =3D=3D24267=3D=3D TRANSLATE: 0x42073880 redirected to 0x1B9041C8 =3D=3D24290=3D=3D TRANSLATE: 0x42073880 redirected to 0x1B9041C8 =3D=3D24292=3D=3D TRANSLATE: 0x42073880 redirected to 0x1B9041C8 =3D=3D24292=3D=3D Warning: ignored attempt to set SIGSTOP handler in sigaction(); =3D=3D24292=3D=3D the SIGSTOP signal is uncatchable ^^^^^^^^^^^^^could this be the problem?? =3D=3D24267=3D=3D warning: Valgrind's pthread_cond_destroy is incomplete =3D=3D24292=3D=3D warning: Valgrind's pthread_cond_destroy is incomplete =3D=3D24292=3D=3D (it doesn't check if the cond is waited on) =3D=3D24292=3D=3D your program may misbehave as a result ^^^^^^^^^^^^^ or this perhaps??? =3D=3D24290=3D=3D warning: Valgrind's pthread_cond_destroy is incomplete =3D=3D24290=3D=3D (it doesn't check if the cond is waited on) =3D=3D24290=3D=3D your program may misbehave as a result =3D=3D24267=3D=3D (it doesn't check if the cond is waited on) =3D=3D24267=3D=3D your program may misbehave as a result =3D=3D24290=3D=3D =3D=3D24290=3D=3D ERROR SUMMARY: 0 errors from 0 contexts (suppressed: = 39 from 1) --24290-- --24290-- supp: 39 Ugly strchr error in /lib/ld-2.3.2.so =3D=3D24290=3D=3D malloc/free: in use at exit: 1972 bytes in 12 blocks. =3D=3D24290=3D=3D malloc/free: 18 allocs, 6 frees, 4652 bytes allocated. =3D=3D24290=3D=3D --24290-- TT/TC: 0 tc sectors discarded. --24290-- 5805 tt_fast misses. --24290-- translate: new 5652 (90046 -> 1222320; ratio 135:10) --24290-- discard 1 (23 -> 320; ratio 139:10). --24290-- chainings: 2933 chainings, 2 unchainings. --24290-- dispatch: 450000 jumps (bb entries); of them 46048 (10%) unchained. --24290-- 154/6548 major/minor sched events. --24290-- reg-alloc: 694 t-req-spill, 225755+5355 orig+spill uis, --24290-- 27120 total-reg-rank --24290-- sanity: 107 cheap, 5 expensive checks. --24290-- ccalls: 26861 C calls, 64% saves+restores avoided (102990 bytes) --24290-- 35232 args, avg 0.89 setup instrs each (7090 bytes) --24290-- 0% clear the stack (80469 bytes) --24290-- 7789 retvals, 33% of reg-reg movs avoided (5044 bytes) =3D=3D24292=3D=3D =3D=3D24292=3D=3D ERROR SUMMARY: 0 errors from 0 contexts (suppressed: = 39 from 1) --24292-- --24292-- supp: 39 Ugly strchr error in /lib/ld-2.3.2.so =3D=3D24292=3D=3D malloc/free: in use at exit: 1972 bytes in 12 blocks. =3D=3D24292=3D=3D malloc/free: 19 allocs, 7 frees, 5004 bytes allocated. =3D=3D24292=3D=3D --24292-- TT/TC: 0 tc sectors discarded. --24292-- 6129 tt_fast misses. --24292-- translate: new 5975 (94930 -> 1286225; ratio 135:10) --24292-- discard 1 (23 -> 320; ratio 139:10). --24292-- chainings: 3090 chainings, 2 unchainings. --24292-- dispatch: 450000 jumps (bb entries); of them 56445 (12%) unchained. --24292-- 158/9371 major/minor sched events. --24292-- reg-alloc: 729 t-req-spill, 237512+5547 orig+spill uis, --24292-- 28668 total-reg-rank --24292-- sanity: 109 cheap, 5 expensive checks. --24292-- ccalls: 28219 C calls, 64% saves+restores avoided (108012 bytes) --24292-- 37074 args, avg 0.89 setup instrs each (7494 bytes) --24292-- 0% clear the stack (84495 bytes) --24292-- 8201 retvals, 33% of reg-reg movs avoided (5356 bytes) =3D=3D24267=3D=3D =3D=3D24267=3D=3D ERROR SUMMARY: 0 errors from 0 contexts (suppressed: = 39 from 1) --24267-- --24267-- supp: 39 Ugly strchr error in /lib/ld-2.3.2.so =3D=3D24267=3D=3D malloc/free: in use at exit: 1972 bytes in 12 blocks. =3D=3D24267=3D=3D malloc/free: 18 allocs, 6 frees, 4652 bytes allocated. =3D=3D24267=3D=3D --24267-- TT/TC: 0 tc sectors discarded. --24267-- 5769 tt_fast misses. --24267-- translate: new 5616 (89683 -> 1216761; ratio 135:10) --24267-- discard 1 (23 -> 320; ratio 139:10). --24267-- chainings: 2912 chainings, 2 unchainings. --24267-- dispatch: 450000 jumps (bb entries); of them 45914 (10%) unchained. --24267-- 154/6503 major/minor sched events. --24267-- reg-alloc: 692 t-req-spill, 224770+5351 orig+spill uis, --24267-- 26978 total-reg-rank --24267-- sanity: 107 cheap, 5 expensive checks. --24267-- ccalls: 26726 C calls, 64% saves+restores avoided (102526 bytes) --24267-- 35056 args, avg 0.89 setup instrs each (7034 bytes) --24267-- 0% clear the stack (80067 bytes) --24267-- 7748 retvals, 33% of reg-reg movs avoided (5010 bytes) |
|
From: Scott K. <val...@ke...> - 2004-09-15 14:33:55
|
Hi all, I've created a very simple test program that causes valgrind (both memcheck and addrcheck) to assert with: valgrind: vg_signals.c:1997 (vg_async_signalhandler): Assertion `vgPlain_ksigismember(&uc->uc_sigmask, sigNo)' failed. All the program does is create a pthread, and from that pthread it calls popen() to open a pipe to qmail to send an email. Is this a known limitation? Or something I should file a proper bug report for? (Yes, I have more details, I just thought I'd check first). Thanks, Scott. |
|
From: Enders, B. <Bor...@pd...> - 2004-09-15 08:42:36
|
Hello,
I'am compiling valgrind 2.2.0 on
Red Hat Enterprise Linux WS release 3 (Taroon Update 2)
with
gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-39)
With following modifications:
1) export CPPFLAGS=3D-I/usr/src/linux-2.4/include/
(for finding asm/msr.h)
2) including <linux/if.h>
(for avoiding redefinitions)
But I'am still getting the following error:
if gcc -DHAVE_CONFIG_H -I. -I. -I.. -I./demangle -I../include
-I../include -I./
x86 -DVG_LIBDIR=3D"\"/home/benders/val22/lib/valgrind"\"
-DKICKSTART_BASE=3D0xb00000
00 -I/usr/src/linux-2.4/include/ -Winline -Wall -Wshadow -O
-fno-omit-frame-poi
nter -mpreferred-stack-boundary=3D2 -g -DELFSZ=3D32 -MT vg_syscalls.o =
-MD
-MP -MF "
.deps/vg_syscalls.Tpo" -c -o vg_syscalls.o vg_syscalls.c; \
then mv -f ".deps/vg_syscalls.Tpo" ".deps/vg_syscalls.Po"; else rm -f
".deps/vg_
syscalls.Tpo"; exit 1; fi
In file included from vg_unsafe.h:52,
from vg_syscalls.c:35:
/usr/src/linux-2.4/include/net/route.h:37:2: warning: #warning This file
is not=20
supposed to be used outside of kernel.
In file included from /usr/src/linux-2.4/include/net/route.h:28,
from vg_unsafe.h:52,
from vg_syscalls.c:35:
/usr/src/linux-2.4/include/net/dst.h:30: parse error before `atomic_t'
/usr/src/linux-2.4/include/net/dst.h:30: warning: no semicolon at end of
struct=20
or union
/usr/src/linux-2.4/include/net/dst.h:67: parse error before `}'
/usr/src/linux-2.4/include/net/dst.h:85: parse error before `atomic_t'
/usr/src/linux-2.4/include/net/dst.h:85: warning: no semicolon at end of
struct=20
or union
/usr/src/linux-2.4/include/net/dst.h:86: warning: type defaults to `int'
in decl
aration of `kmem_cachep'
/usr/src/linux-2.4/include/net/dst.h:86: warning: data definition has no
type or
storage class
And some following errors...
Starting with the warning: net/route.h:37:2: warning: #warning This file
is not=20
supposed to be used outside of kernel.
I changed <net/route.h> to <linux/route.h>, but then I'am getting the
following error:
if gcc -DHAVE_CONFIG_H -I. -I. -I.. -I./demangle -I../include
-I../include -I./x86 =
-DVG_LIBDIR=3D"\"/home/benders/val22/lib/valgrind"\"
-DKICKSTART_BASE=3D0xb0000000 -I/usr/src/linux-2.4/include/ -Winline
-Wall -Wshadow -O -fno-omit-frame-pointer -mpreferred-stack-boundary=3D2
-g -DELFSZ=3D32 -MT vg_syscalls.o -MD -MP -MF ".deps/vg_syscalls.Tpo" =
-c
-o vg_syscalls.o vg_syscalls.c; \
then mv -f ".deps/vg_syscalls.Tpo" ".deps/vg_syscalls.Po"; else rm -f
".deps/vg_syscalls.Tpo"; exit 1; fi
vg_syscalls.c:493: warning: `struct sockaddr_in' declared inside
parameter list
vg_syscalls.c:493: warning: its scope is only this definition or
declaration, which is probably not what you want.
vg_syscalls.c: In function `inet2name':
vg_syscalls.c:498: dereferencing pointer to incomplete type
vg_syscalls.c:506: dereferencing pointer to incomplete type
vg_syscalls.c:506: dereferencing pointer to incomplete type
vg_syscalls.c:506: dereferencing pointer to incomplete type
/usr/src/linux-2.4/include/linux/byteorder/swab.h:132: warning: inlining
failed in call to `__fswab16'
vg_syscalls.c:506: warning: called from here
vg_syscalls.c: In function `getsockdetails':
vg_syscalls.c:523: field `in' has incomplete type
vg_syscalls.c:525: confused by earlier errors, bailing out
Sincerely Borg Enders
|
|
From: Naveen K. <g_n...@ya...> - 2004-09-14 21:44:12
|
Hi all,
Below(far below) is my previous post regarding
this. On further investigation I found that the "spin"
in VG_(st_basetype) [vg_symtypes.c] was because
type = type->u.t_typedef.type = SymType pointer passed
in the below function. Hence the spin forever.
SymType *VG_(st_basetype)(SymType *type, Bool
do_resolve)
{
while (type->kind == TyTypedef || (do_resolve &&
type->kind == TyUnresolved)) {
if (do_resolve)
resolve(type);
if (type->kind == TyTypedef)
{
type = type->u.t_typedef.type;
}
}
return type;
}
The symbol that was being parsed below had already
been parsed previously and I found that the
type->u.t_typedef.type was being set in
VG_(st_mktypedef) [vg_symtypes.c] which in turn was
being called from structDef [vg_stabs.c].
So I do a simple check before calling st_mktypedef
from structDef so that recursion is avoided as shown
below. After making the below change I find that the
program in question could executed by valgrind(and
already it has found some problems!!!).
static SymType *structDef(StabTypeTab *tab, SymType
*def, Bool isstruct, Char *name)
{
static const Bool debug = False;
SymType *ref = structRef(tab, NULL, isstruct,
name);
if (debug)
VG_(printf)("defining %s ref for %s %p -> %p\n",
isstruct ? "struct" : "union", name,
ref, def);
if( ref != def)
def = VG_(st_mktypedef)(ref, name,
VG_(st_basetype)(def, False));
VG_(st_setname)(def, name);
return def;
}
I am not sure if the above is the correct thing to do
but it works and I hope it would atleast shed some
light and pave the way for correcting it.
Thanks
Naveen
--- Nicholas Nethercote <nj...@ca...> wrote:
> On Thu, 9 Sep 2004, Naveen Kumar wrote:
>
> > I had posted earlier about valgrind stalling but
> > since nobody seemed to have encountered it I
> decided
> > to try investigating myself. I turned on some of
> the
> > debug flags and added some printf statements at
> some
> > points in the code. I find that valgrind is going
> into
> > an infinite loop in one place. These are the debug
> > statements before it stalls
> >
> > initSym(si=0xB02ED020, tab=0xB02FD120,
> sym=0xB17416F8,
> > kind=128, name=0xB0AC6C46
> "msgbuf:Tt(0,27)=xsmsgbuf:",
> > val=0)
> >
> > initSym name="msgbuf" type=Tt(0,27)=xsmsgbuf:
> > initSym: before base type
> >
> > I added the following printfs in vg_stabs.c
> > VG_(printf)("initSym: before base type\n");
> > base = VG_(st_basetype)(sym->type, False);
> > VG_(printf)("initSym: after base type\n");
> >
> > As can be seen from the logs I dont get anything
> > printed after "..before base type..". It is just
> > spinning in VG_(st_basetype).
>
> Can you file a bug report for this please?
>
> Thanks.
>
> N
>
>
>
__________________________________
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail
|
|
From: Astakhov, I. <igo...@in...> - 2004-09-14 13:49:04
|
[iastakh@svtipp018 issue261353]$ valgrind --tool=3Dmemcheck mtest valgrind: Couldn't allocate address space for shadow memory valgrind: Are you using a kernel with a small user address space, valgrind: or do you have your virtual memory size limited? =20 What does it mean?=20 =20 Igor =20 |
|
From: Nicholas N. <nj...@ca...> - 2004-09-13 15:13:45
|
On Mon, 13 Sep 2004, Josef Weidendorfer wrote: > ==1258== Process terminating with default action of signal 11 (SIGSEGV) > ==1258== Access not within mapped region at address 0xF30000C > ==1258== at 0x3AA57282: (within /lib/libc-2.3.2.so) > ==1258== by 0x3AA5607E: free (in /lib/libc-2.3.2.so) > ==1258== by 0x8050691: CBodyList_GetElem (cbody_list.c:126) > [...] > Any idea how to track this down further? I'm happy to take a look at it with Cachegrind if a test case can be produced. N |
|
From: Dennis L. <pla...@tz...> - 2004-09-13 13:30:05
|
Am Mo, den 13.09.2004 schrieb Nicholas Nethercote um 15:15: > > What are "parsing errors in the configs"? Some -v output would help here. I probably wasnt clear enough, its an error from the program Im running, not from valgrind. Thats why it is currently hard for me to track this down, since this code is hard to read, and I dont know where it could have problems. But its definetly happening only on memcheck/addrcheck etc. not on the others I mentioned. So I would be glad for some hints how to use valgrind to track this down, since something must be different when running the different tools... greets Dennis |
|
From: Nicholas N. <nj...@ca...> - 2004-09-13 13:15:47
|
On Mon, 13 Sep 2004, Dennis Lubert wrote: > I have now tried the 2.2 release and CVS, and after the bug with > memcheck/addrcheck consuming tons of memory, which should be fixed in CVS now > I encountered another bug. > Im trying to port a program to 64Bit, and before doing it, tried to fix > all bugs in a 32Bit environment I can find. So I wanted to run it under > valgrind, but it refused to start, with some parsing errors in the > configs. What are "parsing errors in the configs"? Some -v output would help here. > This only happend when I run it under addrcheck, memcheck or > massif tool, but not under cachegrind, lackey or nullgrind. > Memcheck does not show any errors, except two possible memory leaks. So > I suspect some bug in the part of memcheck. > Unfortunately I wasnt yet able to check what exactly the difference is > between the two runs, and so not able to produce any sample code that > makes the error clearer. > But perhaps there is also some bug known, or people working on, or some > have idea where a bug could be ? Or perhaps you could give me some hints > how to run valgrind to track down the problem ? N |
|
From: Dennis L. <pla...@tz...> - 2004-09-13 12:57:08
|
Hello, I have now tried the 2.2 release and CVS, and after the bug with memcheck/addrcheck consuming tons of memory, I encountered another bug. Im trying to port a program to 64Bit, and before doing it, tried to fix all bugs in a 32Bit environment I can find. So I wanted to run it under valgrind, but it refused to start, with some parsing errors in the configs. This only happend when I run it under addrcheck, memcheck or massif tool, but not under cachegrind, lackey or nullgrind. Memcheck does not show any errors, except two possible memory leaks. So I suspect some bug in the part of memcheck. Unfortunately I wasnt yet able to check what exactly the difference is between the two runs, and so not able to produce any sample code that makes the error clearer. But perhaps there is also some bug known, or people working on, or some have idea where a bug could be ? Or perhaps you could give me some hints how to run valgrind to track down the problem ? greets Dennis |
|
From: Josef W. <Jos...@gm...> - 2004-09-13 12:29:46
|
Hi, I have a strange bug here. This was a bug report for calltree/callgrind, bu= t=20 it seems not to be a bug in my code, as it is happening with cachegrind, to= o. The bug reporter is running Valgrind 2.2.0 on Debian testing. The faulting address in the report below (0x3AA57282) is in the middle of a= =20 basic block with 11 instructions, as can be seen in debug output from=20 callgrind: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D BB# 11326449 =2D setup_bbcc (BB 0x3AA57275): Instrs 11 (Len 34) log_1Dr: iaddr=3D0x3AA57275, isize=3D3, daddr=3D0x8160F50, dsize=3D4 log_0D: iaddr=3D0x3AA57278, isize=3D2 log_0D: iaddr=3D0x3AA5727A, isize=3D2 log_1Dr: iaddr=3D0x3AA5727C, isize=3D3, daddr=3D0x8160EE6, dsize=3D4 log_1Dr: iaddr=3D0x3AA5727F, isize=3D3, daddr=3D0x8160EEA, dsize=3D4 =3D=3D1258=3D=3D=20 =3D=3D1258=3D=3D Process terminating with default action of signal 11 (SIGS= EGV) =3D=3D1258=3D=3D Access not within mapped region at address 0xF30000C =3D=3D1258=3D=3D at 0x3AA57282: (within /lib/libc-2.3.2.so) =3D=3D1258=3D=3D by 0x3AA5607E: free (in /lib/libc-2.3.2.so) =3D=3D1258=3D=3D by 0x8050691: CBodyList_GetElem (cbody_list.c:126) =2E.. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =46rom further debug output, one can see that this BB maps to=20 libc-2.3.2.so +0x72275=3D0x3AA57275, and that is the relevant code: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > objdump -D --start-address=3D0x72270 /lib/libc-2.3.2.so|head -70 /lib/libc-2.3.2.so: file format elf32-i386 00072270 <.text+0x5c690>: 72270: 89 45 e8 mov %eax,0xffffffe8(%ebp) 72273: 75 13 jne 0x72288 72275: 8b 47 f8 mov 0xfffffff8(%edi),%eax 72278: 29 c1 sub %eax,%ecx 7227a: 01 c6 add %eax,%esi 7227c: 8b 51 08 mov 0x8(%ecx),%edx 7227f: 8b 41 0c mov 0xc(%ecx),%eax 72282: 89 42 0c mov %eax,0xc(%edx) <=3D SEGFAULT happening here 72285: 89 50 08 mov %edx,0x8(%eax) 72288: 8b 55 f0 mov 0xfffffff0(%ebp),%edx 7228b: 8b 7d ec mov 0xffffffec(%ebp),%edi 7228e: 3b 7a 54 cmp 0x54(%edx),%edi 72291: 0f 84 cb 00 00 00 je 0x72362 72297: 8b 45 e8 mov 0xffffffe8(%ebp),%eax 7229a: f6 44 38 04 01 testb $0x1,0x4(%eax,%edi,1) 7229f: 0f 85 ab 00 00 00 jne 0x72350 =2E.. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Interesting is that it also happens with "callgrind --simulate-cache=3Dno .= =2E.".=20 In this mode, I only have instrumented a call to a helper at the beginning = of=20 the BB. Thus, the segfault seems to be triggered by the valgrind generated= =20 code itself. Any idea how to track this down further? Josef Subject: Re: Bug#231095: valgrind-calltree: calltree terminates with SIGSEV= on=20 call to calloc. Date: Samstag, 11. September 2004 00:17 =46rom: Shan Mignot <sha...@fr...> To: Josef Weidendorfer <Jos...@gm...> I'm using: libc6 2.3.2ds1-1 from debian testing. My program is compiled with: gcc.real (GCC) 3.3.4 (Debian 1:3.3.4-6sarge1). I tried running callgrind without the cache simulation (callgring =2D-simulate-cache=3Dno) and running cachegrind (valgrind --tool=3Dcachegri= nd). Both segfault at precisely the same location ie: =3D=3D544=3D=3D Process terminating with default action of signal 11 (SIGSE= GV) =3D=3D544=3D=3D Access not within mapped region at address 0xF30000C =3D=3D544=3D=3D at 0x3AA57282: (within /lib/libc-2.3.2.so) =3D=3D544=3D=3D by 0x3AA5607E: free (in /lib/libc-2.3.2.so) =3D=3D544=3D=3D by 0x8050691: CBodyList_GetElem (cbody_list.c:126) Here's the dump from libc: > objdump -D --start-address=3D0x72270 /lib/libc-2.3.2.so|head -70 >| > libc.so.dump /lib/libc-2.3.2.so: file format elf32-i386 Disassembly of section .note.ABI-tag: Disassembly of section .hash: Disassembly of section .dynsym: Disassembly of section .dynstr: Disassembly of section .gnu.version: Disassembly of section .gnu.version_d: Disassembly of section .gnu.version_r: Disassembly of section .rel.dyn: Disassembly of section .rel.plt: Disassembly of section .plt: Disassembly of section .text: 00072270 <.text+0x5c690>: 72270: 89 45 e8 mov %eax,0xffffffe8(%ebp) 72273: 75 13 jne 0x72288 72275: 8b 47 f8 mov 0xfffffff8(%edi),%eax 72278: 29 c1 sub %eax,%ecx 7227a: 01 c6 add %eax,%esi 7227c: 8b 51 08 mov 0x8(%ecx),%edx 7227f: 8b 41 0c mov 0xc(%ecx),%eax 72282: 89 42 0c mov %eax,0xc(%edx) 72285: 89 50 08 mov %edx,0x8(%eax) 72288: 8b 55 f0 mov 0xfffffff0(%ebp),%edx 7228b: 8b 7d ec mov 0xffffffec(%ebp),%edi 7228e: 3b 7a 54 cmp 0x54(%edx),%edi 72291: 0f 84 cb 00 00 00 je 0x72362 72297: 8b 45 e8 mov 0xffffffe8(%ebp),%eax 7229a: f6 44 38 04 01 testb $0x1,0x4(%eax,%edi,1) 7229f: 0f 85 ab 00 00 00 jne 0x72350 722a5: 8b 47 0c mov 0xc(%edi),%eax 722a8: 8b 57 08 mov 0x8(%edi),%edx 722ab: 89 42 0c mov %eax,0xc(%edx) 722ae: 89 50 08 mov %edx,0x8(%eax) 722b1: 8b 45 e8 mov 0xffffffe8(%ebp),%eax 722b4: 01 c6 add %eax,%esi 722b6: 89 34 0e mov %esi,(%esi,%ecx,1) 722b9: 8b 45 f0 mov 0xfffffff0(%ebp),%eax 722bc: 83 c0 5c add $0x5c,%eax 722bf: 89 41 0c mov %eax,0xc(%ecx) 722c2: 8b 50 08 mov 0x8(%eax),%edx 722c5: 89 51 08 mov %edx,0x8(%ecx) 722c8: 89 48 08 mov %ecx,0x8(%eax) 722cb: 89 f0 mov %esi,%eax 722cd: 83 c8 01 or $0x1,%eax 722d0: 89 4a 0c mov %ecx,0xc(%edx) 722d3: 89 41 04 mov %eax,0x4(%ecx) 722d6: 81 fe ff ff 00 00 cmp $0xffff,%esi 722dc: 0f 86 6b ff ff ff jbe 0x7224d 722e2: 8b 55 f0 mov 0xfffffff0(%ebp),%edx 722e5: f6 42 28 01 testb $0x1,0x28(%edx) 722e9: 74 5b je 0x72346 722eb: 8d 83 70 0a 00 00 lea 0xa70(%ebx),%eax 722f1: 39 45 f0 cmp %eax,0xfffffff0(%ebp) 722f4: 74 1d je 0x72313 722f6: 8b 55 f0 mov 0xfffffff0(%ebp),%edx 722f9: 8b 42 54 mov 0x54(%edx),%eax 722fc: 8b 93 f4 0e 00 00 mov 0xef4(%ebx),%edx 72302: 83 c4 24 add $0x24,%esp 72305: 25 00 00 f0 ff and $0xfff00000,%eax 7230a: 5b pop %ebx 7230b: 5e pop %esi 7230c: 5f pop %edi 7230d: 5d pop %ebp 7230e: e9 ed cf ff ff jmp 0x6f300 72313: 8b 83 c4 0a 00 00 mov 0xac4(%ebx),%eax 72319: 8b 40 04 mov 0x4(%eax),%eax 7231c: 83 e0 f8 and $0xfffffff8,%eax Hope that helps. Please keep informed, I'd like to understand what is going on. Shan =2D------------------------------------------------------ |
|
From: Tom H. <th...@cy...> - 2004-09-13 11:46:29
|
In message <Pin...@he...>
Nicholas Nethercote <nj...@ca...> wrote:
> On Mon, 13 Sep 2004, Nicholas Nethercote wrote:
>
>>> I had posted earlier about valgrind stalling but
>>> since nobody seemed to have encountered it I decided
>>> to try investigating myself. I turned on some of the
>>> debug flags and added some printf statements at some
>>> points in the code. I find that valgrind is going into
>>> an infinite loop in one place. These are the debug
>>> statements before it stalls
>>> initSym(si=0xB02ED020, tab=0xB02FD120, sym=0xB17416F8,
>>> kind=128, name=0xB0AC6C46 "msgbuf:Tt(0,27)=xsmsgbuf:",
>>> val=0)
>>> initSym name="msgbuf" type=Tt(0,27)=xsmsgbuf:
>>> initSym: before base type
>>> I added the following printfs in vg_stabs.c
>>> VG_(printf)("initSym: before base type\n");
>>> base = VG_(st_basetype)(sym->type, False);
>>> VG_(printf)("initSym: after base type\n");
>>> As can be seen from the logs I dont get anything
>>> printed after "..before base type..". It is just
>>> spinning in VG_(st_basetype).
>>
>> Can you file a bug report for this please?
>
> Actually, it might be more appropriate to add a comment to
> http://bugs.kde.org/show_bug.cgi?id=88703 explaining your situation (I
> think that's the bug you're talking about?)
Why? That bug isn't about a stall, it's about a warning from
the stabs reader. I'm not aware of any reason to believe that
the two are linked.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|