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
(6) |
2
(16) |
3
(3) |
4
(11) |
5
(2) |
|
6
(4) |
7
(11) |
8
(4) |
9
(6) |
10
(25) |
11
(10) |
12
(1) |
|
13
(2) |
14
(6) |
15
(16) |
16
(19) |
17
(16) |
18
(5) |
19
|
|
20
(4) |
21
(5) |
22
(21) |
23
(4) |
24
(14) |
25
(3) |
26
(9) |
|
27
(3) |
28
(13) |
29
(6) |
30
(16) |
|
|
|
|
From: Julian S. <js...@ac...> - 2003-04-24 23:28:17
|
Known problem .. under consideration. See Q10 of http://developer.kde.org/~sewardj/docs-1.9.5/FAQ.txt J On Thursday 24 April 2003 11:34 pm, Sergio Ito wrote: > Hi all, > > first I'd like to say that valgrind is one of most > amazing tools I already used. Thanks for making it > such a great tool. > > I got some problems when my system was upgraded to red > hat 8.0 and we migrated to gcc 3.2.2 + valgrind-1.9.5. > I have a multithread app and it hangs somewhere > calling oldselect... strace gave this: > > fcntl(13, F_GETFL) = 0x801 (flags > O_WRONLY|O_NONBLOCK) > write(13, "MTclChannel FOPEN_MAX=16\nMTclCha"..., 57) > = 57 > fcntl(13, F_GETFL) = 0x801 (flags > O_WRONLY|O_NONBLOCK) > fcntl(13, F_SETFL, O_WRONLY) = 0 > oldselect(19, [17 18], NULL, NULL, NULL > > > and, pstack generated this: > > 0x4018ccde: vgPlain_post_known_blocking_syscall + > 0x20f (12, 4528d4c0, 0, 0, 0) > 0x40176563: __select + 0x2d (12, 4528d4c0, 0, 0, 0, 0) > + 1030 > 0x09b6a02f: _ZN11MTclChannel18shellCmdEventLoop_Ev + > 0x12f (4528afa8, 9b69ee0) > 0x09b69ef1: _ZN11MTclChannel21runShellCmdEventLoop_EPv > + 0x11 (4528afa8, 0, 0, 0, 0, 0) + 18 > 0x4026b822: thread_wrapper + 0xad (4528b040, 0, 0, 0, > 0, 0) + 789cc224 > 0x4016583e: do__apply_in_new_thread_bogusRA (4528afd0, > bfffc240, b0b0c60, 45287808, 452877d4, 45287798) + 40 > 0x09b69d23: > _ZN11MTclChannel4initEP10Tcl_InterpRN4_STL13basic_ostreamIcNS2_11char_trait >sIcEEEES7_ + 0x1c3 (b0b0c20, b0b0c60, b0b0c60, 4527c31c, > 45269e44, 1) + 10 > > valgrind-1.0.4 on red hat 7.2 was working properly. > > Any ideas?? > > Sergio > > > > > __________________________________________________ > Do you Yahoo!? > The New Yahoo! Search - Faster. Easier. Bingo > http://search.yahoo.com > > > ------------------------------------------------------- > 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: Sergio I. <ser...@ya...> - 2003-04-24 22:34:17
|
Hi all, first I'd like to say that valgrind is one of most amazing tools I already used. Thanks for making it such a great tool. I got some problems when my system was upgraded to red hat 8.0 and we migrated to gcc 3.2.2 + valgrind-1.9.5. I have a multithread app and it hangs somewhere calling oldselect... strace gave this: fcntl(13, F_GETFL) = 0x801 (flags O_WRONLY|O_NONBLOCK) write(13, "MTclChannel FOPEN_MAX=16\nMTclCha"..., 57) = 57 fcntl(13, F_GETFL) = 0x801 (flags O_WRONLY|O_NONBLOCK) fcntl(13, F_SETFL, O_WRONLY) = 0 oldselect(19, [17 18], NULL, NULL, NULL and, pstack generated this: 0x4018ccde: vgPlain_post_known_blocking_syscall + 0x20f (12, 4528d4c0, 0, 0, 0) 0x40176563: __select + 0x2d (12, 4528d4c0, 0, 0, 0, 0) + 1030 0x09b6a02f: _ZN11MTclChannel18shellCmdEventLoop_Ev + 0x12f (4528afa8, 9b69ee0) 0x09b69ef1: _ZN11MTclChannel21runShellCmdEventLoop_EPv + 0x11 (4528afa8, 0, 0, 0, 0, 0) + 18 0x4026b822: thread_wrapper + 0xad (4528b040, 0, 0, 0, 0, 0) + 789cc224 0x4016583e: do__apply_in_new_thread_bogusRA (4528afd0, bfffc240, b0b0c60, 45287808, 452877d4, 45287798) + 40 0x09b69d23: _ZN11MTclChannel4initEP10Tcl_InterpRN4_STL13basic_ostreamIcNS2_11char_traitsIcEEEES7_ + 0x1c3 (b0b0c20, b0b0c60, b0b0c60, 4527c31c, 45269e44, 1) + 10 valgrind-1.0.4 on red hat 7.2 was working properly. Any ideas?? Sergio __________________________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo http://search.yahoo.com |
|
From: Sebastian K.
|
Dnia czw 24. kwiecie=F1 2003 23:31, Alex Ivershen napisa=B3: > Sorry for off-topic, but I would like to ask Valgrind users a question = - > no=0D doubt some of you have run into this. I am deeply interested in f= inding > a performance profiler that works without code recompilation. Gprof is > great, but ... can't use it. Is there anything out there for Linux that > works like valgrind - on executalbles? Or at least on object files? I w= ould > truly appreciate any feedback. Have you tried cachegrind skin, or even KCachegrind + Calltree skin? This stuff (esp. Kcachegrind + Calltree skin) does quite nice profiling. = And=20 works on everything Valgrind works with, since it's Valgrind :) rgds Sebastian --=20 "Never undersetimate the power of human stupidity" -- from notebooks of L= =2EL. |
|
From: Julian S. <js...@ac...> - 2003-04-24 22:29:39
|
Writing a skin to do this should be very easy. I suggest you start with the lackey skin. Or maybe the cacheprof one. You can instrument the basic blocks in flexible ways as they are passed to your skin. One simple thing to do is to call function(s) of your choice when LOADs / STOREs, and their FPU equivalents, happen. All in all a brilliant piece of engineering from Nick N. J On Thursday 24 April 2003 11:04 pm, Vimal Reddy wrote: > Hello list, > I'm a newbie to valgrind and want to find out if I can use Valgrind in my > project. I'm trying to get address traces for executables. Since valgrind > anyway checks each read and write, I was thinking it should be possible to > log the address referenced by the read/write. > > I'm pretty sure the cachegrind skin uses this (addresses) to simulate > different cache hierarchies. Or am I getting this wrong? Please let me > know if you think this is a feasible task, so I will then go ahead and do > some hacking to get the traces. > > cheers, > Vimal > > ===== > Vimal Reddy > Graduate Student, ECE > North Carolina State University > Raleigh, NC > Ph: (919) 836-8254 Web: http://www4.ncsu.edu/~vkreddy > > __________________________________________________ > Do you Yahoo!? > The New Yahoo! Search - Faster. Easier. Bingo > http://search.yahoo.com > > > ------------------------------------------------------- > 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: Vimal R. <vim...@ya...> - 2003-04-24 22:04:41
|
Hello list, I'm a newbie to valgrind and want to find out if I can use Valgrind in my project. I'm trying to get address traces for executables. Since valgrind anyway checks each read and write, I was thinking it should be possible to log the address referenced by the read/write. I'm pretty sure the cachegrind skin uses this (addresses) to simulate different cache hierarchies. Or am I getting this wrong? Please let me know if you think this is a feasible task, so I will then go ahead and do some hacking to get the traces. cheers, Vimal ===== Vimal Reddy Graduate Student, ECE North Carolina State University Raleigh, NC Ph: (919) 836-8254 Web: http://www4.ncsu.edu/~vkreddy __________________________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo http://search.yahoo.com |
|
From: Alex I. <ale...@in...> - 2003-04-24 21:32:30
|
R3V5cywNCg0KWWVwLCAgdGhhdCB3YXMgaXQuIEkga2luZGEgaGFkIGEgc3VzcGljaW9uIHRo YXQgaXQgd2FzIHRoZSBuZXdlciBnbGliYy4NCkV2ZXJ5dGhpbmcgd29ya2VkIHBlcmZlY3Rs eSBvbiBmcmVzaCBSZWRIYXQuIFNvLCBkbyB5b3UgZ3V5cyBoYXZlIGFueSBpZGVhDQphYm91 dCB0aW1lZnJhbWUgd2hlbiBnbGliYyAyLjMuMiB3aWxsIGJlIHN1cHBvcnRlZD8gSnVzdCBj dXJpb3VzIC4uLg0KDQpTb3JyeSBmb3Igb2ZmLXRvcGljLCBidXQgSSB3b3VsZCBsaWtlIHRv IGFzayBWYWxncmluZCB1c2VycyBhIHF1ZXN0aW9uIC0gbm8NCmRvdWJ0IHNvbWUgb2YgeW91 IGhhdmUgcnVuIGludG8gdGhpcy4gSSBhbSBkZWVwbHkgaW50ZXJlc3RlZCBpbiBmaW5kaW5n IGENCnBlcmZvcm1hbmNlIHByb2ZpbGVyIHRoYXQgd29ya3Mgd2l0aG91dCBjb2RlIHJlY29t cGlsYXRpb24uIEdwcm9mIGlzIGdyZWF0LCBidXQNCi4uLiBjYW4ndCB1c2UgaXQuIElzIHRo ZXJlIGFueXRoaW5nIG91dCB0aGVyZSBmb3IgTGludXggdGhhdCB3b3JrcyBsaWtlDQp2YWxn cmluZCAtIG9uIGV4ZWN1dGFsYmxlcz8gT3IgYXQgbGVhc3Qgb24gb2JqZWN0IGZpbGVzPyBJ IHdvdWxkIHRydWx5DQphcHByZWNpYXRlIGFueSBmZWVkYmFjay4NCg0KQmlnIHNob3V0b3V0 IHRvIFZhbGdyaW5kIGRldmVsb3BlcnMgLSB5b3UgaGF2ZSBkb25lIGFuZCBhcmUgZG9pbmcg YW1hemluZyBqb2IhDQpBbGV4DQoNCg0KVG9kZCBSaWNobW9uZCB3cm90ZToNCg0KPiBZb3Vy IGNvZGUgc2hvdWxkIHdvcmsgZmluZSBvbiBhIGdsaWJjIDIuMy4xIHN5c3RlbSBzdWNoIGFz IHBsYWluIHZhbmlsbGEsDQo+IGZyZXNobHkgaW5zdGFsbGVkIFJlZGhhdCA4LiBJZiB5b3Ug cmVxdWlyZSBSZWRoYXQgOSBvciBwYXRjaGVzIHRvIDgod2hpY2gNCj4gbWF5IHVwZ3JhZGUg dG8gMi4zLjIpICwgeW91IHdpbGwgaGF2ZSB0byB3YWl0IGZvciBhIHZhbGdyaW5kIHVwZGF0 ZQ0KPiAgICAgVG9kZA0KPg0KPiAtLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tDQo+IEZy b206ICJKdWxpYW4gU2V3YXJkIiA8anNld2FyZEBhY20ub3JnPg0KPiBUbzogIkFsZXggSXZl cnNoZW4iIDxhbGV4Lml2ZXJzaGVuQGluZXQuY29tPjsgIk5pY2hvbGFzIE5ldGhlcmNvdGUi DQo+IDxuam4yNUBjYW0uYWMudWs+DQo+IENjOiA8dmFsZ3JpbmQtdXNlcnNAbGlzdHMuc291 cmNlZm9yZ2UubmV0Pg0KPiBTZW50OiBUaHVyc2RheSwgQXByaWwgMjQsIDIwMDMgMToyMiBQ TQ0KPiBTdWJqZWN0OiBSZTogW1ZhbGdyaW5kLXVzZXJzXSBWYWxncmluZCdpbmcgbXVsdGlw bGUgdGhyZWFkcw0KPg0KPiA+DQo+ID4gU2lnaCAuLi4NCj4gPg0KPiA+IFN1cmUsIG91ciB0 aHJlYWRpbmcgbGlicmFyeSBub3JtYWxseSBoYW5kbGVzIHRoaXMgZmluZS4gIEhvd2V2ZXIN Cj4gPiB0aGVyZSBhcmUgYmlnIHByb2JsZW1zIG9uIGRlYWxpbmcgd2l0aCB0aHJlYWRpbmcg aW4gc3lzdGVtcw0KPiA+IHdpdGggZ2xpYmMgMi4zLjIgYW5kIGxhdGVyLCBhbmQgdGhpcyBp cyBvbmUgb2YgdGhlbS4NCj4gPg0KPiA+IEFyZSB5b3UgYWJsZSB0byBidWlsZCAvIHJ1biB5 b3VyIGFwcCBvbiBhIGRpc3RybyB3aXRoDQo+ID4gZ2xpYmMgb2YgMi4zLjEgb3IgZWFybGll cj8gIFRoYXQgbWlnaHQgaGVscC4gIChUZXN0IHdpdGgNCj4gPiB5b3VyIHRpbnkgdGVzdCBw cm9ncmFtIGZpcnN0IC4uLikNCj4gPg0KPiA+IEoNCj4gPg0KPiA+DQo+ID4gT24gVGh1cnNk YXkgMjQgQXByaWwgMjAwMyA4OjU0IHBtLCBBbGV4IEl2ZXJzaGVuIHdyb3RlOg0KPiA+ID4g PCFkb2N0eXBlIGh0bWwgcHVibGljICItLy93M2MvL2R0ZCBodG1sIDQuMCB0cmFuc2l0aW9u YWwvL2VuIj4NCj4gPiA+IDxodG1sPg0KPiA+ID4gSGkgYWxsLA0KPiA+ID4gPHA+SSBhbSBv YnNlcnZpbmcgYSBzdHJhbmdlIGJlaGF2aW91ciB3aGlsZSB0cnlpbmcgdG8gdmFsZ3JpbmQg bXkNCj4gPiA+IG11dGxpdGhyZWFkZWQgcHJvZ3JhbXMuJm5ic3A7IEkgd3JvdGUgYSB0cml2 aWFsIHRlc3QgcHJvZ3JhbSB3aXRoIHR3bw0KPiA+ID4gdGhyZWFkcyBhbmQgdGhlIGJlaGF2 aW91ciByZXBsaWNhdGVzIHdoYXQgSSBhbSBzZWVpbmcgaW4gbXkgYXBwcy4gSGVyZQ0KPiBp cw0KPiA+ID4gdGhlIHNjZW5hcmlvIC0gYXBwbGljYXRpb24gc3Bhd25zIHR3byB0aHJlYWRz LiBGaXJzdCBvbmUgb3BlbnMgYSBzb2NrZXQNCj4gYW5kDQo+ID4gPiBpcyBkb2luZyBibG9j a2luZyByZWN2KCkuJm5ic3A7IFRoZW4gdGhlIHNlY29uZCBvbmUgaXMgc3Bhd25lZCB0byBk bw0KPiA+ID4gc29tZXRoaW5nIGVsc2UuJm5ic3A7IFdvcmtzIGp1c3QgZmluZSB3aXRob3V0 IHZhbGdyaW5kLg0KPiA+ID4gPHA+V2hhdCBoYXBwZW5zIGluIHZhbGdyaW5kLCB3aGVuIHRo ZSBmaXJzdCB0aHJlYWQsIHNvY2tldCBsaXN0ZW5lciwgaXMNCj4gPiA+IHNwYXduZWQsIGl0 IGV4ZWN1dGVzIGluIHRoZSBjb250ZXh0IG9mIG1haW4gdGhyZWFkLiBUaGlzIGNhdXNlcyB0 aGUgbWFpbg0KPiA+ID4gdGhyZWFkIHRvIGJsb2NrIG9uIHJlY3YoKSwgYW5kIGFzIGNvbnNl cXVlbmNlIHRoZSBwcm9ncmFtIG5ldmVyIGdvZXMgYW55DQo+ID4gPiBmdXJ0aGVyLCBub3Qg c3Bhd25pbmcgdGhlIHNlY29uZCB0aHJlYWQsIG5vdCBkb2luZyBhbnl0aGluZy4mbmJzcDsg SSBkbw0KPiA+ID4ga25vdyB5b3UgYXJlIHVzaW5nIHlvdXIgb3duIHN1YnN0aXR1dGUgZm9y IHB0aHJlYWRzIGxpYnJhcnksIGJ1dCBJDQo+IGNhbm5vdA0KPiA+ID4gaW1hZ2luZSB0aGF0 IHlvdSBtdXRpbGF0aW5nIGl0IHNvIG11Y2ggYXMgdG8gY29sbGFwc2UgYWxsIGFwcGxpY2F0 aW9uDQo+ID4gPiB0aHJlYWRzIGludG8gb25lLg0KPiA+ID4gPHA+SSBhbSB1c2luZyBSSDgg TGludXggd2l0aCBnbGliYy0yLjMuMi00LjgwLCBrZXJuZWwgMi40LjE4LTI2LjguMHNtcCwN Cj4gPiA+IGNvbXBpbGluZyB3aXRoIGdjYyAyLjk1LjMgKGNhbid0IGdvIGhpZ2hlciBiZWNh dXNlIG9mIHNvdXJjZSBjb2RlDQo+ID4gPiBkZXBlbmRlbmNpZXMgaXNzdWVzKS4gSSBhbSBp bmNsdWRpbmcgc291cmNlIGNvZGUgZm9yIHRoZSBsaXR0bGUgdGVzdA0KPiA+ID4gcHJvZ3Jh bSBhbmQgYmFja3RyYWNlIGFmdGVyIGl0J3Mgc3R1Y2sgaW4gcmVjdigpIC0geW91IGNhbiBz ZWUgdGhhdA0KPiA+ID4gZXZlcnl0aGluZyBpcyBpbiBvbmUgdGhyZWFkLCBhbmQgZ2RiIGRv ZXMgbm90IHNob3cgYW55IG1vcmUgdGhyZWFkcw0KPiA+ID4gd2hhdHNvZXZlci4NCj4gPiA+ IDxwPlNvLCBpZiB5b3UgY291bGQgc29sdmUgdGhlIG15c3RlcnkgZm9yIG1lLCBpdCB3aWxs IGJlIG11Y2gNCj4gYXBwcmVjaWF0ZWQhDQo+ID4gPiBJIGNhbm5vdCB3YWl0IHRvIGdldCBt eSBoYW5kcyBvbiBhbGwgdGhlIGZlYXR1cmVzIHRoYXQgdGhlIG1hbnVhbCB0YWxrcw0KPiA+ ID4gYWJvdXQgLSBhbmQgZnJvbSBnZW5lcmFsIExpbnV4IGNvbW11bml0eSBidXp6IHlvdSBn dXlzIGFyZSBtdWNoIGJldHRlcg0KPiA+ID4gdGhlbiBSYXRpb25hbCBQdXJpZnkuDQo+ID4g PiA8cD5SZWdhcmRzLA0KPiA+ID4gPGJyPkFsZXgNCj4gPiA+IDxwPihnZGIpIGJ0DQo+ID4g PiA8YnI+IzAmbmJzcDsgMHg0MDBiYjI2MiBpbiB2Z1BsYWluX2RvX3N5c2NhbGwgKCkgZnJv bQ0KPiA+ID4gL2hvbWUvYWdpL2xpbnV4L2xpYi92YWxncmluZC92YWxncmluZC5zbyA8YnI+ IzEmbmJzcDsgMHg0MDBhOGMxZSBpbg0KPiA+ID4gdmdJbnRlcmNlcHRfcmVjdiAocz00LCBi dWY9MHg0MGU1M2IxMCwgbGVuPTEwMDAsIGZsYWdzPTApIGF0DQo+ID4gPiB2Z19pbnRlcmNl cHQuYzoxNTINCj4gPiA+IDxicj4jMiZuYnNwOyAweDQwMGE4YzM0IGluIHJlY3YgKHM9NCwg YnVmPTB4NDBlNTNiMTAsIGxlbj0xMDAwLCBmbGFncz0wKQ0KPiA+ID4gYXQgdmdfaW50ZXJj ZXB0LmM6MTU3DQo+ID4gPiA8YnI+IzMmbmJzcDsgMHgwODA0ODc5MCBpbiBMaXN0ZW5lclN0 YXJ0KHZvaWQqKSAocFBhcm09MHgwKSBhdA0KPiBtYWluLmNwcDo1OQ0KPiA+ID4gPGJyPiM0 Jm5ic3A7IDB4NDAxM2E1OGQgaW4gdGhyZWFkX3dyYXBwZXIgKGluZm89MHhmZmZmZmUwMCkg YXQNCj4gPiA+IHZnX2xpYnB0aHJlYWQuYzo2NzEgPGJyPiM1Jm5ic3A7IDB4NDAwOWFiODAg aW4NCj4gPiA+IGRvX19hcHBseV9pbl9uZXdfdGhyZWFkX2JvZ3VzUkEgKCkgYXQgdmdfc2No ZWR1bGVyLmM6MjE1NSA8YnI+IzYmbmJzcDsNCj4gPiA+IDB4MDgwNDg2OTUgaW4gbWFpbiAo KSBhdCBtYWluLmNwcDoyNQ0KPiA+ID4gPGJyPiM3Jm5ic3A7IDB4NDAxNzk0YWQgaW4gX19s aWJjX3N0YXJ0X21haW4gKCkgZnJvbSAvbGliL2xpYmMuc28uNg0KPiA+ID4gPHByZT4tLSZu YnNwOw0KPiA+ID4gQWxleCBHLg0KPiA+ID4NCj4gSXZlcnNoZW4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmDQo+ ID4NCj4gPm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5icw0KPiBwDQo+ID4gPjsmbmJzcDsmbmJzcDsm bmJzcDsgSW5ldCBUZWNobm9sb2dpZXMsIEluYy4gTmV0d29yayBQcm9kdWN0cw0KPiA+ID4N Cj4gRGVwdC4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzDQo+ID4gPnA7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDE1MDAgTi4NCj4gR3JlZW52aWxs ZQ0KPiA+ID4gQXZlLiBJbmV0IFRlY2hub2xvZ2llcw0KPiA+ID4NCj4gSW5jLiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwDQo+ID4gPjsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgUmljaGFyZHNvbiwgVFgNCj4gNzUwODENCj4gPiA+IFBob25l Og0KPiA+ID4NCj4gKzEtNDY5LTMzMC00Mjk1Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo+ID4gPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBV U0ENCj4gPiA+DQo+ID4gPiAiQmxhY2sgSG9sZXMgYXJlIHdoZXJlIEdvZCBkaXZpZGVkIGJ5 IHplcm8iPC9wcmU+DQo+ID4gPiAmbmJzcDs8L2h0bWw+DQo+ID4NCj4gPg0KPiA+DQo+ID4g LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KPiA+IFRoaXMgc2YubmV0IGVtYWlsIGlzIHNwb25zb3JlZCBieTpUaGlua0dlZWsNCj4g PiBXZWxjb21lIHRvIGdlZWsgaGVhdmVuLg0KPiA+IGh0dHA6Ly90aGlua2dlZWsuY29tL3Nm DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4gPiBWYWxncmluZC11c2VycyBtYWlsaW5nIGxpc3QNCj4gPiBWYWxncmluZC11c2Vyc0Bs aXN0cy5zb3VyY2Vmb3JnZS5uZXQNCj4gPiBodHRwczovL2xpc3RzLnNvdXJjZWZvcmdlLm5l dC9saXN0cy9saXN0aW5mby92YWxncmluZC11c2Vycw0KPiA+DQo+DQo+IC0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gVGhpcyBz Zi5uZXQgZW1haWwgaXMgc3BvbnNvcmVkIGJ5OlRoaW5rR2Vlaw0KPiBXZWxjb21lIHRvIGdl ZWsgaGVhdmVuLg0KPiBodHRwOi8vdGhpbmtnZWVrLmNvbS9zZg0KPiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBWYWxncmluZC11c2VycyBt YWlsaW5nIGxpc3QNCj4gVmFsZ3JpbmQtdXNlcnNAbGlzdHMuc291cmNlZm9yZ2UubmV0DQo+ IGh0dHBzOi8vbGlzdHMuc291cmNlZm9yZ2UubmV0L2xpc3RzL2xpc3RpbmZvL3ZhbGdyaW5k LXVzZXJzDQoNCi0tDQpBbGV4IEcuIEl2ZXJzaGVuICAgICAgICAgICAgICAgICAgICAgICAg ICAgIEluZXQgVGVjaG5vbG9naWVzLCBJbmMuDQpOZXR3b3JrIFByb2R1Y3RzIERlcHQuICAg ICAgICAgICAgICAgICAgICAgIDE1MDAgTi4gR3JlZW52aWxsZSBBdmUuDQpJbmV0IFRlY2hu b2xvZ2llcyBJbmMuICAgICAgICAgICAgICAgICAgICAgIFJpY2hhcmRzb24sIFRYIDc1MDgx DQpQaG9uZTogKzEtNDY5LTMzMC00Mjk1ICAgICAgICAgICAgICAgICAgICAgIFVTQQ0KDQoi QmxhY2sgSG9sZXMgYXJlIHdoZXJlIEdvZCBkaXZpZGVkIGJ5IHplcm8iDQoNCg0K |
|
From: Jeff S. <je...@tv...> - 2003-04-24 21:04:04
|
On Thu, 24 Apr 2003, Nicholas Nethercote wrote: > On Thu, 24 Apr 2003, Jeff Sadowski wrote: > > > valgrind 1.9.5 > > and kernel 2.5.68 > > Is there anything spceicial I need to do in order to get it to work? > > Try this patch, courtesy of Anders Gustafsson on Monday :) > Thanks that worked :) > N > > |
|
From: Todd R. <ric...@pr...> - 2003-04-24 20:38:16
|
Your code should work fine on a glibc 2.3.1 system such as plain vanilla,
freshly installed Redhat 8. If you require Redhat 9 or patches to 8(which
may upgrade to 2.3.2) , you will have to wait for a valgrind update
Todd
----- Original Message -----
From: "Julian Seward" <js...@ac...>
To: "Alex Ivershen" <ale...@in...>; "Nicholas Nethercote"
<nj...@ca...>
Cc: <val...@li...>
Sent: Thursday, April 24, 2003 1:22 PM
Subject: Re: [Valgrind-users] Valgrind'ing multiple threads
>
> Sigh ...
>
> Sure, our threading library normally handles this fine. However
> there are big problems on dealing with threading in systems
> with glibc 2.3.2 and later, and this is one of them.
>
> Are you able to build / run your app on a distro with
> glibc of 2.3.1 or earlier? That might help. (Test with
> your tiny test program first ...)
>
> J
>
>
> On Thursday 24 April 2003 8:54 pm, Alex Ivershen wrote:
> > <!doctype html public "-//w3c//dtd html 4.0 transitional//en">
> > <html>
> > Hi all,
> > <p>I am observing a strange behaviour while trying to valgrind my
> > mutlithreaded programs. I wrote a trivial test program with two
> > threads and the behaviour replicates what I am seeing in my apps. Here
is
> > the scenario - application spawns two threads. First one opens a socket
and
> > is doing blocking recv(). Then the second one is spawned to do
> > something else. Works just fine without valgrind.
> > <p>What happens in valgrind, when the first thread, socket listener, is
> > spawned, it executes in the context of main thread. This causes the main
> > thread to block on recv(), and as consequence the program never goes any
> > further, not spawning the second thread, not doing anything. I do
> > know you are using your own substitute for pthreads library, but I
cannot
> > imagine that you mutilating it so much as to collapse all application
> > threads into one.
> > <p>I am using RH8 Linux with glibc-2.3.2-4.80, kernel 2.4.18-26.8.0smp,
> > compiling with gcc 2.95.3 (can't go higher because of source code
> > dependencies issues). I am including source code for the little test
> > program and backtrace after it's stuck in recv() - you can see that
> > everything is in one thread, and gdb does not show any more threads
> > whatsoever.
> > <p>So, if you could solve the mystery for me, it will be much
appreciated!
> > I cannot wait to get my hands on all the features that the manual talks
> > about - and from general Linux community buzz you guys are much better
> > then Rational Purify.
> > <p>Regards,
> > <br>Alex
> > <p>(gdb) bt
> > <br>#0 0x400bb262 in vgPlain_do_syscall () from
> > /home/agi/linux/lib/valgrind/valgrind.so <br>#1 0x400a8c1e in
> > vgIntercept_recv (s=4, buf=0x40e53b10, len=1000, flags=0) at
> > vg_intercept.c:152
> > <br>#2 0x400a8c34 in recv (s=4, buf=0x40e53b10, len=1000, flags=0)
> > at vg_intercept.c:157
> > <br>#3 0x08048790 in ListenerStart(void*) (pParm=0x0) at
main.cpp:59
> > <br>#4 0x4013a58d in thread_wrapper (info=0xfffffe00) at
> > vg_libpthread.c:671 <br>#5 0x4009ab80 in
> > do__apply_in_new_thread_bogusRA () at vg_scheduler.c:2155 <br>#6
> > 0x08048695 in main () at main.cpp:25
> > <br>#7 0x401794ad in __libc_start_main () from /lib/libc.so.6
> > <pre>--
> > Alex G.
> >
Ivershen &
>
>nbsp; &nbs
p
> >; Inet Technologies, Inc. Network Products
> >
Dept. &nbs
> >p; 1500 N.
Greenville
> > Ave. Inet Technologies
> >
Inc.  
> >; Richardson, TX
75081
> > Phone:
> >
+1-469-330-4295
> > USA
> >
> > "Black Holes are where God divided by zero"</pre>
> > </html>
>
>
>
> -------------------------------------------------------
> 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: Julian S. <js...@ac...> - 2003-04-24 20:22:26
|
Sigh ... Sure, our threading library normally handles this fine. However there are big problems on dealing with threading in systems with glibc 2.3.2 and later, and this is one of them. Are you able to build / run your app on a distro with glibc of 2.3.1 or earlier? That might help. (Test with your tiny test program first ...) J On Thursday 24 April 2003 8:54 pm, Alex Ivershen wrote: > <!doctype html public "-//w3c//dtd html 4.0 transitional//en"> > <html> > Hi all, > <p>I am observing a strange behaviour while trying to valgrind my > mutlithreaded programs. I wrote a trivial test program with two > threads and the behaviour replicates what I am seeing in my apps. Here is > the scenario - application spawns two threads. First one opens a socket and > is doing blocking recv(). Then the second one is spawned to do > something else. Works just fine without valgrind. > <p>What happens in valgrind, when the first thread, socket listener, is > spawned, it executes in the context of main thread. This causes the main > thread to block on recv(), and as consequence the program never goes any > further, not spawning the second thread, not doing anything. I do > know you are using your own substitute for pthreads library, but I cannot > imagine that you mutilating it so much as to collapse all application > threads into one. > <p>I am using RH8 Linux with glibc-2.3.2-4.80, kernel 2.4.18-26.8.0smp, > compiling with gcc 2.95.3 (can't go higher because of source code > dependencies issues). I am including source code for the little test > program and backtrace after it's stuck in recv() - you can see that > everything is in one thread, and gdb does not show any more threads > whatsoever. > <p>So, if you could solve the mystery for me, it will be much appreciated! > I cannot wait to get my hands on all the features that the manual talks > about - and from general Linux community buzz you guys are much better > then Rational Purify. > <p>Regards, > <br>Alex > <p>(gdb) bt > <br>#0 0x400bb262 in vgPlain_do_syscall () from > /home/agi/linux/lib/valgrind/valgrind.so <br>#1 0x400a8c1e in > vgIntercept_recv (s=4, buf=0x40e53b10, len=1000, flags=0) at > vg_intercept.c:152 > <br>#2 0x400a8c34 in recv (s=4, buf=0x40e53b10, len=1000, flags=0) > at vg_intercept.c:157 > <br>#3 0x08048790 in ListenerStart(void*) (pParm=0x0) at main.cpp:59 > <br>#4 0x4013a58d in thread_wrapper (info=0xfffffe00) at > vg_libpthread.c:671 <br>#5 0x4009ab80 in > do__apply_in_new_thread_bogusRA () at vg_scheduler.c:2155 <br>#6 > 0x08048695 in main () at main.cpp:25 > <br>#7 0x401794ad in __libc_start_main () from /lib/libc.so.6 > <pre>-- > Alex G. > Ivershen & >nbsp;   >; Inet Technologies, Inc. Network Products > Dept. &nbs >p; 1500 N. Greenville > Ave. Inet Technologies > Inc.   >; Richardson, TX 75081 > Phone: > +1-469-330-4295 > USA > > "Black Holes are where God divided by zero"</pre> > </html> |
|
From: Alex I. <ale...@in...> - 2003-04-24 19:54:26
|
<!doctype html public "-//w3c//dtd html 4.0 transitional//en"> <html> Hi all, <p>I am observing a strange behaviour while trying to valgrind my mutlithreaded programs. I wrote a trivial test program with two threads and the behaviour replicates what I am seeing in my apps. Here is the scenario - application spawns two threads. First one opens a socket and is doing blocking recv(). Then the second one is spawned to do something else. Works just fine without valgrind. <p>What happens in valgrind, when the first thread, socket listener, is spawned, it executes in the context of main thread. This causes the main thread to block on recv(), and as consequence the program never goes any further, not spawning the second thread, not doing anything. I do know you are using your own substitute for pthreads library, but I cannot imagine that you mutilating it so much as to collapse all application threads into one. <p>I am using RH8 Linux with glibc-2.3.2-4.80, kernel 2.4.18-26.8.0smp, compiling with gcc 2.95.3 (can't go higher because of source code dependencies issues). I am including source code for the little test program and backtrace after it's stuck in recv() - you can see that everything is in one thread, and gdb does not show any more threads whatsoever. <p>So, if you could solve the mystery for me, it will be much appreciated! I cannot wait to get my hands on all the features that the manual talks about - and from general Linux community buzz you guys are much better then Rational Purify. <p>Regards, <br>Alex <p>(gdb) bt <br>#0 0x400bb262 in vgPlain_do_syscall () from /home/agi/linux/lib/valgrind/valgrind.so <br>#1 0x400a8c1e in vgIntercept_recv (s=4, buf=0x40e53b10, len=1000, flags=0) at vg_intercept.c:152 <br>#2 0x400a8c34 in recv (s=4, buf=0x40e53b10, len=1000, flags=0) at vg_intercept.c:157 <br>#3 0x08048790 in ListenerStart(void*) (pParm=0x0) at main.cpp:59 <br>#4 0x4013a58d in thread_wrapper (info=0xfffffe00) at vg_libpthread.c:671 <br>#5 0x4009ab80 in do__apply_in_new_thread_bogusRA () at vg_scheduler.c:2155 <br>#6 0x08048695 in main () at main.cpp:25 <br>#7 0x401794ad in __libc_start_main () from /lib/libc.so.6 <pre>-- Alex G. Ivershen Inet Technologies, Inc. Network Products Dept. 1500 N. Greenville Ave. Inet Technologies Inc. Richardson, TX 75081 Phone: +1-469-330-4295 USA "Black Holes are where God divided by zero"</pre> </html> |
|
From: Nicholas N. <nj...@ca...> - 2003-04-24 18:56:03
|
On Thu, 24 Apr 2003, Jeff Sadowski wrote: > valgrind 1.9.5 > and kernel 2.5.68 > Is there anything spceicial I need to do in order to get it to work? Try this patch, courtesy of Anders Gustafsson on Monday :) N |
|
From: Jeff S. <je...@tv...> - 2003-04-24 18:45:24
|
On Thu, 24 Apr 2003, Julian Seward wrote: > > What version of V and what version of the kernel? v-1.9.5 works > with at least some 2.5.Xs. > > J > valgrind 1.9.5 and kernel 2.5.68 Is there anything spceicial I need to do in order to get it to work? > > On Thursday 24 April 2003 7:21 pm, Jeff Sadowski wrote: > > I recently tried out the 2.5.x kernel > > when I try to run valgrind I get the following error message > > > > valgrind.so: When searching for client's argc/argc/envp: > > ELF frame does not look like 2.2.X or 2.4.X. > > See kernel sources linux/fs/binfmt_elf.c to make sense of this. > > valgrind.so: Startup or configuration error: > > couldn't find client's argc/argc/envp > > valgrind.so: Unable to start up properly. Giving up. > > > > I even recompiled valgrind with no problems and I get > > the same error message. > > > > > > > > ------------------------------------------------------- > > 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: Julian S. <js...@ac...> - 2003-04-24 18:29:28
|
What version of V and what version of the kernel? v-1.9.5 works with at least some 2.5.Xs. J On Thursday 24 April 2003 7:21 pm, Jeff Sadowski wrote: > I recently tried out the 2.5.x kernel > when I try to run valgrind I get the following error message > > valgrind.so: When searching for client's argc/argc/envp: > ELF frame does not look like 2.2.X or 2.4.X. > See kernel sources linux/fs/binfmt_elf.c to make sense of this. > valgrind.so: Startup or configuration error: > couldn't find client's argc/argc/envp > valgrind.so: Unable to start up properly. Giving up. > > I even recompiled valgrind with no problems and I get > the same error message. > > > > ------------------------------------------------------- > 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: Jeff S. <je...@tv...> - 2003-04-24 18:21:38
|
I recently tried out the 2.5.x kernel
when I try to run valgrind I get the following error message
valgrind.so: When searching for client's argc/argc/envp:
ELF frame does not look like 2.2.X or 2.4.X.
See kernel sources linux/fs/binfmt_elf.c to make sense of this.
valgrind.so: Startup or configuration error:
couldn't find client's argc/argc/envp
valgrind.so: Unable to start up properly. Giving up.
I even recompiled valgrind with no problems and I get
the same error message.
|