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
(5) |
2
(5) |
3
(3) |
|
4
|
5
(4) |
6
(6) |
7
(4) |
8
(14) |
9
(2) |
10
(4) |
|
11
(2) |
12
(2) |
13
(4) |
14
(7) |
15
(5) |
16
(11) |
17
(4) |
|
18
|
19
(10) |
20
(4) |
21
(13) |
22
(6) |
23
(6) |
24
(4) |
|
25
(5) |
26
(18) |
27
(7) |
28
(10) |
29
(11) |
30
(17) |
|
|
From: Lee D. <lee...@mi...> - 2004-04-15 16:51:20
|
> What goes wrong? Can you show the output of "valgrind -v" > for a sample > prog, plus the output of "uname -a"? Thanks. [root@localhost TUG]# uname -a Linux localhost.localdomain 2.4.18-27.7.x #1 Fri Mar 14 06:44:53 EST 2003 i686 unknown [root@localhost TUG]# valgrind -v --tool=memcheck ls ==13655== Memcheck, a memory error detector for x86-linux. ==13655== Copyright (C) 2002-2004, and GNU GPL'd, by Julian Seward. ==13655== Using valgrind-2.1.2.CVS, a program supervision framework for x86-linux. ==13655== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward. ==13655== Valgrind library directory: /usr/local/lib/valgrind ==13655== Command line ==13655== ls ==13655== Startup, with flags: ==13655== -v ==13655== --tool=memcheck ==13655== Reading syms from /bin/ls (0x8048000) ==13655== object doesn't have a symbol table ==13655== object doesn't have any debug info --13655-- INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV) - exiting --13655-- si_code=1 Fault EIP: 0xB030B4BC (); Faulting address: 0x50100000 valgrind: the `impossible' happened: Killed by fatal signal Basic block ctr is approximately 0 ==13655== at 0xB802BF5F: ??? ==13655== by 0xB802BF5E: ??? ==13655== by 0xB802BF74: ??? ==13655== by 0xB803288F: ??? sched status: Thread 1: status = Runnable, associated_mx = 0x0, associated_cv = 0x0 ==13655== at 0x3C000B50: ??? Note: see also the FAQ.txt in the source distribution. It contains workarounds to several common problems. If that doesn't help, please report this bug to: valgrind.kde.org In the bug report, send all the above text, the valgrind version, and what Linux distro you are using. Thanks. [root@localhost TUG]# |
|
From: Nicholas N. <nj...@ca...> - 2004-04-15 16:27:30
|
On Thu, 15 Apr 2004, Lee Dilkie wrote: > I created a little test program that calls sem_init/sem_destroy. I can do 50 > of these before vg barfs with a message to increase VG_N_SEMAPHORES. > > Every call to sem_destroy() generates a "KLUDGED call to: sem_destroy" > message. > > So is it me or does vg's sem_destry not recover the semaphore for later > reuse? I think this is fixed in later versions, 2.1.1 should have it, or definitely the cvs head. > Also... :)... I tried cvs-ing the latest (head) and the previous (2.1.1) > versions but they never worked at all. I'm running rh 7.3. If someone tells > me that this does work, I'll spend the effort to figure out how. What goes wrong? Can you show the output of "valgrind -v" for a sample prog, plus the output of "uname -a"? Thanks. N |
|
From: Lee D. <lee...@mi...> - 2004-04-15 16:19:13
|
Hi folks! I'm using valgrind 2.0.0 and I'm trying to track down an issue with OpenSSL but I came across this *other* problem. I created a little test program that calls sem_init/sem_destroy. I can do 50 of these before vg barfs with a message to increase VG_N_SEMAPHORES. Every call to sem_destroy() generates a "KLUDGED call to: sem_destroy" message. So is it me or does vg's sem_destry not recover the semaphore for later reuse? Also, does anyone have a magic bullet (like a patch to openssl) to stop all those "uninitialized memory" errors that VG reports when doeing ssl operations? Also... :)... I tried cvs-ing the latest (head) and the previous (2.1.1) versions but they never worked at all. I'm running rh 7.3. If someone tells me that this does work, I'll spend the effort to figure out how. Thanks, -lee This footnote confirms that either (1) this email message has been swept by Baltimore MIMEsweeper for Content Security threats, including computer viruses, (2) this email message was sent by a virus that appends this footnote, or (3) (most likely) the sender of this message is trying to raise awareness of how foolish it would be to place any confidence in footnotes like this. |
|
From: Nicholas N. <nj...@ca...> - 2004-04-15 07:55:55
|
On Wed, 14 Apr 2004, David Hawkins wrote:
> I just learned about valgrind today, so went to put
> it to the test.
>
> ==21781== 16 bytes in 1 blocks are still reachable in loss record 1 of 2
> ==21781== at 0x3C01E9D3: calloc (vg_replace_malloc.c:141)
> ==21781== by 0x3C063360: _dlerror_run (in /lib/libdl-2.3.2.so)
> ==21781== by 0x3C063023: dlsym (in /lib/libdl-2.3.2.so)
> ==21781== by 0x3C026F9C: pthread_create (vg_libpthread.c:906)
This block is still reachable, and so isn't a problem. If you don't want
to hear about it, don't use --show-reachable=yes.
> ==21781== 200 bytes in 1 blocks are definitely lost in loss record 2 of 2
> ==21781== at 0x3C01E250: malloc (vg_replace_malloc.c:105)
> ==21781== by 0x3C025DF6: my_malloc (vg_libpthread.c:334)
> ==21781== by 0x3C028AAA: get_or_allocate_specifics_ptr
> (vg_libpthread.c:1591)
> ==21781== by 0x3C028C33: pthread_key_create (vg_libpthread.c:1628)
This is an leak in Valgrind's libpthread; there's meant to be a
suppression for it (the leak is in our code, not yours) but it doesn't
seem to be working. In default.supp (should be wherever Valgrind is
installed), change this suppression:
{
my_malloc/get_or_allocate_specifics_ptr/pthread_key_create(Leak)
Memcheck:Leak
fun:my_malloc
fun:get_or_allocate_specifics_ptr
fun:pthread_key_create
}
to this:
{
my_malloc/get_or_allocate_specifics_ptr/pthread_key_create(Leak)
Memcheck:Leak
fun:malloc
fun:my_malloc
fun:get_or_allocate_specifics_ptr
fun:pthread_key_create
}
which should get rid of it.
> I'd like to start using Valgrind on more thread-based code.
> What are my options here?
Is that enough to get you going?
N
|
|
From: Nicholas N. <nj...@ca...> - 2004-04-15 07:51:44
|
On Wed, 14 Apr 2004, David Hawkins wrote: > I just learned about valgrind today, so went to put > it to the test. > > I used the helgrind option to see what race conditions > it could catch ... here's an example of what I believe > is thread-safe, yet generates valgrind errors. Helgrind is quite fallible, unfortunately, and generates a lot of false positives. N |
|
From: David H. <dw...@ov...> - 2004-04-14 23:35:55
|
Hi,
I just learned about valgrind today, so went to put
it to the test.
I used the helgrind option to see what race conditions
it could catch ... here's an example of what I believe
is thread-safe, yet generates valgrind errors.
/*
* two_threads_stdio.c
*
* A simple test of two threads (main and another) both
* accessing stderr through a thread-safe function.
*
* valgrind was complaining about race conditions in some of
* my other code. So here is a minimal version that uses a
* protected printf in two threads - lets see if helgrind
* complains.
*
*/
#include <stdio.h>
#include <unistd.h>
#include <stdlib.h>
#include <stdarg.h>
#include <pthread.h>
/* Threads */
void *another_thread(void *arg);
/* Thread-safe debug */
static pthread_mutex_t stdio_mutex = PTHREAD_MUTEX_INITIALIZER;
static void debug(const char *format, ...);
/* Main thread */
int main()
{
pthread_t thread_id;
int status;
/* Start another thread */
debug("Main: Creating another thread.\n");
status = pthread_create(&thread_id, NULL, another_thread, NULL);
if (status) {
debug("Main: Thread creation failed!");
return 1;
}
/* Stop the other thread */
debug("Main: Waiting for the other thread\n");
pthread_join(thread_id, NULL);
if (status) {
debug("Main: Thread join failed!");
return 1;
}
debug("Main: Joined ok\n");
return 0;
}
void* another_thread(void *arg)
{
debug("Thread: Started\n");
debug("Thread: Sleeping for 2s\n");
sleep(2);
debug("Thread: Exiting\n");
return NULL;
}
/* Thread-safe printf */
static void debug(const char *format, ...)
{
va_list arg;
pthread_mutex_lock(&stdio_mutex);
va_start(arg, format);
vfprintf(stderr, format, arg);
va_end(arg);
(void)pthread_mutex_unlock(&stdio_mutex);
return;
}
==22213== Helgrind, a data race detector for x86-linux.
==22213== Copyright (C) 2002-2004, and GNU GPL'd, by Nicholas Nethercote.
==22213== Using valgrind-2.1.1, a program supervision framework for
x86-linux.
==22213== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward.
==22213== For more details, rerun with: -v
==22213==
Main: Creating another thread.
Main: Waiting for the other thread
Thread: Started
Thread: Sleeping for 2s
Thread: Exiting
Main: Joined ok
==22213== Possible data race reading variable at 0x4212E150
(_IO_stdfile_2_lock+8)
==22213== at 0x420701A4: _IO_flush_all_lockp (in /lib/tls/libc-2.3.2.so)
==22213== by 0x4207031F: _IO_flush_all_internal (in
/lib/tls/libc-2.3.2.so)
==22213== by 0x42070518: _IO_cleanup (in /lib/tls/libc-2.3.2.so)
==22213== by 0x42029C61: exit (in /lib/tls/libc-2.3.2.so)
==22213== Address 0x4212E150 is in data section of /lib/tls/libc-2.3.2.so
==22213== Previous state: shared RW, locked by:0x80497DC(stdio_mutex)
==22213==
==22213== Possible data race reading variable at 0x4212E14C
(_IO_stdfile_2_lock+4)
==22213== at 0x420701C0: _IO_flush_all_lockp (in /lib/tls/libc-2.3.2.so)
==22213== by 0x4207031F: _IO_flush_all_internal (in
/lib/tls/libc-2.3.2.so)
==22213== by 0x42070518: _IO_cleanup (in /lib/tls/libc-2.3.2.so)
==22213== by 0x42029C61: exit (in /lib/tls/libc-2.3.2.so)
==22213== Address 0x4212E14C is in data section of /lib/tls/libc-2.3.2.so
==22213== Previous state: shared RW, locked by:0x80497DC(stdio_mutex)
==22213==
==22213== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 2 from 2)
==22213== 4 possible data races found; 0 lock order problems
I believe all of these complains are caused by code encapsulated
in the locked mutex, hence they are thread-safe. Any reason why
this mutex locking is not being detected.
Cheers
Dave Hawkins
Caltech.
|
|
From: David H. <dw...@ov...> - 2004-04-14 21:43:54
|
Hi,
I just learned about valgrind today, so went to put
it to the test.
With the following test file:
/*--------------------------------------------------------------------------
* two_threads.c
*
* A simple test of two threads (main and another).
*
* The purpose of this test was to see whether valgrind complains.
*
* gcc -o two_threads two_threads.c -lpthread
* valgrind --tool=memcheck --leak-check=yes --show-reachable=yes
two_threads
*
*/
#include <stdio.h>
#include <unistd.h>
#include <stdlib.h>
#include <pthread.h>
/* Threads */
void *another_thread(void *arg);
/* Main thread */
int main()
{
pthread_t thread_id;
int status;
/* start another thread */
printf("Main: Creating another thread.\n");
status = pthread_create(&thread_id, NULL, another_thread, NULL);
if (status) {
fprintf(stderr, "Main: Thread creation failed!");
return 1;
}
/* Stop the other thread */
printf("Main: Waiting for the other thread\n");
pthread_join(thread_id, NULL);
if (status) {
fprintf(stderr, "Main: Thread join failed!");
return 1;
}
printf("Main: Joined ok\n");
return 0;
}
void* another_thread(void *arg)
{
printf("Thread: Started\n");
printf("Thread: Sleeping for 2s\n");
sleep(2);
printf("Thread: Exiting\n");
return NULL;
}
/*--------------------------------------------------------------------------
*/
The output of Valgrind is:
==21781== Memcheck, a memory error detector for x86-linux.
==21781== Copyright (C) 2002-2004, and GNU GPL'd, by Julian Seward.
==21781== Using valgrind-2.1.1, a program supervision framework for
x86-linux.
==21781== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward.
==21781== For more details, rerun with: -v
==21781==
Main: Creating another thread.
Main: Waiting for the other thread
Thread: Started
Thread: Sleeping for 2s
Thread: Exiting
Main: Joined ok
==21781==
==21781== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 15 from 1)
==21781== malloc/free: in use at exit: 216 bytes in 2 blocks.
==21781== malloc/free: 5 allocs, 3 frees, 2004 bytes allocated.
==21781== For counts of detected errors, rerun with: -v
==21781== searching for pointers to 2 not-freed blocks.
==21781== checked 1597296 bytes.
==21781==
==21781== 16 bytes in 1 blocks are still reachable in loss record 1 of 2
==21781== at 0x3C01E9D3: calloc (vg_replace_malloc.c:141)
==21781== by 0x3C063360: _dlerror_run (in /lib/libdl-2.3.2.so)
==21781== by 0x3C063023: dlsym (in /lib/libdl-2.3.2.so)
==21781== by 0x3C026F9C: pthread_create (vg_libpthread.c:906)
==21781==
==21781==
==21781== 200 bytes in 1 blocks are definitely lost in loss record 2 of 2
==21781== at 0x3C01E250: malloc (vg_replace_malloc.c:105)
==21781== by 0x3C025DF6: my_malloc (vg_libpthread.c:334)
==21781== by 0x3C028AAA: get_or_allocate_specifics_ptr
(vg_libpthread.c:1591)
==21781== by 0x3C028C33: pthread_key_create (vg_libpthread.c:1628)
==21781==
==21781== LEAK SUMMARY:
==21781== definitely lost: 200 bytes in 1 blocks.
==21781== possibly lost: 0 bytes in 0 blocks.
==21781== still reachable: 16 bytes in 1 blocks.
==21781== suppressed: 0 bytes in 0 blocks.
Which points to the leak in pthread_create() etc.
I looked on the mailing list archive and saw a comment about
the same error posted last month. However, their example code
did not use pthread_join() so I thought perhaps that might
be the issue. However, here the thread is joined successfully
before main exits, so the thread resources should have been
reclaimed.
I'd like to start using Valgrind on more thread-based code.
What are my options here?
Regards
Dave Hawkins
Caltech.
|
|
From: Suresh Sundararaman-A. <Sun...@mo...> - 2004-04-14 11:59:27
|
Is valgrind tool available for Symbian O.S? Is there any plan to make it available for Symbian? Thanks Suresh |
|
From: Nicholas N. <nj...@ca...> - 2004-04-14 10:10:41
|
On Wed, 14 Apr 2004, Banibrata Dutta wrote: > how does one file a valgrind bug ?? at the bugzilla site, the options > seem to be only to file kde bugs, and the submodules list doesn't > contain valgrind!! See valgrind.kde.org/bugs.html. You won't need to file a report for your bug though, as it already has a report. N |
|
From: Banibrata D. <du...@in...> - 2004-04-14 10:08:11
|
how does one file a valgrind bug ?? at the bugzilla site, the options seem to be only to file kde bugs, and the submodules list doesn't contain valgrind!! not sure if this makes sense... BD > -----Original Message----- > From: val...@li... > [mailto:val...@li...] On Behalf > Of Nicholas Nethercote > Sent: Wednesday, April 14, 2004 2:51 PM > To: Banibrata Dutta > Cc: val...@li... > Subject: Re: [Valgrind-users] problems with STL ! > > > On Wed, 14 Apr 2004, Banibrata Dutta wrote: > > > i have a simple C++ program that uses STL. "valgrind" seems > to crash > > on it. what is the reason ? is there any workaround ? > > > > @@ don't know what type '_' is > > See the bug report at bugs.kde.org/show_bug.cgi?id=77869. > Jeremy just committed a fix, so try the current CVS version > (see valgrind.kde.org/cvs.html for how). > > N > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IBM Linux Tutorials > Free Linux tutorial presented by Daniel Robbins, President > and CEO of GenToo technologies. Learn everything from > fundamentals to system > administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click > _______________________________________________ > Valgrind-users mailing list Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > |
|
From: Nicholas N. <nj...@ca...> - 2004-04-14 09:21:24
|
On Wed, 14 Apr 2004, Banibrata Dutta wrote: > i have a simple C++ program that uses STL. "valgrind" seems to crash on it. > what is the reason ? is there any workaround ? > > @@ don't know what type '_' is See the bug report at bugs.kde.org/show_bug.cgi?id=77869. Jeremy just committed a fix, so try the current CVS version (see valgrind.kde.org/cvs.html for how). N |
|
From: Banibrata D. <du...@in...> - 2004-04-14 04:10:14
|
hi,
=20
i have a simple C++ program that uses STL. "valgrind" seems to crash on =
it.
what is the reason ? is there any workaround ?
=20
<program-start>
=20
#include <map>
#include <functional>
#include <utility>
#include <iostream>
using namespace std;
=20
typedef pair<int,int> int_pair;
=20
class data_type {
public:
data_type(int_pair* p, char d) : key_part(p), data(d) {}
data_type(char d) : key_part(0), data(d) {}
data_type() : key_part(0), data(0) {}
int_pair* getKey() { return key_part;}
char getData() {return data;}
private:
int_pair *key_part;
char data;
};
=20
typedef map<int_pair,data_type> ip_map;
=20
int main()
{
ip_map _map;
data_type *_dt=3D0;
=20
int_pair *key=3D0;
=20
for (int i=3D0,j=3D3; i < 5; i+=3D2, j++)
{
key =3D new int_pair(i, j);
_dt =3D new data_type(key, ('a' + char(i)));
_map[*key] =3D *_dt;
}
=20
for (ip_map::iterator iter =3D _map.begin(); iter !=3D =
_map.end();
iter++)
{
cout << "map[" << iter->first.first << "," <<
iter->first.second << "] =3D (" <<
iter->second.getKey() << ", " <<
iter->second.getData() << ")" << endl;
}
return 0;
}
</program-stop>
=20
=20
<valgrind-output-start>
[dutta@pttlnx1 maps]$ valgrind --tool=3Dmemcheck -v --demangle=3Dyes =
./a.out=20
=3D=3D24620=3D=3D Memcheck, a memory error detector for x86-linux.
=3D=3D24620=3D=3D Copyright (C) 2002-2004, and GNU GPL'd, by Julian =
Seward.
=3D=3D24620=3D=3D Using valgrind-2.1.1, a program supervision framework =
for
x86-linux.
=3D=3D24620=3D=3D Copyright (C) 2000-2004, and GNU GPL'd, by Julian =
Seward.
=3D=3D24620=3D=3D Valgrind library directory: /usr/local/lib/valgrind
=3D=3D24620=3D=3D Command line
=3D=3D24620=3D=3D ./a.out
=3D=3D24620=3D=3D Startup, with flags:
=3D=3D24620=3D=3D --tool=3Dmemcheck
=3D=3D24620=3D=3D -v
=3D=3D24620=3D=3D --demangle=3Dyes
=3D=3D24620=3D=3D Reading syms from /home/dutta/work/cpp_prac/maps/a.out =
(0x8048000)
@@ don't know what type '_' is
@@ parsing
__rf__Ct17_Rb_tree_iterator3Zt4pair2ZCt4pair2ZiZiZ9data_typeZRt4pair2ZCt4=
pai
r2ZiZiZ9data_typeZPt4pair2
ZCt4pair2ZiZiZ9data_type;2B.;operator++::(0,187)=3D##(0,179);:__pp__t17_R=
b_tre
e_iterator3Zt4pair2ZCt4pair2ZiZiZ9data
_typeZRt4pair2ZCt4pair2ZiZiZ9data_typeZPt4pair2ZCt4pair2ZiZiZ9data_type;2=
A.(
0,188)=3D##(0,105);:__pp__t17_Rb_tree_it
erator3Zt4pair2ZCt4pair2ZiZiZ9data_typeZRt4pair2ZCt4pair2ZiZiZ9data_typeZ=
Pt4
pair2ZCt4pair2ZiZiZ9data_typei;2A.;ope
rator--::(0,187):__mm__t17_Rb_tree_iterator3Zt4pair2ZCt4pair2ZiZiZ9data_t=
ype
ZRt4pair2ZCt4pair2ZiZiZ9data_typeZPt4p
air2ZCt4pair2ZiZiZ9data_type;2A.(0,188):__mm__t17_Rb_tree_iterator3Zt4pai=
r2Z
Ct4pair2ZiZiZ9data_typeZRt4pair2ZCt4pa
ir2ZiZiZ9data_typeZPt4pair2ZCt4pair2ZiZiZ9data_typei;2A.;; gave NULL =
type
(_rf__Ct17_Rb_tree_iterator3Zt4pair2ZCt4
pair2ZiZiZ9data_typeZRt4pair2ZCt4pair2ZiZiZ9data_typeZPt4pair2ZCt4pair2Zi=
ZiZ
9data_type;2B.;operator++::(0,187)=3D##(
0,179);:__pp__t17_Rb_tree_iterator3Zt4pair2ZCt4pair2ZiZiZ9data_typeZRt4pa=
ir2
ZCt4pair2ZiZiZ9data_typeZPt4pair2ZCt4p
air2ZiZiZ9data_type;2A.(0,188)=3D##(0,105);:__pp__t17_Rb_tree_iterator3Zt=
4pair
2ZCt4pair2ZiZiZ9data_typeZRt4pair2ZCt4
pair2ZiZiZ9data_typeZPt4pair2ZCt4pair2ZiZiZ9data_typei;2A.;operator--::(0=
,18
7):__mm__t17_Rb_tree_iterator3Zt4pair2
ZCt4pair2ZiZiZ9data_typeZRt4pair2ZCt4pair2ZiZiZ9data_typeZPt4pair2ZCt4pai=
r2Z
iZiZ9data_type;2A.(0,188):__mm__t17_Rb
_tree_iterator3Zt4pair2ZCt4pair2ZiZiZ9data_typeZRt4pair2ZCt4pair2ZiZiZ9da=
ta_
typeZPt4pair2ZCt4pair2ZiZiZ9data_typei
;2A.;; remains)
=20
@@ expected ':' at struct method MANGLE-ARGS
(remains=3D"rf__Ct17_Rb_tree_iterator3Zt4pair2ZCt4pair2ZiZiZ9data_type
ZRt4pair2ZCt4pair2ZiZiZ9data_typeZPt4pair2ZCt4pair2ZiZiZ9data_type;2B.;op=
era
tor++::(0,187)=3D##(0,179);:__pp__t17_Rb
_tree_iterator3Zt4pair2ZCt4pair2ZiZiZ9data_typeZRt4pair2ZCt4pair2ZiZiZ9da=
ta_
typeZPt4pair2ZCt4pair2ZiZiZ9data_type;
2A.(0,188)=3D##(0,105);:__pp__t17_Rb_tree_iterator3Zt4pair2ZCt4pair2ZiZiZ=
9data
_typeZRt4pair2ZCt4pair2ZiZiZ9data_type
ZPt4pair2ZCt4pair2ZiZiZ9data_typei;2A.;operator--::(0,187):__mm__t17_Rb_t=
ree
_iterator3Zt4pair2ZCt4pair2ZiZiZ9data_
typeZRt4pair2ZCt4pair2ZiZiZ9data_typeZPt4pair2ZCt4pair2ZiZiZ9data_type;2A=
.(0
,188):__mm__t17_Rb_tree_iterator3Zt4pa
ir2ZCt4pair2ZiZiZ9data_typeZRt4pair2ZCt4pair2ZiZiZ9data_typeZPt4pair2ZCt4=
pai
r2ZiZiZ9data_typei;2A.;;")
@@ parsing
(0,105)=3Ds4!1,020,(2,9);operator=3D::(0,178)=3D##(0,179)=3D&(0,105);:__a=
s__t17_Rb_t
ree_iterator3Zt4pair2ZCt4p
air2ZiZiZ9data_typeZRt4pair2ZCt4pair2ZiZiZ9data_typeZPt4pair2ZCt4pair2ZiZ=
iZ9
data_typeRCt17_Rb_tree_iterator3Zt4pai
r2ZCt4pair2ZiZiZ9data_typeZRt4pair2ZCt4pair2ZiZiZ9data_typeZPt4pair2ZCt4p=
air
2ZiZiZ9data_type;2A.;_Rb_tree_iterator
::(0,180)=3D##(0,181)=3D*(0,105);:__t17_Rb_tree_iterator3Zt4pair2ZCt4pair=
2ZiZiZ9
data_typeZRt4pair2ZCt4pair2ZiZiZ9data_
typeZPt4pair2ZCt4pair2ZiZiZ9data_type;2A.(0,182)=3D##(0,181);:__t17_Rb_tr=
ee_it
erator3Zt4pair2ZCt4pair2ZiZiZ9data_typ
eZRt4pair2ZCt4pair2ZiZiZ9data_typeZPt4pair2ZCt4pair2ZiZiZ9data_typePt13_R=
b_t
ree_node1Zt4pair2ZCt4pair2ZiZiZ9data_t
ype;2A.(0,183)=3D##(0,181);:__t17_Rb_tree_iterator3Zt4pair2ZCt4pair2ZiZiZ=
9data
_typeZRt4pair2ZCt4pair2ZiZiZ9data_type
ZPt4pair2ZCt4pair2ZiZiZ9data_typeRCt17_Rb_tree_iterator3Zt4pair2ZCt4pair2=
ZiZ
iZ9data_typeZRt4pair2ZCt4pair2ZiZiZ9da
ta_typeZPt4pair2ZCt4pair2ZiZiZ9data_type;2A.;operator*::(0,184)=3D##(0,93=
);:__
ml__Ct17_Rb_tree_iterator3Zt4pair2ZCt4
pair2ZiZiZ9data_typeZRt4pair2ZCt4pair2ZiZiZ9data_typeZPt4pair2ZCt4pair2Zi=
ZiZ
9data_type;2B.;operator->::(0,185)=3D##(
0,186)=3D*(0,94);:__rf__Ct17_Rb_tree_iterator3Zt4pair2ZCt4pair2ZiZiZ9data=
_type
ZRt4pair2ZCt4pair2ZiZiZ9data_typeZPt4p
air2ZCt4pair2ZiZiZ9data_type;2B.;operator++::(0,187)=3D##(0,179);:__pp__t=
17_Rb
_tree_iterator3Zt4pair2ZCt4pair2ZiZiZ9
data_typeZRt4pair2ZCt4pair2ZiZiZ9data_typeZPt4pair2ZCt4pair2ZiZiZ9data_ty=
pe;
2A.(0,188)=3D##(0,105);:__pp__t17_Rb_tre
e_iterator3Zt4pair2ZCt4pair2ZiZiZ9data_typeZRt4pair2ZCt4pair2ZiZiZ9data_t=
ype
ZPt4pair2ZCt4pair2ZiZiZ9data_typei;2A.
;operator--::(0,187):__mm__t17_Rb_tree_iterator3Zt4pair2ZCt4pair2ZiZiZ9da=
ta_
typeZRt4pair2ZCt4pair2ZiZiZ9data_typeZ
Pt4pair2ZCt4pair2ZiZiZ9data_type;2A.(0,188):__mm__t17_Rb_tree_iterator3Zt=
4pa
ir2ZCt4pair2ZiZiZ9data_typeZRt4pair2ZC
t4pair2ZiZiZ9data_typeZPt4pair2ZCt4pair2ZiZiZ9data_typei;2A.;; gave NULL
type (s4!1,020,(2,9);operator=3D::(0,178)=3D#
#(0,179)=3D&(0,105);:__as__t17_Rb_tree_iterator3Zt4pair2ZCt4pair2ZiZiZ9da=
ta_ty
peZRt4pair2ZCt4pair2ZiZiZ9data_typeZPt
4pair2ZCt4pair2ZiZiZ9data_typeRCt17_Rb_tree_iterator3Zt4pair2ZCt4pair2ZiZ=
iZ9
data_typeZRt4pair2ZCt4pair2ZiZiZ9data_
typeZPt4pair2ZCt4pair2ZiZiZ9data_type;2A.;_Rb_tree_iterator::(0,180)=3D##=
(0,18
1)=3D*(0,105);:__t17_Rb_tree_iterator3Zt
4pair2ZCt4pair2ZiZiZ9data_typeZRt4pair2ZCt4pair2ZiZiZ9data_typeZPt4pair2Z=
Ct4
pair2ZiZiZ9data_type;2A.(0,182)=3D##(0,1
81);:__t17_Rb_tree_iterator3Zt4pair2ZCt4pair2ZiZiZ9data_typeZRt4pair2ZCt4=
pai
r2ZiZiZ9data_typeZPt4pair2ZCt4pair2ZiZ
iZ9data_typePt13_Rb_tree_node1Zt4pair2ZCt4pair2ZiZiZ9data_type;2A.(0,183)=
=3D##
(0,181);:__t17_Rb_tree_iterator3Zt4pai
r2ZCt4pair2ZiZiZ9data_typeZRt4pair2ZCt4pair2ZiZiZ9data_typeZPt4pair2ZCt4p=
air
2ZiZiZ9data_typeRCt17_Rb_tree_iterator
3Zt4pair2ZCt4pair2ZiZiZ9data_typeZRt4pair2ZCt4pair2ZiZiZ9data_typeZPt4pai=
r2Z
Ct4pair2ZiZiZ9data_type;2A.;operator*:
:(0,184)=3D##(0,93);:__ml__Ct17_Rb_tree_iterator3Zt4pair2ZCt4pair2ZiZiZ9d=
ata_t
ypeZRt4pair2ZCt4pair2ZiZiZ9data_typeZP
t4pair2ZCt4pair2ZiZiZ9data_type;2B.;operator->::(0,185)=3D##(0,186)=3D*(0=
,94);:_
_rf__Ct17_Rb_tree_iterator3Zt4pair2ZCt
4pair2ZiZiZ9data_typeZRt4pair2ZCt4pair2ZiZiZ9data_typeZPt4pair2ZCt4pair2Z=
iZi
Z9data_type;2B.;operator++::(0,187)=3D##
(0,179);:__pp__t17_Rb_tree_iterator3Zt4pair2ZCt4pair2ZiZiZ9data_typeZRt4p=
air
2ZCt4pair2ZiZiZ9data_typeZPt4pair2ZCt4
pair2ZiZiZ9data_type;2A.(0,188)=3D##(0,105);:__pp__t17_Rb_tree_iterator3Z=
t4pai
r2ZCt4pair2ZiZiZ9data_typeZRt4pair2ZCt
4pair2ZiZiZ9data_typeZPt4pair2ZCt4pair2ZiZiZ9data_typei;2A.;operator--::(=
0,1
87):__mm__t17_Rb_tree_iterator3Zt4pair
2ZCt4pair2ZiZiZ9data_typeZRt4pair2ZCt4pair2ZiZiZ9data_typeZPt4pair2ZCt4pa=
ir2
ZiZiZ9data_type;2A.(0,188):__mm__t17_R
b_tree_iterator3Zt4pair2ZCt4pair2ZiZiZ9data_typeZRt4pair2ZCt4pair2ZiZiZ9d=
ata
_typeZPt4pair2ZCt4pair2ZiZiZ9data_type
i;2A.;; remains)
--24620-- INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV) - =
exiting
--24620-- si_code=3D1 Fault EIP: 0xB803A9CB (); Faulting address: 0x0
valgrind: the `impossible' happened:
Killed by fatal signal
Basic block ctr is approximately 0
=3D=3D24620=3D=3D at 0xB802D8A7: ???
=3D=3D24620=3D=3D by 0xB802D8A6: ???
=3D=3D24620=3D=3D by 0xB802D8BC: ???
=3D=3D24620=3D=3D by 0xB803366A: ???
=20
sched status:
=20
Thread 1: status =3D Runnable, associated_mx =3D 0x0, associated_cv =3D =
0x0
=3D=3D24620=3D=3D at 0x3C001E90: ???
=20
Note: see also the FAQ.txt in the source distribution.
It contains workarounds to several common problems.
=20
If that doesn't help, please report this bug to: valgrind.kde.org
=20
In the bug report, send all the above text, the valgrind
version, and what Linux distro you are using. Thanks.
=20
</valgrind-output-stop>
=20
=20
thanks & regards,
bdutta
|
|
From: Nicholas N. <nj...@ca...> - 2004-04-13 15:13:41
|
On Tue, 13 Apr 2004, Thomas Lavergne wrote: > I just updated to valgrind 2.1.1 (previous running version was 2.0) and > I encounter a problem (I have never seen it with 2.0). > My C program uses a flex/bison parser for reading an input file. > Valgrind exits while this input file is read, but without signaling any > error. > What is really strange to me, is that my program actually parses this > input files and prints outputs prooving it does. However, valgrind > reports that the "input" in flex scanner failed. > > I uses valgrind --tool=memcheck -v myprogram > > Can anybody help in finding why valgrind is detached and reports such an > error? > Thanks > Thomas > > [many output from my program, reading the input file.] Sounds like a Valgrind bug. Can you give us the full output from "valgrind -v"? If it's big, can you gzip it and put it on a website? Even better -- can you reduce your program to the smallest size that reproduces the problem and give it to us with sample input? That's the best chance for finding the problem. In the meantime, I guess you can revert to 2.0.0 (actually, it would be interesting to know if 2.1.0 works properly). N |
|
From: David E. <tw...@us...> - 2004-04-13 15:07:00
|
On Tue, 2004-04-13 at 16:25, Thomas Lavergne wrote:
> Hi
> I just updated to valgrind 2.1.1 (previous running version was 2.0) and
> I encounter a problem (I have never seen it with 2.0).
> My C program uses a flex/bison parser for reading an input file.
> Valgrind exits while this input file is read, but without signaling any
> error.
> What is really strange to me, is that my program actually parses this
> input files and prints outputs prooving it does. However, valgrind
> reports that the "input" in flex scanner failed.
>
> I uses valgrind --tool=memcheck -v myprogram
>
> Can anybody help in finding why valgrind is detached and reports such an
> error?
FWIW, I don't think that the message "input in flex scanner failed"
comes from valgrind but from flex or flex-generated code. Just google
for the string.
--
Regards,
-\- David Eriksson -/-
SynCE - http://synce.sourceforge.net
CalcEm - http://calcem.sourceforge.net
ScummVM - http://scummvm.sourceforge.net
Desquirr - http://desquirr.sourceforge.net
SetiWrapper - http://setiwrapper.sourceforge.net
|
|
From: Thomas L. <tho...@jr...> - 2004-04-13 14:26:43
|
Hi I just updated to valgrind 2.1.1 (previous running version was 2.0) and I encounter a problem (I have never seen it with 2.0). My C program uses a flex/bison parser for reading an input file. Valgrind exits while this input file is read, but without signaling any error. What is really strange to me, is that my program actually parses this input files and prints outputs prooving it does. However, valgrind reports that the "input" in flex scanner failed. I uses valgrind --tool=memcheck -v myprogram Can anybody help in finding why valgrind is detached and reports such an error? Thanks Thomas [many output from my program, reading the input file.] input in flex scanner failed ==20622== ==20622== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 13 from 1) --20622-- --20622-- supp: 13 Ugly strchr error in /lib/ld-2.3.2.so ==20622== malloc/free: in use at exit: 31290 bytes in 436 blocks. ==20622== malloc/free: 497 allocs, 61 frees, 34370 bytes allocated. ==20622== --20622-- TT/TC: 0 tc sectors discarded. --20622-- 3240 chainings, 2 unchainings. --20622-- translate: new 4564 (88524 -> 1130025; ratio 127:10) --20622-- discard 1 (23 -> 320; ratio 139:10). --20622-- dispatch: 25500000 jumps (bb entries), of which 8775573 (34%) were unchained. --20622-- 735/6124 major/minor sched events. 4717 tt_fast misses. --20622-- reg-alloc: 1043 t-req-spill, 206269+7427 orig+spill uis, 24275 total-reg-r. --20622-- sanity: 628 cheap, 26 expensive checks. --20622-- ccalls: 21139 C calls, 53% saves+restores avoided (67210 bytes) --20622-- 28497 args, avg 0.85 setup instrs each (8344 bytes) --20622-- 0% clear the stack (63234 bytes) --20622-- 8668 retvals, 28% of reg-reg movs avoided (4806 bytes) |
|
From: Banibrata D. <du...@in...> - 2004-04-13 05:17:37
|
hi,
=20
i have a simple C++ program that uses STL. "valgrind" seems to crash on =
it.
what is the reason ? is there any workaround ?
=20
<program-start>
=20
#include <map>
#include <functional>
#include <utility>
#include <iostream>
using namespace std;
=20
typedef pair<int,int> int_pair;
=20
class data_type {
public:
data_type(int_pair* p, char d) : key_part(p), data(d) {}
data_type(char d) : key_part(0), data(d) {}
data_type() : key_part(0), data(0) {}
int_pair* getKey() { return key_part;}
char getData() {return data;}
private:
int_pair *key_part;
char data;
};
=20
typedef map<int_pair,data_type> ip_map;
=20
int main()
{
ip_map _map;
data_type *_dt=3D0;
=20
int_pair *key=3D0;
=20
for (int i=3D0,j=3D3; i < 5; i+=3D2, j++)
{
key =3D new int_pair(i, j);
_dt =3D new data_type(key, ('a' + char(i)));
_map[*key] =3D *_dt;
}
=20
for (ip_map::iterator iter =3D _map.begin(); iter !=3D =
_map.end();
iter++)
{
cout << "map[" << iter->first.first << "," <<
iter->first.second << "] =3D (" <<
iter->second.getKey() << ", " <<
iter->second.getData() << ")" << endl;
}
return 0;
}
</program-stop>
=20
=20
<valgrind-output-start>
[dutta@pttlnx1 maps]$ valgrind --tool=3Dmemcheck -v --demangle=3Dyes =
./a.out=20
=3D=3D24620=3D=3D Memcheck, a memory error detector for x86-linux.
=3D=3D24620=3D=3D Copyright (C) 2002-2004, and GNU GPL'd, by Julian =
Seward.
=3D=3D24620=3D=3D Using valgrind-2.1.1, a program supervision framework =
for
x86-linux.
=3D=3D24620=3D=3D Copyright (C) 2000-2004, and GNU GPL'd, by Julian =
Seward.
=3D=3D24620=3D=3D Valgrind library directory: /usr/local/lib/valgrind
=3D=3D24620=3D=3D Command line
=3D=3D24620=3D=3D ./a.out
=3D=3D24620=3D=3D Startup, with flags:
=3D=3D24620=3D=3D --tool=3Dmemcheck
=3D=3D24620=3D=3D -v
=3D=3D24620=3D=3D --demangle=3Dyes
=3D=3D24620=3D=3D Reading syms from /home/dutta/work/cpp_prac/maps/a.out =
(0x8048000)
@@ don't know what type '_' is
@@ parsing
__rf__Ct17_Rb_tree_iterator3Zt4pair2ZCt4pair2ZiZiZ9data_typeZRt4pair2ZCt4=
pai
r2ZiZiZ9data_typeZPt4pair2
ZCt4pair2ZiZiZ9data_type;2B.;operator++::(0,187)=3D##(0,179);:__pp__t17_R=
b_tre
e_iterator3Zt4pair2ZCt4pair2ZiZiZ9data
_typeZRt4pair2ZCt4pair2ZiZiZ9data_typeZPt4pair2ZCt4pair2ZiZiZ9data_type;2=
A.(
0,188)=3D##(0,105);:__pp__t17_Rb_tree_it
erator3Zt4pair2ZCt4pair2ZiZiZ9data_typeZRt4pair2ZCt4pair2ZiZiZ9data_typeZ=
Pt4
pair2ZCt4pair2ZiZiZ9data_typei;2A.;ope
rator--::(0,187):__mm__t17_Rb_tree_iterator3Zt4pair2ZCt4pair2ZiZiZ9data_t=
ype
ZRt4pair2ZCt4pair2ZiZiZ9data_typeZPt4p
air2ZCt4pair2ZiZiZ9data_type;2A.(0,188):__mm__t17_Rb_tree_iterator3Zt4pai=
r2Z
Ct4pair2ZiZiZ9data_typeZRt4pair2ZCt4pa
ir2ZiZiZ9data_typeZPt4pair2ZCt4pair2ZiZiZ9data_typei;2A.;; gave NULL =
type
(_rf__Ct17_Rb_tree_iterator3Zt4pair2ZCt4
pair2ZiZiZ9data_typeZRt4pair2ZCt4pair2ZiZiZ9data_typeZPt4pair2ZCt4pair2Zi=
ZiZ
9data_type;2B.;operator++::(0,187)=3D##(
0,179);:__pp__t17_Rb_tree_iterator3Zt4pair2ZCt4pair2ZiZiZ9data_typeZRt4pa=
ir2
ZCt4pair2ZiZiZ9data_typeZPt4pair2ZCt4p
air2ZiZiZ9data_type;2A.(0,188)=3D##(0,105);:__pp__t17_Rb_tree_iterator3Zt=
4pair
2ZCt4pair2ZiZiZ9data_typeZRt4pair2ZCt4
pair2ZiZiZ9data_typeZPt4pair2ZCt4pair2ZiZiZ9data_typei;2A.;operator--::(0=
,18
7):__mm__t17_Rb_tree_iterator3Zt4pair2
ZCt4pair2ZiZiZ9data_typeZRt4pair2ZCt4pair2ZiZiZ9data_typeZPt4pair2ZCt4pai=
r2Z
iZiZ9data_type;2A.(0,188):__mm__t17_Rb
_tree_iterator3Zt4pair2ZCt4pair2ZiZiZ9data_typeZRt4pair2ZCt4pair2ZiZiZ9da=
ta_
typeZPt4pair2ZCt4pair2ZiZiZ9data_typei
;2A.;; remains)
=20
@@ expected ':' at struct method MANGLE-ARGS
(remains=3D"rf__Ct17_Rb_tree_iterator3Zt4pair2ZCt4pair2ZiZiZ9data_type
ZRt4pair2ZCt4pair2ZiZiZ9data_typeZPt4pair2ZCt4pair2ZiZiZ9data_type;2B.;op=
era
tor++::(0,187)=3D##(0,179);:__pp__t17_Rb
_tree_iterator3Zt4pair2ZCt4pair2ZiZiZ9data_typeZRt4pair2ZCt4pair2ZiZiZ9da=
ta_
typeZPt4pair2ZCt4pair2ZiZiZ9data_type;
2A.(0,188)=3D##(0,105);:__pp__t17_Rb_tree_iterator3Zt4pair2ZCt4pair2ZiZiZ=
9data
_typeZRt4pair2ZCt4pair2ZiZiZ9data_type
ZPt4pair2ZCt4pair2ZiZiZ9data_typei;2A.;operator--::(0,187):__mm__t17_Rb_t=
ree
_iterator3Zt4pair2ZCt4pair2ZiZiZ9data_
typeZRt4pair2ZCt4pair2ZiZiZ9data_typeZPt4pair2ZCt4pair2ZiZiZ9data_type;2A=
.(0
,188):__mm__t17_Rb_tree_iterator3Zt4pa
ir2ZCt4pair2ZiZiZ9data_typeZRt4pair2ZCt4pair2ZiZiZ9data_typeZPt4pair2ZCt4=
pai
r2ZiZiZ9data_typei;2A.;;")
@@ parsing
(0,105)=3Ds4!1,020,(2,9);operator=3D::(0,178)=3D##(0,179)=3D&(0,105);:__a=
s__t17_Rb_t
ree_iterator3Zt4pair2ZCt4p
air2ZiZiZ9data_typeZRt4pair2ZCt4pair2ZiZiZ9data_typeZPt4pair2ZCt4pair2ZiZ=
iZ9
data_typeRCt17_Rb_tree_iterator3Zt4pai
r2ZCt4pair2ZiZiZ9data_typeZRt4pair2ZCt4pair2ZiZiZ9data_typeZPt4pair2ZCt4p=
air
2ZiZiZ9data_type;2A.;_Rb_tree_iterator
::(0,180)=3D##(0,181)=3D*(0,105);:__t17_Rb_tree_iterator3Zt4pair2ZCt4pair=
2ZiZiZ9
data_typeZRt4pair2ZCt4pair2ZiZiZ9data_
typeZPt4pair2ZCt4pair2ZiZiZ9data_type;2A.(0,182)=3D##(0,181);:__t17_Rb_tr=
ee_it
erator3Zt4pair2ZCt4pair2ZiZiZ9data_typ
eZRt4pair2ZCt4pair2ZiZiZ9data_typeZPt4pair2ZCt4pair2ZiZiZ9data_typePt13_R=
b_t
ree_node1Zt4pair2ZCt4pair2ZiZiZ9data_t
ype;2A.(0,183)=3D##(0,181);:__t17_Rb_tree_iterator3Zt4pair2ZCt4pair2ZiZiZ=
9data
_typeZRt4pair2ZCt4pair2ZiZiZ9data_type
ZPt4pair2ZCt4pair2ZiZiZ9data_typeRCt17_Rb_tree_iterator3Zt4pair2ZCt4pair2=
ZiZ
iZ9data_typeZRt4pair2ZCt4pair2ZiZiZ9da
ta_typeZPt4pair2ZCt4pair2ZiZiZ9data_type;2A.;operator*::(0,184)=3D##(0,93=
);:__
ml__Ct17_Rb_tree_iterator3Zt4pair2ZCt4
pair2ZiZiZ9data_typeZRt4pair2ZCt4pair2ZiZiZ9data_typeZPt4pair2ZCt4pair2Zi=
ZiZ
9data_type;2B.;operator->::(0,185)=3D##(
0,186)=3D*(0,94);:__rf__Ct17_Rb_tree_iterator3Zt4pair2ZCt4pair2ZiZiZ9data=
_type
ZRt4pair2ZCt4pair2ZiZiZ9data_typeZPt4p
air2ZCt4pair2ZiZiZ9data_type;2B.;operator++::(0,187)=3D##(0,179);:__pp__t=
17_Rb
_tree_iterator3Zt4pair2ZCt4pair2ZiZiZ9
data_typeZRt4pair2ZCt4pair2ZiZiZ9data_typeZPt4pair2ZCt4pair2ZiZiZ9data_ty=
pe;
2A.(0,188)=3D##(0,105);:__pp__t17_Rb_tre
e_iterator3Zt4pair2ZCt4pair2ZiZiZ9data_typeZRt4pair2ZCt4pair2ZiZiZ9data_t=
ype
ZPt4pair2ZCt4pair2ZiZiZ9data_typei;2A.
;operator--::(0,187):__mm__t17_Rb_tree_iterator3Zt4pair2ZCt4pair2ZiZiZ9da=
ta_
typeZRt4pair2ZCt4pair2ZiZiZ9data_typeZ
Pt4pair2ZCt4pair2ZiZiZ9data_type;2A.(0,188):__mm__t17_Rb_tree_iterator3Zt=
4pa
ir2ZCt4pair2ZiZiZ9data_typeZRt4pair2ZC
t4pair2ZiZiZ9data_typeZPt4pair2ZCt4pair2ZiZiZ9data_typei;2A.;; gave NULL
type (s4!1,020,(2,9);operator=3D::(0,178)=3D#
#(0,179)=3D&(0,105);:__as__t17_Rb_tree_iterator3Zt4pair2ZCt4pair2ZiZiZ9da=
ta_ty
peZRt4pair2ZCt4pair2ZiZiZ9data_typeZPt
4pair2ZCt4pair2ZiZiZ9data_typeRCt17_Rb_tree_iterator3Zt4pair2ZCt4pair2ZiZ=
iZ9
data_typeZRt4pair2ZCt4pair2ZiZiZ9data_
typeZPt4pair2ZCt4pair2ZiZiZ9data_type;2A.;_Rb_tree_iterator::(0,180)=3D##=
(0,18
1)=3D*(0,105);:__t17_Rb_tree_iterator3Zt
4pair2ZCt4pair2ZiZiZ9data_typeZRt4pair2ZCt4pair2ZiZiZ9data_typeZPt4pair2Z=
Ct4
pair2ZiZiZ9data_type;2A.(0,182)=3D##(0,1
81);:__t17_Rb_tree_iterator3Zt4pair2ZCt4pair2ZiZiZ9data_typeZRt4pair2ZCt4=
pai
r2ZiZiZ9data_typeZPt4pair2ZCt4pair2ZiZ
iZ9data_typePt13_Rb_tree_node1Zt4pair2ZCt4pair2ZiZiZ9data_type;2A.(0,183)=
=3D##
(0,181);:__t17_Rb_tree_iterator3Zt4pai
r2ZCt4pair2ZiZiZ9data_typeZRt4pair2ZCt4pair2ZiZiZ9data_typeZPt4pair2ZCt4p=
air
2ZiZiZ9data_typeRCt17_Rb_tree_iterator
3Zt4pair2ZCt4pair2ZiZiZ9data_typeZRt4pair2ZCt4pair2ZiZiZ9data_typeZPt4pai=
r2Z
Ct4pair2ZiZiZ9data_type;2A.;operator*:
:(0,184)=3D##(0,93);:__ml__Ct17_Rb_tree_iterator3Zt4pair2ZCt4pair2ZiZiZ9d=
ata_t
ypeZRt4pair2ZCt4pair2ZiZiZ9data_typeZP
t4pair2ZCt4pair2ZiZiZ9data_type;2B.;operator->::(0,185)=3D##(0,186)=3D*(0=
,94);:_
_rf__Ct17_Rb_tree_iterator3Zt4pair2ZCt
4pair2ZiZiZ9data_typeZRt4pair2ZCt4pair2ZiZiZ9data_typeZPt4pair2ZCt4pair2Z=
iZi
Z9data_type;2B.;operator++::(0,187)=3D##
(0,179);:__pp__t17_Rb_tree_iterator3Zt4pair2ZCt4pair2ZiZiZ9data_typeZRt4p=
air
2ZCt4pair2ZiZiZ9data_typeZPt4pair2ZCt4
pair2ZiZiZ9data_type;2A.(0,188)=3D##(0,105);:__pp__t17_Rb_tree_iterator3Z=
t4pai
r2ZCt4pair2ZiZiZ9data_typeZRt4pair2ZCt
4pair2ZiZiZ9data_typeZPt4pair2ZCt4pair2ZiZiZ9data_typei;2A.;operator--::(=
0,1
87):__mm__t17_Rb_tree_iterator3Zt4pair
2ZCt4pair2ZiZiZ9data_typeZRt4pair2ZCt4pair2ZiZiZ9data_typeZPt4pair2ZCt4pa=
ir2
ZiZiZ9data_type;2A.(0,188):__mm__t17_R
b_tree_iterator3Zt4pair2ZCt4pair2ZiZiZ9data_typeZRt4pair2ZCt4pair2ZiZiZ9d=
ata
_typeZPt4pair2ZCt4pair2ZiZiZ9data_type
i;2A.;; remains)
--24620-- INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV) - =
exiting
--24620-- si_code=3D1 Fault EIP: 0xB803A9CB (); Faulting address: 0x0
valgrind: the `impossible' happened:
Killed by fatal signal
Basic block ctr is approximately 0
=3D=3D24620=3D=3D at 0xB802D8A7: ???
=3D=3D24620=3D=3D by 0xB802D8A6: ???
=3D=3D24620=3D=3D by 0xB802D8BC: ???
=3D=3D24620=3D=3D by 0xB803366A: ???
=20
sched status:
=20
Thread 1: status =3D Runnable, associated_mx =3D 0x0, associated_cv =3D =
0x0
=3D=3D24620=3D=3D at 0x3C001E90: ???
=20
Note: see also the FAQ.txt in the source distribution.
It contains workarounds to several common problems.
=20
If that doesn't help, please report this bug to: valgrind.kde.org
=20
In the bug report, send all the above text, the valgrind
version, and what Linux distro you are using. Thanks.
=20
</valgrind-output-stop>
=20
=20
thanks & regards,
bdutta
=20
thanks & regards,
Banibrata Dutta
Hewlett-Packard ISO Pvt. Ltd,
29, Cunningham Road,
Bangalore - 560052, India.
Tel: +91-80-22051796
=20
=20
|
|
From: Nicholas N. <nj...@ca...> - 2004-04-12 09:11:35
|
On Sun, 11 Apr 2004, Edwin Mulder wrote: > Start of initial question: > Currently i am facing a problem concerning the use of a semaphore. > > valgrind: vg_libpthread.c:2581 (sem_wait): Assertion `res == 0' failed. Can you please file a bug report, following the instructions at valgrind.kde.org/bugs.html? Thanks. N |
|
From: Joshua Moore-O. <jo...@ch...> - 2004-04-12 09:07:18
|
I can't answer anythign else, but I can answer this one. > P.S. getpid() always returns the same id, no matter which thread is actually > executing this call. Known issue? > you shoudl be using pthread_self for threads, NOT getpid. The only reason that getpid returns different values on a linux system is because of the special way that linux handles threads, different from all other O/S's that I know of. And the reason that getpid is returning the saem id is because valgrind is providing and arguably more standards compliant thread implementation by implementing all the threads as one process for debugging purposes. Joshua Moore-Oliva. |
|
From: Edwin M. <em...@ho...> - 2004-04-11 21:32:46
|
Hi all, I have posted this question before, but i have not received any response = yet. Is this mailing-list the right spot for this question? Or is the = question not clear? Or ..... Start of initial question: Currently i am facing a problem concerning the use of a semaphore. valgrind: vg_libpthread.c:2581 (sem_wait): Assertion `res =3D=3D 0' = failed. =3D=3D5262=3D=3D Please report this bug at: valgrind.kde.org =3D=3D5262=3D=3D TRANSLATE: 0x3C33E610 redirected to 0x3C13CD28 =3D=3D5262=3D=3D =3D=3D5262=3D=3D ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 24 = from 2) =3D=3D5262=3D=3D =3D=3D5262=3D=3D 1 errors in context 1 of 1: =3D=3D5262=3D=3D Thread 29: =3D=3D5262=3D=3D pthread_cond_wait/timedwait: mutex is unlocked or is = locked but not=20 owned by thread =3D=3D5262=3D=3D at 0x3C13AD26: pthread_cond_wait = (vg_libpthread.c:1316) =3D=3D5262=3D=3D by 0x3C13DD2B: sem_wait (vg_libpthread.c:2579) =3D=3D5262=3D=3D by 0x80EBA13: cGosyCountSemImpl::Wait(unsigned)=20 (gosy_countsem.cpp:113) =3D=3D5262=3D=3D by 0x80EB781: cGosyCountSem::Wait(unsigned)=20 (gosy_countsem.cpp:32) --5262-- --5262-- supp: 23 Ugly strchr error in /lib/ld-2.3.2.so --5262-- supp: 1 pthread_mutex_unlock/_IO_funlockfile =3D=3D5262=3D=3D =3D=3D5262=3D=3D IN SUMMARY: 1 errors from 1 contexts (suppressed: 24 = from 2) My configuration: Suse 9.0 kernel 2.4.21-99 glibc 2.3.2 valgrind 2.1.1 In the faq i read: ** A10. Thread support on glibc 2.3.2+ with NPTL is not as ** good as on older LinuxThreads-based systems. We have Is this my problem? What is NPTL? Any workarounds for having valgrind=20 up-and-running? Edwin P.S. getpid() always returns the same id, no matter which thread is = actually=20 executing this call. Known issue? |
|
From: Henrik N. <hn...@ma...> - 2004-04-11 00:00:41
|
On Sat, 10 Apr 2004, G B wrote: > There is no error with --run-libc-freeres=no. I guess > that solves that one then. That said, why does glibc > have this problem? Probably because very few developers uses the freeres function in glibc as it is only relevant for leak checkers, so bugs is very likely to appear in this part of glibc. Regards Henrik |
|
From: Nicholas N. <nj...@ca...> - 2004-04-10 18:50:31
|
On Sat, 10 Apr 2004, G B wrote: > There is no error with --run-libc-freeres=no. I guess > that solves that one then. Yes, sounds like a glibc bug. > That said, why does glibc have this problem? glibc has bugs, just like any other program :) N |
|
From: <gil...@ya...> - 2004-04-10 18:30:07
|
> > The above was obtained with --num-callers=20. Any > > ideas what could be lurking at 0x8F? > > Stack-walking is not always reliable, I think > Valgrind's getting confused > here, and wouldn't pay too much attention to the > 0x8f. Try with > --run-libc-freeres=no. If you don't get an error, > then I think it shows > that the problem is with glibc -- libc-freeres is a > glibc routine that > frees up all glibc's memory. There is no error with --run-libc-freeres=no. I guess that solves that one then. That said, why does glibc have this problem? ____________________________________________________________ Yahoo! Messenger - Communicate instantly..."Ping" your friends today! Download Messenger Now http://uk.messenger.yahoo.com/download/index.html |
|
From: Nicholas N. <nj...@ca...> - 2004-04-10 01:10:22
|
On Thu, 8 Apr 2004, tmoog wrote: > I have noticed that when a .so is loaded via dlopen and it is > unloaded via dlclose before exit then valgrind doesn't know > how to resolve the symbols for that .so. Yes. I just committed a PR for that (http://bugs.kde.org/show_bug.cgi?id=79362) if you are interested. Not that this implies anything will be done immediately; this has been a problem since Valgrind was born. N |
|
From: Nicholas N. <nj...@ca...> - 2004-04-09 22:39:30
|
On Fri, 9 Apr 2004, G B wrote: > --- Nicholas Nethercote <nj...@ca...> wrote: > > > Is this valgrind finding a bug in > > > a) itself? > > > b) libc? > > > c) my program? > > > > Maybe b, maybe c. A longer stack trace (eg. > > --num-callers=20) will > > hopefully make it clearer. > > ==2872== Invalid free() / delete / delete[] > ==2872== at 0x7501CDEC: free (in > /usr/lib/valgrind/vgpreload_addrcheck.so) > ==2872== by 0x7540B9B3: (within /lib/libc-2.3.3.so) > ==2872== by 0x7540B6F9: __libc_freeres (in > /lib/libc-2.3.3.so) > ==2872== by 0x75018BBE: (within > /usr/lib/valgrind/vg_inject.so) > ==2872== by 0x7533104A: exit (in > /lib/libc-2.3.3.so) > ==2872== by 0x75106C19: processEventsAndTimeouts > (in /usr/lib/libglut.so.3.7.1) > ==2872== by 0x8F: ??? > ==2872== Address 0x759D0818 is not stack'd, malloc'd > or free'd > > The above was obtained with --num-callers=20. Any > ideas what could be lurking at 0x8F? Stack-walking is not always reliable, I think Valgrind's getting confused here, and wouldn't pay too much attention to the 0x8f. Try with --run-libc-freeres=no. If you don't get an error, then I think it shows that the problem is with glibc -- libc-freeres is a glibc routine that frees up all glibc's memory. N |
|
From: <gil...@ya...> - 2004-04-09 16:01:52
|
--- Nicholas Nethercote <nj...@ca...> wrote: > > Is this valgrind finding a bug in > > a) itself? > > b) libc? > > c) my program? > > Maybe b, maybe c. A longer stack trace (eg. > --num-callers=20) will > hopefully make it clearer. ==2872== Invalid free() / delete / delete[] ==2872== at 0x7501CDEC: free (in /usr/lib/valgrind/vgpreload_addrcheck.so) ==2872== by 0x7540B9B3: (within /lib/libc-2.3.3.so) ==2872== by 0x7540B6F9: __libc_freeres (in /lib/libc-2.3.3.so) ==2872== by 0x75018BBE: (within /usr/lib/valgrind/vg_inject.so) ==2872== by 0x7533104A: exit (in /lib/libc-2.3.3.so) ==2872== by 0x75106C19: processEventsAndTimeouts (in /usr/lib/libglut.so.3.7.1) ==2872== by 0x8F: ??? ==2872== Address 0x759D0818 is not stack'd, malloc'd or free'd The above was obtained with --num-callers=20. Any ideas what could be lurking at 0x8F? ____________________________________________________________ Yahoo! Messenger - Communicate instantly..."Ping" your friends today! Download Messenger Now http://uk.messenger.yahoo.com/download/index.html |