Menu
▾
▴
valgrind-users — General discussion list for Valgrind users
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
(12) |
Oct
(16) |
Nov
(1) |
Dec
|
| 2024 |
Jan
(4) |
Feb
(3) |
Mar
(6) |
Apr
(17) |
May
(2) |
Jun
(33) |
Jul
(13) |
Aug
(1) |
Sep
(6) |
Oct
(8) |
Nov
(6) |
Dec
(15) |
| 2025 |
Jan
(5) |
Feb
(11) |
Mar
(8) |
Apr
(20) |
May
(1) |
Jun
|
Jul
|
Aug
(7) |
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Josef W. <Jos...@gm...> - 2003-06-05 15:26:51
|
On Thursday 05 June 2003 16:34, Alex Ivershen wrote: > Josef, > > With the test classes, I am linking simply as "g++ -o TEST main.o > Classes2.95.3.o". The libgcc.a library seems to be correct to me - that was > built along with the compiler and never gave me any grief. You are saiying > that " Usually, __builtin_new is defined in "libstdc++-libc6.2-2.so.3" and > will be linked in by the runtime library." - however, libstdc++ in my > installation is STATIC, there is a specific requirement not to use any Ok. So this is the culprit, and makes sense: If the (static) linker detects a symbol in different libraries, it prefers symbols from shared libraries and lets the runtime linker do the resolving (this at least seems to be true because __builtin_new is defined as weak (W) in libgcc.a). Then your requirements (only static libs from the compiler) effectively prohibit the use of Valgrind for you. > shared compiler libraries. So, in static libstdc++ __builtin_new are "U" > symbols. The only place the program can pull the definitions from is > libgcc.a. I tried > "-nostdlibraries" swich to the compiler to prevent him from pulling it by > default, but then, of course, the app won't link, citing unresolved > symbols. > > Now, when you do "nm" on your test application, what is the symbol type for > "__builtin_new"? And I am guessing that "ldd" shows dependency on > "libstdc++-libc6.2-2.so.3" - the application expects to resolve it at > run-time from libstdc++ and Valgrind has a chance to intercept everyting, Yes. > right? So, the bottom line seems to be that if I use static libstdc++, I > am screwed? Ugh ... Sure. You can't use Valgrind with static linked binaries, and that seems to hold true with even partial static binaries (as you don't have a "libstdc++-libc6.2-2.so.3"). But perhaps you can link in a shared library of your own with __builtin_new, calling malloc. At least this would allow to run the application with Valgrind, or even better: Put valgrind.so into your link line! Josef > > Alex > > Josef Weidendorfer wrote: > > On Thursday 05 June 2003 00:52, Alex Ivershen wrote: > > > <!doctype html public "-//w3c//dtd html 4.0 transitional//en"> > > > <html> > > > Gentlemen, > > > <p>I am still having issues with __builtin_new not being intercepted by > > > Valgrind. Jeremy Fitzhardinge gave me some suggestions, but it > > > did not solve the issue. Here is the problem: when I am compling > > > certain classes, the compiler generates references to __builtin_new > > > (vec_new, delete, vec_delete) in the object file. When this > > > object file is linked into executable, the compiler resolves the > > > __builtin* references from libgcc.a, where they are defined as "W" > > > symbols. > > > <p>As a result, Valgrind does NOT intercept those __builtin* > > > functions, and only catches malloc() and free() calls when these > > > classes are used. As you can imagine, a swarm of musmatched > > > free/delete/delete[] is > > > > Your object files seem to be fine. > > The problem is, that the static link process shouldn't resolve > > __builtin_new, i.e. the libgcc.a you mention seems to be wrong, if it > > really defines __builtin_new statically. Perhaps this file shouldn't be > > linked in or is from a wrong compiler version? Or you do some partial > > static linking. What's your link command line? > > > > I just checked with my own installation of GCC 2.95.3 (Suse8.1). > > If I compile your Classes2.95.3.o with a dummy main(), it links fine, and > > in the resulting executable, there *is* the symbol __builtin_new, so > > there will be no problem with valgrind ?!? > > Usually, "__builtin_new" is defined in "libstdc++-libc6.2-2.so.3" and > > will be linked in by the runtime library. > > > > Josef > > -- > 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 > > "Computer games don't affect kids; I mean if Pac-Man affected us as kids, > we'd all be running around in darkened rooms, munching magic pills and > listening to repetitive electronic music." -- Kristian Wilson, Nintendo, > Inc |
|
From: Alex I. <ale...@in...> - 2003-06-05 14:37:13
|
Sm9zZWYsDQoNCldpdGggdGhlIHRlc3QgY2xhc3NlcywgSSBhbSBsaW5raW5nIHNpbXBseSBh cyAiZysrIC1vIFRFU1QgbWFpbi5vDQpDbGFzc2VzMi45NS4zLm8iLiBUaGUgbGliZ2NjLmEg bGlicmFyeSBzZWVtcyB0byBiZSBjb3JyZWN0IHRvIG1lIC0gdGhhdCB3YXMNCmJ1aWx0IGFs b25nIHdpdGggdGhlIGNvbXBpbGVyIGFuZCBuZXZlciBnYXZlIG1lIGFueSBncmllZi4gIFlv dSBhcmUgc2FpeWluZyB0aGF0DQoiIFVzdWFsbHksIF9fYnVpbHRpbl9uZXcgaXMgZGVmaW5l ZCBpbiAibGlic3RkYysrLWxpYmM2LjItMi5zby4zIiBhbmQgd2lsbCBiZQ0KbGlua2VkIGlu IGJ5IHRoZSBydW50aW1lIGxpYnJhcnkuIiAtIGhvd2V2ZXIsIGxpYnN0ZGMrKyBpbiBteSBp bnN0YWxsYXRpb24gaXMNClNUQVRJQywgdGhlcmUgaXMgYSBzcGVjaWZpYyByZXF1aXJlbWVu dCBub3QgdG8gdXNlIGFueSBzaGFyZWQgY29tcGlsZXINCmxpYnJhcmllcy4gU28sIGluIHN0 YXRpYyBsaWJzdGRjKysgX19idWlsdGluX25ldyBhcmUgIlUiIHN5bWJvbHMuIFRoZSBvbmx5 IHBsYWNlDQp0aGUgcHJvZ3JhbSBjYW4gcHVsbCB0aGUgZGVmaW5pdGlvbnMgZnJvbSBpcyBs aWJnY2MuYS4gIEkgdHJpZWQNCiItbm9zdGRsaWJyYXJpZXMiIHN3aWNoIHRvIHRoZSBjb21w aWxlciB0byBwcmV2ZW50IGhpbSBmcm9tIHB1bGxpbmcgaXQgYnkNCmRlZmF1bHQsIGJ1dCB0 aGVuLCBvZiBjb3Vyc2UsIHRoZSBhcHAgd29uJ3QgbGluaywgY2l0aW5nICB1bnJlc29sdmVk IHN5bWJvbHMuDQoNCk5vdywgd2hlbiB5b3UgZG8gIm5tIiBvbiB5b3VyIHRlc3QgYXBwbGlj YXRpb24sIHdoYXQgaXMgdGhlIHN5bWJvbCB0eXBlIGZvcg0KIl9fYnVpbHRpbl9uZXciPyAg QW5kIEkgYW0gZ3Vlc3NpbmcgdGhhdCAibGRkIiBzaG93cyBkZXBlbmRlbmN5IG9uDQoibGli c3RkYysrLWxpYmM2LjItMi5zby4zIiAtIHRoZSBhcHBsaWNhdGlvbiBleHBlY3RzIHRvIHJl c29sdmUgaXQgYXQgcnVuLXRpbWUNCmZyb20gbGlic3RkYysrIGFuZCBWYWxncmluZCBoYXMg YSBjaGFuY2UgdG8gaW50ZXJjZXB0IGV2ZXJ5dGluZywgcmlnaHQ/ICBTbywgdGhlDQpib3R0 b20gbGluZSBzZWVtcyB0byBiZSB0aGF0IGlmIEkgdXNlIHN0YXRpYyBsaWJzdGRjKyssIEkg YW0gc2NyZXdlZD8gVWdoIC4uLg0KDQpBbGV4DQoNCg0KSm9zZWYgV2VpZGVuZG9yZmVyIHdy b3RlOg0KDQo+IE9uIFRodXJzZGF5IDA1IEp1bmUgMjAwMyAwMDo1MiwgQWxleCBJdmVyc2hl biB3cm90ZToNCj4gPiA8IWRvY3R5cGUgaHRtbCBwdWJsaWMgIi0vL3czYy8vZHRkIGh0bWwg NC4wIHRyYW5zaXRpb25hbC8vZW4iPg0KPiA+IDxodG1sPg0KPiA+IEdlbnRsZW1lbiwNCj4g PiA8cD5JIGFtIHN0aWxsIGhhdmluZyBpc3N1ZXMgd2l0aCBfX2J1aWx0aW5fbmV3IG5vdCBi ZWluZyBpbnRlcmNlcHRlZCBieQ0KPiA+IFZhbGdyaW5kLiZuYnNwOyBKZXJlbXkgRml0emhh cmRpbmdlIGdhdmUgbWUgc29tZSBzdWdnZXN0aW9ucywgYnV0IGl0IGRpZA0KPiA+IG5vdCBz b2x2ZSB0aGUgaXNzdWUuIEhlcmUgaXMgdGhlIHByb2JsZW06IHdoZW4gSSBhbSBjb21wbGlu ZyBjZXJ0YWluDQo+ID4gY2xhc3NlcywgdGhlIGNvbXBpbGVyIGdlbmVyYXRlcyByZWZlcmVu Y2VzIHRvIF9fYnVpbHRpbl9uZXcgKHZlY19uZXcsDQo+ID4gZGVsZXRlLCB2ZWNfZGVsZXRl KSBpbiB0aGUgb2JqZWN0IGZpbGUuJm5ic3A7IFdoZW4gdGhpcyBvYmplY3QgZmlsZSBpcw0K PiA+IGxpbmtlZCBpbnRvIGV4ZWN1dGFibGUsIHRoZSBjb21waWxlciByZXNvbHZlcyB0aGUg X19idWlsdGluKiByZWZlcmVuY2VzDQo+ID4gZnJvbSBsaWJnY2MuYSwgd2hlcmUgdGhleSBh cmUgZGVmaW5lZCBhcyAiVyIgc3ltYm9scy4NCj4gPiA8cD5BcyBhIHJlc3VsdCwmbmJzcDsg VmFsZ3JpbmQgZG9lcyBOT1QgaW50ZXJjZXB0IHRob3NlIF9fYnVpbHRpbioNCj4gPiBmdW5j dGlvbnMsIGFuZCBvbmx5IGNhdGNoZXMgbWFsbG9jKCkgYW5kIGZyZWUoKSBjYWxscyB3aGVu IHRoZXNlIGNsYXNzZXMNCj4gPiBhcmUgdXNlZC4gQXMgeW91IGNhbiBpbWFnaW5lLCBhIHN3 YXJtIG9mIG11c21hdGNoZWQgZnJlZS9kZWxldGUvZGVsZXRlW10gaXMNCj4NCj4gWW91ciBv YmplY3QgZmlsZXMgc2VlbSB0byBiZSBmaW5lLg0KPiBUaGUgcHJvYmxlbSBpcywgdGhhdCB0 aGUgc3RhdGljIGxpbmsgcHJvY2VzcyBzaG91bGRuJ3QgcmVzb2x2ZSBfX2J1aWx0aW5fbmV3 LA0KPiBpLmUuIHRoZSBsaWJnY2MuYSB5b3UgbWVudGlvbiBzZWVtcyB0byBiZSB3cm9uZywg aWYgaXQgcmVhbGx5IGRlZmluZXMNCj4gX19idWlsdGluX25ldyBzdGF0aWNhbGx5LiBQZXJo YXBzIHRoaXMgZmlsZSBzaG91bGRuJ3QgYmUgbGlua2VkIGluIG9yIGlzIGZyb20NCj4gYSB3 cm9uZyBjb21waWxlciB2ZXJzaW9uPyBPciB5b3UgZG8gc29tZSBwYXJ0aWFsIHN0YXRpYyBs aW5raW5nLiBXaGF0J3MgeW91cg0KPiBsaW5rIGNvbW1hbmQgbGluZT8NCj4NCj4gSSBqdXN0 IGNoZWNrZWQgd2l0aCBteSBvd24gaW5zdGFsbGF0aW9uIG9mIEdDQyAyLjk1LjMgKFN1c2U4 LjEpLg0KPiBJZiBJIGNvbXBpbGUgeW91ciBDbGFzc2VzMi45NS4zLm8gd2l0aCBhIGR1bW15 IG1haW4oKSwgaXQgbGlua3MgZmluZSwgYW5kIGluDQo+IHRoZSByZXN1bHRpbmcgZXhlY3V0 YWJsZSwgdGhlcmUgKmlzKiB0aGUgc3ltYm9sIF9fYnVpbHRpbl9uZXcsIHNvIHRoZXJlIHdp bGwNCj4gYmUgbm8gcHJvYmxlbSB3aXRoIHZhbGdyaW5kID8hPw0KPiBVc3VhbGx5LCAiX19i dWlsdGluX25ldyIgaXMgZGVmaW5lZCBpbiAibGlic3RkYysrLWxpYmM2LjItMi5zby4zIiBh bmQgd2lsbCBiZQ0KPiBsaW5rZWQgaW4gYnkgdGhlIHJ1bnRpbWUgbGlicmFyeS4NCj4NCj4g Sm9zZWYNCg0KLS0NCkFsZXggRy4gSXZlcnNoZW4gICAgICAgICAgICAgICAgICAgICAgICAg ICAgSW5ldCBUZWNobm9sb2dpZXMsIEluYy4NCk5ldHdvcmsgUHJvZHVjdHMgRGVwdC4gICAg ICAgICAgICAgICAgICAgICAgMTUwMCBOLiBHcmVlbnZpbGxlIEF2ZS4NCkluZXQgVGVjaG5v bG9naWVzIEluYy4gICAgICAgICAgICAgICAgICAgICAgUmljaGFyZHNvbiwgVFggNzUwODEN ClBob25lOiArMS00NjktMzMwLTQyOTUgICAgICAgICAgICAgICAgICAgICAgVVNBDQoNCiJD b21wdXRlciBnYW1lcyBkb24ndCBhZmZlY3Qga2lkczsgSSBtZWFuIGlmIFBhYy1NYW4gYWZm ZWN0ZWQgdXMgYXMga2lkcywgd2UnZA0KYWxsIGJlIHJ1bm5pbmcgYXJvdW5kIGluIGRhcmtl bmVkIHJvb21zLCBtdW5jaGluZyBtYWdpYyBwaWxscyBhbmQgbGlzdGVuaW5nIHRvDQpyZXBl dGl0aXZlIGVsZWN0cm9uaWMgbXVzaWMuIiAtLSBLcmlzdGlhbiBXaWxzb24sIE5pbnRlbmRv LCBJbmMNCg0KDQo= |
|
From: Josef W. <Jos...@gm...> - 2003-06-05 07:57:47
|
On Thursday 05 June 2003 00:52, Alex Ivershen wrote: > <!doctype html public "-//w3c//dtd html 4.0 transitional//en"> > <html> > Gentlemen, > <p>I am still having issues with __builtin_new not being intercepted by > Valgrind. Jeremy Fitzhardinge gave me some suggestions, but it did > not solve the issue. Here is the problem: when I am compling certain > classes, the compiler generates references to __builtin_new (vec_new, > delete, vec_delete) in the object file. When this object file is > linked into executable, the compiler resolves the __builtin* references > from libgcc.a, where they are defined as "W" symbols. > <p>As a result, Valgrind does NOT intercept those __builtin* > functions, and only catches malloc() and free() calls when these classes > are used. As you can imagine, a swarm of musmatched free/delete/delete[] is Your object files seem to be fine. The problem is, that the static link process shouldn't resolve __builtin_new, i.e. the libgcc.a you mention seems to be wrong, if it really defines __builtin_new statically. Perhaps this file shouldn't be linked in or is from a wrong compiler version? Or you do some partial static linking. What's your link command line? I just checked with my own installation of GCC 2.95.3 (Suse8.1). If I compile your Classes2.95.3.o with a dummy main(), it links fine, and in the resulting executable, there *is* the symbol __builtin_new, so there will be no problem with valgrind ?!? Usually, "__builtin_new" is defined in "libstdc++-libc6.2-2.so.3" and will be linked in by the runtime library. Josef |
|
From: Nicholas N. <nj...@ca...> - 2003-06-05 07:17:52
|
On Wed, 4 Jun 2003, Bastien Chevreux wrote: > On Wednesday 04 June 2003 22:44, Patrick McFarland wrote: > > When valgrind says "Conditional jump or move depends on uninitialised > > value(s)" does this mean it _has_ happened or _can_ happen? > > Has. To be super-precise: is just about to (ie. next instruction). N |
|
From: Artur W. <wi...@th...> - 2003-06-05 06:23:26
|
Thanks, it works now ! Nicholas Nethercote wrote: > On Wed, 4 Jun 2003, Artur Wisz wrote: > > >>it looks like malloc_usable_size cannot be used with valgrind. Are there >>any hopes it will be implemented in the foreseeable future ? >> > > It is supported in the latest development version. > > Grab it from CVS from sourceforge.net/cvs/?group_id=46268, build it by > following the instructions in "README". > > N > > > -- Dipl.-Ing. Artur Wisz Forschung & Entwicklung THB Bury GmbH & Co KG wi...@th... |
|
From: Alex I. <ale...@in...> - 2003-06-04 22:59:22
|
<!doctype html public "-//w3c//dtd html 4.0 transitional//en"> <html> Gentlemen, <p>I am still having issues with __builtin_new not being intercepted by Valgrind. Jeremy Fitzhardinge gave me some suggestions, but it did not solve the issue. Here is the problem: when I am compling certain classes, the compiler generates references to __builtin_new (vec_new, delete, vec_delete) in the object file. When this object file is linked into executable, the compiler resolves the __builtin* references from libgcc.a, where they are defined as "W" symbols. <p>As a result, Valgrind does NOT intercept those __builtin* functions, and only catches malloc() and free() calls when these classes are used. As you can imagine, a swarm of musmatched free/delete/delete[] is evoked, plus the validity of memory checks probably becomes questionable. <p>Now, this is happening when I am using gcc 2.95.3 ( and g++ as linker). If I compile with gcc 3.2, references to __builtin* are not generated, instead it generated references to "operator new" and its buddies - that works well with Valgrind. Unfortunately, I cannot compile my system with 3.2 - I am stuck with 2.95.3 for the time being. There is a lot of code in the system that does not compile with 3.2 and fixing the code is not a choice (it's millions of lines). <p>I am attaching a cheesy test case - definition of 3 classes plus two object files generated by 2.95.3 and 3.2 compilers. Please, if anyone can give me a hint how this problem may be circumvented, that would be awesome and merit at least a six-pack! :) <p>Looking forward to suggestions! <br>Regards, <br>Alex Ivershen <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</pre> </html> |
|
From: Bastien C. <ba...@ch...> - 2003-06-04 20:57:20
|
On Wednesday 04 June 2003 22:44, Patrick McFarland wrote:
> When valgrind says "Conditional jump or move depends on uninitialised
> value(s)" does this mean it _has_ happened or _can_ happen?
Has.
B.
--
-- The universe has its own cure for stupidity. --
-- Unfortunately, it doesn't always apply it. --
|
|
From: Patrick M. <un...@pa...> - 2003-06-04 20:45:46
|
When valgrind says "Conditional jump or move depends on uninitialised value(s)" does this mean it _has_ happened or _can_ happen? -- Patrick "Diablo-D3" McFarland || un...@pa... "Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd all be running around in darkened rooms, munching magic pills and listening to repetitive electronic music." -- Kristian Wilson, Nintendo, Inc, 1989 |
|
From: Vincent Penquerc'h <Vin...@ar...> - 2003-06-04 09:36:38
|
> In order to get valgrind to run, what cflags must I compile > my system with? > so far I've tried march=pentium3 -O2 -fomit-frame-pointer and > march=i686 -O2 > -fomit-frame-pointer Don't you directly make bzImage or something similar ? > and both of them give me an error about some CS thing which I > was told has to > do with teh CFLAGS I use to compile my system.. Reading the code, CS segment overrides aren't supported, though data seg overrides are. I guess this is it. > So basically, if any of you have compiled your linux system > from source could > you please tell me what CFLAGS you used to get valgrind to debug your > programs. I compiled my current kernel (2.2.10) with the default Makefile, and Valgrind works fine. Another machine with 2.4.13 was compiled with Pentium 2 opts IIRC, and Valgrind works fine too. Maybe the culprit is the particular kernel you use, which happens to use CS overrides ? -- Vincent Penquerc'h |
|
From: Nicholas N. <nj...@ca...> - 2003-06-04 08:26:43
|
On Wed, 4 Jun 2003, Artur Wisz wrote: > it looks like malloc_usable_size cannot be used with valgrind. Are there > any hopes it will be implemented in the foreseeable future ? It is supported in the latest development version. Grab it from CVS from sourceforge.net/cvs/?group_id=46268, build it by following the instructions in "README". N |
|
From: Robert W. <rj...@du...> - 2003-06-04 08:22:37
|
> it looks like malloc_usable_size cannot be used with valgrind. Are there=20 > any hopes it will be implemented in the foreseeable future ? It's in the current CVS head and seems to work fine. Regards, Robert. --=20 Robert Walsh Amalgamated Durables, Inc. - "We don't make the things you buy." Email: rj...@du... |
|
From: Artur W. <wi...@th...> - 2003-06-04 08:08:30
|
Hello, it looks like malloc_usable_size cannot be used with valgrind. Are there any hopes it will be implemented in the foreseeable future ? Thanks, Artur |
|
From: Eric P. <eri...@ce...> - 2003-06-04 07:39:02
|
Hello, Thanks for your fast and precise answers. You must be right, the gcc compiled valgrind should be sufficient. FYI: I have been asked to provide a set of tools (libraries and binaries) compiled with icc (32bits) and ecc (64bits). I tried to compile valgrind with gcc (64bits) but got a message saying it is ix86 specific, so no valgrind on 64bits machine. Regards. Arnaud Desitter wrote: > ----- Original Message ----- > From: "Nicholas Nethercote" <nj...@ca...> > To: "Eric Poinsignon" <eri...@ce...> > Cc: <val...@li...> > Sent: Tuesday, June 03, 2003 4:00 PM > Subject: Re: [Valgrind-users] Valgrind 1.9.6 compilation with the Intel > compiler icc > > > >>On Tue, 3 Jun 2003, Eric Poinsignon wrote: >> >> >>>I am trying to compile Valgrind with the Intel compiler icc 7.1. >>>But the "configure" command does not accept icc. >> >>Valgrind requires gcc, it uses various gcc-specific features. >> >> >>>Does anybody know a way to compile valgrind with icc ? >> >>Julian got it working a while ago, but it required a few changes. >> >>Can I ask why you are trying to use the Intel compiler? Presumably you >>have gcc on your Linux system. If you are using it to get better >>performance, there's not much point because Valgrind spends most of its >>time in code it generates itself. > > > For record, valgrind runs fine any code generated by icc (and ifc if that is > relevant) as long as the sse instructions are avoided. > > Regards, > > > -- Eric Poinsignon (Eri...@ce...) Bldg 32,R-B03 CERN-EP-SFT LCG - AppArea - LCG Software Process & Infrastructure http://spi.cern.ch/extsoft/ http://spi.cern.ch/lcgsoft/ Tel : +41 (0) 22 767 9157 Fax : not available yet. ICQ#: 52035855 |
|
From: Patrick M. <un...@pa...> - 2003-06-03 22:55:46
|
On 03-Jun-2003, David Eriksson wrote: > On Tue, 2003-06-03 at 19:51, Patrick McFarland wrote: > > Hi, Ive just started using valgrind, and Im getting odd errors reported by > > valgrind: > > > > "Conditional jump or move depends on uninitialised value(s)" from code that > > uses a if/else checking if foo == NULL or not > > Then "foo" hasn't been initialized where it came from. Check the > backtrace. I know it has been initalized. Its being set by a function that either returns a memory pointer _that must be valid_, or NULL. > > "Invalid write of size 1" when freeing. > > Maybe freeing the same memory twice? Double checked, Im not. > > "Use of uninitialised value of size x" when using GLfloat foo = bar; (or any > > typedefed type for that matter) > > Probably "bar" hasn't been initialized where it came from. Check the > backtrace. Double checked this as well. bar always has to be initialized correctly. BTW, has there been any problems with either debian sid's build, or valgrind in conjunction with sid's gcc 3.3.x and/or libc? -- Patrick "Diablo-D3" McFarland || un...@pa... "Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd all be running around in darkened rooms, munching magic pills and listening to repetitive electronic music." -- Kristian Wilson, Nintendo, Inc, 1989 |
|
From: David E. <da...@2g...> - 2003-06-03 18:17:30
|
On Tue, 2003-06-03 at 19:51, Patrick McFarland wrote: > Hi, Ive just started using valgrind, and Im getting odd errors reported by > valgrind: > > "Conditional jump or move depends on uninitialised value(s)" from code that > uses a if/else checking if foo == NULL or not Then "foo" hasn't been initialized where it came from. Check the backtrace. > "Invalid write of size 1" when freeing. Maybe freeing the same memory twice? > "Use of uninitialised value of size x" when using GLfloat foo = bar; (or any > typedefed type for that matter) Probably "bar" hasn't been initialized where it came from. Check the backtrace. > How do I fix these, or do I just ignore them? At least don't ignore them if it's your own code :-) -- -\- David Eriksson -/- www.2GooD.nu "I personally refuse to use inferior tools because of ideology." - Linus Torvalds |
|
From: Patrick M. <un...@pa...> - 2003-06-03 17:52:32
|
Hi, Ive just started using valgrind, and Im getting odd errors reported by valgrind: "Conditional jump or move depends on uninitialised value(s)" from code that uses a if/else checking if foo == NULL or not "Invalid write of size 1" when freeing. "Use of uninitialised value of size x" when using GLfloat foo = bar; (or any typedefed type for that matter) How do I fix these, or do I just ignore them? -- Patrick "Diablo-D3" McFarland || un...@pa... "Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd all be running around in darkened rooms, munching magic pills and listening to repetitive electronic music." -- Kristian Wilson, Nintendo, Inc, 1989 |
|
From: Joshua Moore-O. <jo...@ch...> - 2003-06-03 17:32:53
|
In order to get valgrind to run, what cflags must I compile my system with? so far I've tried march=pentium3 -O2 -fomit-frame-pointer and march=i686 -O2 -fomit-frame-pointer and both of them give me an error about some CS thing which I was told has to do with teh CFLAGS I use to compile my system.. So basically, if any of you have compiled your linux system from source could you please tell me what CFLAGS you used to get valgrind to debug your programs. Thanks Josh. |
|
From: Arnaud D. <arn...@ge...> - 2003-06-03 16:02:58
|
----- Original Message ----- From: "Nicholas Nethercote" <nj...@ca...> To: "Eric Poinsignon" <eri...@ce...> Cc: <val...@li...> Sent: Tuesday, June 03, 2003 4:00 PM Subject: Re: [Valgrind-users] Valgrind 1.9.6 compilation with the Intel compiler icc > On Tue, 3 Jun 2003, Eric Poinsignon wrote: > > > I am trying to compile Valgrind with the Intel compiler icc 7.1. > > But the "configure" command does not accept icc. > > Valgrind requires gcc, it uses various gcc-specific features. > > > Does anybody know a way to compile valgrind with icc ? > > Julian got it working a while ago, but it required a few changes. > > Can I ask why you are trying to use the Intel compiler? Presumably you > have gcc on your Linux system. If you are using it to get better > performance, there's not much point because Valgrind spends most of its > time in code it generates itself. For record, valgrind runs fine any code generated by icc (and ifc if that is relevant) as long as the sse instructions are avoided. Regards, |
|
From: Nicholas N. <nj...@ca...> - 2003-06-03 15:00:44
|
On Tue, 3 Jun 2003, Eric Poinsignon wrote: > I am trying to compile Valgrind with the Intel compiler icc 7.1. > But the "configure" command does not accept icc. Valgrind requires gcc, it uses various gcc-specific features. > Does anybody know a way to compile valgrind with icc ? Julian got it working a while ago, but it required a few changes. Can I ask why you are trying to use the Intel compiler? Presumably you have gcc on your Linux system. If you are using it to get better performance, there's not much point because Valgrind spends most of its time in code it generates itself. HTH N |
|
From: Eric P. <eri...@ce...> - 2003-06-03 14:31:49
|
Hello valgrind users,
I am trying to compile Valgrind with the Intel compiler icc 7.1.
But the "configure" command does not accept icc.
Here is the "configure" output:
# setenv CC icc
# setenv CXX icc
# ./configure --prefix `pwd`
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for gawk... gawk
checking whether make sets ${MAKE}... yes
checking whether to enable maintainer-specific portions of Makefiles... no
checking whether ln -s works... yes
checking for gcc... icc
checking for C compiler default output... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... no
checking whether icc accepts -g... yes
checking for style of include used by make... GNU
checking dependency style of icc... gcc3
checking how to run the C preprocessor... icc -E
checking whether we are using the GNU C++ compiler... no
checking whether icc accepts -g... yes
checking dependency style of icc... gcc3
checking for ranlib... ranlib
configure: error: Valgrind relies on GCC to be compiled
#
Does anybody know a way to compile valgrind with icc ?
Thanks.
Regards.
--
Eric Poinsignon (Eri...@ce...) Bldg 32,R-B03
CERN-EP-SFT
LCG - AppArea - LCG Software Process & Infrastructure
http://spi.cern.ch/extsoft/
Tel : +41 (0) 22 767 9157 Fax : not available yet.
ICQ#: 52035855
|
|
From: Abhijeet B. <ab...@qu...> - 2003-06-02 17:25:21
|
I tried that same thing as the other user , removed GLIBC 2.2.3 block and it works. Thanks, Abhijeet At 05:55 PM 6/2/2003 +0100, Olly Betts wrote: >On Mon, Jun 02, 2003 at 09:39:03AM -0700, Abhijeet Bisain wrote: > > relocation error: /lib/librt.so.1: symbol __pthread_clock_settime, version > > GLIBC_VERSION not defined in file libpthread.so.0 with the link time > > reference. > > > > I am running this on redhat 7.3 and the code makes a call to > > lock_gettime and links with librt. I read in the FAQ that the valgrind > > has its own implementation of pthreads and so is it possible that this > > symbol is not defined in valgrind's libpthread? > >It's a symbol which is meant to be private to the pthread >implementation, but unfortunately librt uses it. > >Did you fully read the answer to FAQ Q13? It has a suggestion for a way >to fix this problem, and notes it worked for at least one person. If it >works for other people too, it might be worth considering for a future >valgrind release, so it would be useful to try it... > >Cheers, > Olly > > >------------------------------------------------------- >This SF.net email is sponsored by: eBay >Get office equipment for less on eBay! >http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 >_______________________________________________ >Valgrind-users mailing list >Val...@li... >https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: Olly B. <ol...@su...> - 2003-06-02 16:56:25
|
On Mon, Jun 02, 2003 at 09:39:03AM -0700, Abhijeet Bisain wrote:
> relocation error: /lib/librt.so.1: symbol __pthread_clock_settime, version
> GLIBC_VERSION not defined in file libpthread.so.0 with the link time
> reference.
>
> I am running this on redhat 7.3 and the code makes a call to
> lock_gettime and links with librt. I read in the FAQ that the valgrind
> has its own implementation of pthreads and so is it possible that this
> symbol is not defined in valgrind's libpthread?
It's a symbol which is meant to be private to the pthread
implementation, but unfortunately librt uses it.
Did you fully read the answer to FAQ Q13? It has a suggestion for a way
to fix this problem, and notes it worked for at least one person. If it
works for other people too, it might be worth considering for a future
valgrind release, so it would be useful to try it...
Cheers,
Olly
|
|
From: Abhijeet B. <ab...@qu...> - 2003-06-02 16:39:12
|
Hi, I just started using Valgrind and could successfully run it on some of my code. But on some executables that use pthreads, I get the following error: relocation error: /lib/librt.so.1: symbol __pthread_clock_settime, version GLIBC_VERSION not defined in file libpthread.so.0 with the link time reference. I am running this on redhat 7.3 and the code makes a call to clock_gettime and links with librt. I read in the FAQ that the valgrind has its own implementation of pthreads and so is it possible that this symbol is not defined in valgrind's libpthread? Any help on this would be appreciated. Thanks, Abhijeet |
|
From: Nicholas N. <nj...@ca...> - 2003-06-02 11:54:28
|
On Mon, 2 Jun 2003, Melchior FRANZ wrote: > * Melchior FRANZ -- Friday 02 May 2003 18:33: > > [...] I suggest the following patch. > > This patch has now been ignored for exactly one month. Do I have > to consider it rejected? Because it deals with joysticks, which is > children stuff and not taken seriously? Other reasons? :-) Other reasons? Lack of time. We haven't integrated/addressed your patch, but that doesn't mean we have ignored it. And don't think you're alone in having contributed a patch that hasn't been integrated... Julian Seward is Valgrind's main developer. He spent two years writing Valgrind in his spare time. When it was first released, he took 6 months off work to develop it full time, unpaid. Valgrind's robustness can be largely attributed to the effort he put in chasing down bugs in this time. He now has a full-time non-Valgrind job, and thus has limited time to work on Valgrind. He is the expert on Valgrind's synthetic CPU, and all the OS-specific stuff, such as threads, signals, system calls, etc. The OS-specific stuff happens to be the most fragile and bug-prone part of Valgrind, so Julian spends a lot of his (limited) Valgrind time on fixing bugs in these parts. He also spends a lot of time testing on various Linux configurations, and managing releases. I guess I'd call myself the second developer. I'm a PhD student, and joined the show when Valgrind was first released, a bit over one year ago. My PhD is based around using Valgrind, which means I have a bit more time to spend on it for maintenance, but primarily I'm using it as a vehicle for research; time I spend maintaining it is time I'm not doing research. I try to fix bugs, make improvements, etc. that people submit, but my area of expertise is the core/skin split and instrumentation side, plus Cachegrind. I try to fix as many bugs as I can, but many of them are beyond my area of expertise. Some other people have contributed significant amounts to Valgrind, such as Jeremy Fitzhardinge (Helgrind, lots of other stuff), Josef Weidendorfer (KCachegrind, other core stuff), Dirk Mueller, and probably lots of others I haven't mentioned. AIUI, for these people Valgrind is something that they can't spend huge amounts of time on. Another point worth mentioning is that Valgrind is a fairly complicated piece of software, now beyond what one person can keep in his/her head, and it has very complex interactions with your system that mean it is fragile in many ways. Thus we have to be careful when making changes, particularly ones related to operating system stuff, such as your patch. I currently have 40 emails in my inbox, 36 of which are Valgrind related, being bug reports, patches, suggestions for features, and questions. I also have tens of other similar emails which are stagnating in other folders. Julian probably has more. The problem is time, or lack of it. The reason Julian started this list was to try and improve the feedback users were getting, since he and I can't deal with all the mail we get. We have an implicit triage system; if something is reported only once, we will probably address it if it is bad, and can be addressed without massive amounts of effort. Also, if something is mentioned more than once, it's much more likely to be addressed. For example, Julian implemented support for leak suppressions because lots of people requested it. I implemented support for automatic suppression generation (not in 1.9.6, but in the CVS HEAD) because lots of people asked for it. Julian worked quite hard to get Valgrind working with RH9 to handle the new thread library because lots of people sent bug reports. Your patch is small, you're the only one who has mentioned it, and you've obviously worked out how to fix it yourself. This makes it a fairly low priority. You also submitted it just before the 1.9.6 release came out, too late to include in that release. No release has come out since. It's possible it will be included in 1.9.7. The fact that you sent a patch, rather than just a bug report, is a big help too; it makes our lives much easier, so thank you for that. The fact that it is small and simple also helps. I don't wish to complain, it's great that so many people are using Valgrind, reporting bugs, submitting patches, making suggestions. I can only speak for myself: I read and consider every Valgrind-related email that I receive, but I don't/can't respond to every one, due to lack of time and/or expertise. Julian has more expertise than me, but less time. Please appreciate the time constraints that face us. N |
|
From: <199...@ex...> - 2003-06-02 10:25:14
|
Please see the attached file. |
188 messages has been excluded from this view by a project administrator.
