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
(11) |
2
|
|
3
(5) |
4
(8) |
5
(33) |
6
(11) |
7
(1) |
8
(3) |
9
(4) |
|
10
(3) |
11
(12) |
12
(17) |
13
(10) |
14
(13) |
15
(7) |
16
|
|
17
(2) |
18
(22) |
19
(9) |
20
(7) |
21
(1) |
22
(4) |
23
(1) |
|
24
|
25
(1) |
26
(3) |
27
(8) |
28
(3) |
29
(16) |
30
(4) |
|
31
|
|
|
|
|
|
|
|
From: Olivier C. <oli...@fr...> - 2003-08-27 21:48:23
|
On Wed, Aug 27, 2003 at 10:35:26PM +0200, Stéphane Donzé wrote: > Hello, > > when trying to convert a hp file produced by massif, I get the following > message: > > $ hp2ps hp.25447.hp > hp2ps: hp.25447.hp, line 11: integer unexpected > > any idea ? I tryed Haskell's hp2ps and the version you put on your page, > and both versions (maybe it's the same ?) failed. > I get the same problem. A (tmp?) fix: [olivier@snoopy olivier]$ perl -ne 's/.*://; print' hp.25447.hp> fixedhp.25447.hp [olivier@snoopy olivier]$ hp2ps -c -t0 fixedhp.25447.hp [olivier@snoopy olivier]$ gv -seascape -scalebase 2 fixedhp.25447.ps & Regards, Olivier |
|
From: Adam D. <am...@st...> - 2003-08-27 21:25:42
|
Hi. I get this error whenever my app tries to exit: poll_for_ready_fds: select returned -1 valgrind: the `impossible' happened: poll_for_ready_fds: select failed?! Basic block ctr is approximately 19150000 sched status: <43 threads> My application is a fairly complicated multithreaded beast, with mixed sync/async IO, some signal handling, etc. I am running valgrind-20030725 on uclibc. I've successfully used valgrind for leak detection with a single threaded uclibc app. Is there a fix or workaround for this problem? Thanks, Adam |
|
From: <ste...@ex...> - 2003-08-27 20:35:26
|
Hello, when trying to convert a hp file produced by massif, I get the following message: $ hp2ps hp.25447.hp hp2ps: hp.25447.hp, line 11: integer unexpected any idea ? I tryed Haskell's hp2ps and the version you put on your page, and both versions (maybe it's the same ?) failed. here is the head of my .hp file: JOB "/ng/src/donze/ng/bin/intel-linux/exe/exa -free -p exa.lang (32 ms/ sample)" DATE "(time and date)" SAMPLE_UNIT "ms" VALUE_UNIT "bytes" MARK 3.0 BEGIN_SAMPLE 3.0 stack(s) 2820 END_SAMPLE 3.0 MARK 36.0 BEGIN_SAMPLE 36.0 0x40A717AF:get_or_allocate 200 heap-admin 8 stack(s) 3980 END_SAMPLE 36.0 MARK 68.0 BEGIN_SAMPLE 68.0 0x402CECB9:ChannelNew 23444 0x40A717AF:get_or_allocate 200 0x40DE68D9:HashMalloc 207 0x402DCCA8:NGDigestNew 104 0x40DE6C0E:HashTableNew 52 Stephane |
|
From: Tom H. <th...@cy...> - 2003-08-27 15:23:05
|
In message <287...@se...>
Jason Gauthier <jga...@la...> wrote:
> Maybe I just don't completely understand what I'm looking for. Can someone
> offer an idea?
>
> ==20872== Conditional jump or move depends on uninitialised value(s)
> ==20872== at 0x81361A0: check_dispel (magic.c:246)
> ==20872== by 0x8123B6F: char_to_room (handler.c:1904)
> ==20872== by 0x81024BC: reset_room (db.c:2797)
> ==20872== by 0x8102B1B: reset_area (db.c:2990)
>
> So,I look at reset_area:
The first place you want to look is check_dispel, as that is the
innermost function in that stack trace.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Joerg B. <jo...@we...> - 2003-08-27 15:19:06
|
Jason Gauthier wrote:
> ==20872== Conditional jump or move depends on uninitialised value(s)
> ==20872== at 0x81361A0: check_dispel (magic.c:246)
> ==20872== by 0x8123B6F: char_to_room (handler.c:1904)
> ==20872== by 0x81024BC: reset_room (db.c:2797)
> ==20872== by 0x8102B1B: reset_area (db.c:2990)
>
> So,I look at reset_area:
>
> void reset_area(AREA_DATA * pArea)
> {
> 2997: long vnum=0;
> 2988: for (vnum = pArea->min_vnum; vnum <= pArea->max_vnum; vnum++) {
> 2989: if (pRoomArray[vnum]){
> 2990: reset_room(pRoomArray[vnum]);
> }
> }
> return;
> }
>
> Obviously, I have initialized vnum to 0 here.
only if pArea->min_vnum is initialized, else vnum has been initialized
and then was overwritten with some uninitialized.
> So does that mean pRoomArray is not initialized? It's a global array, and I
> thought they were initialized to NULL.
Joerg
|
|
From: Lee K. <lki...@cs...> - 2003-08-27 15:17:31
|
You should be looking at the lowest levle, line 246 in magic.c - the
cause should be much more apparent there.
L.
Jason Gauthier writes:
> This is driving me crazy.
>
> Maybe I just don't completely understand what I'm looking for. Can someone
> offer an idea?
>
> ==20872== Conditional jump or move depends on uninitialised value(s)
> ==20872== at 0x81361A0: check_dispel (magic.c:246)
> ==20872== by 0x8123B6F: char_to_room (handler.c:1904)
> ==20872== by 0x81024BC: reset_room (db.c:2797)
> ==20872== by 0x8102B1B: reset_area (db.c:2990)
>
> So,I look at reset_area:
>
> void reset_area(AREA_DATA * pArea)
> {
> 2997: long vnum=0;
> 2988: for (vnum = pArea->min_vnum; vnum <= pArea->max_vnum; vnum++) {
> 2989: if (pRoomArray[vnum]){
> 2990: reset_room(pRoomArray[vnum]);
> }
> }
> return;
> }
>
> Obviously, I have initialized vnum to 0 here.
> So does that mean pRoomArray is not initialized? It's a global array, and I
> thought they were initialized to NULL.
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
|
|
From: Jason G. <jga...@la...> - 2003-08-27 14:57:50
|
This is driving me crazy.
Maybe I just don't completely understand what I'm looking for. Can someone
offer an idea?
==20872== Conditional jump or move depends on uninitialised value(s)
==20872== at 0x81361A0: check_dispel (magic.c:246)
==20872== by 0x8123B6F: char_to_room (handler.c:1904)
==20872== by 0x81024BC: reset_room (db.c:2797)
==20872== by 0x8102B1B: reset_area (db.c:2990)
So,I look at reset_area:
void reset_area(AREA_DATA * pArea)
{
2997: long vnum=0;
2988: for (vnum = pArea->min_vnum; vnum <= pArea->max_vnum; vnum++) {
2989: if (pRoomArray[vnum]){
2990: reset_room(pRoomArray[vnum]);
}
}
return;
}
Obviously, I have initialized vnum to 0 here.
So does that mean pRoomArray is not initialized? It's a global array, and I
thought they were initialized to NULL.
|
|
From: Mincu A. <al...@cy...> - 2003-08-27 09:59:41
|
Here is the problem : My program has 3 threads that sleep in pthread_cond_timedwait, when i send a cancelation signal to one of the threads valgrind gives the following error: =3D=3D2417=3D=3D =3D=3D2417=3D=3D Thread 3: =3D=3D2417=3D=3D pthread_mutex_unlock: mutex is not locked =3D=3D2417=3D=3D at 0x402B1CC0: __pthread_mutex_unlock (in /usr/lib/valgrind/libpthread.so) =3D=3D2417=3D=3D by 0x402B120E: (within /usr/lib/valgrind/libpthread.so) =3D=3D2417=3D=3D by 0xBEADDEEE: ??? =3D=3D2417=3D=3D by 0x8054072: messages_main (messages.c:242) I guess that error occurs when the cleanup functions are executed because i do something like this: pthread_cleanup_push((void*)pthread_mutex_unlock, &mutex); pthread_mutex_lock(&mutex); ..... pthread_cond_timedwait(...); ..... pthread_cleanup_pop(1); My question is: Should pthread_cond_timedwait lock the mutex when exiting because of cancelation? |