From: Alex I. <ale...@in...> - 2003-06-04 22:59:22
Attachments:
classes.tar.gz
|
<!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: 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: 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 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 18:14:25
|
Sm9zZWYsDQoNCkkgdGhhbmsgeW91IHNvIG11Y2ggZm9yIHlvdXIgYXNzaXRhbmNlISBDbGVh cmVkIHVwIHRoaW5ncyBmb3IgbWUgcXVpdGUgYSBiaXQuDQpXaGF0IEkgcmVzb3J0ZWQgdG8g ZG9pbmcgaXMgYnVpbGRpbmcgYSBzaGFyZWQgbGlic3RkYysrIGxpYnJhcnkgYW5kIGZvcmNl DQppbi1ob3VzZSBidWlsZHMgdG8gdXNlIHRoZSBzaGFyZWQgbGlicmFyeSBhbmQgZXh0ZXJu YWwgcmVsZWFzZXMgdG8gbGluaw0Kc3RhdGljYWxseS4gIFZhbGdyaW5kIGlzIHdvcmtpbmcg cGVyZmVjdGx5IHdpdGggc2hhcmVkIGxpYnN0ZGMrKy4gTWlnaHQgYmUgd29ydGgNCmFkZGlu ZyB0byBWYWxncmluZCBGQVE/DQoNClRoYW5rcyBhZ2FpbiEgUmVnYXJkcywNCkFsZXgNCg0K DQpKb3NlZiBXZWlkZW5kb3JmZXIgd3JvdGU6DQoNCj4gT24gVGh1cnNkYXkgMDUgSnVuZSAy MDAzIDAwOjUyLCBBbGV4IEl2ZXJzaGVuIHdyb3RlOg0KPiA+IDwhZG9jdHlwZSBodG1sIHB1 YmxpYyAiLS8vdzNjLy9kdGQgaHRtbCA0LjAgdHJhbnNpdGlvbmFsLy9lbiI+DQo+ID4gPGh0 bWw+DQo+ID4gR2VudGxlbWVuLA0KPiA+IDxwPkkgYW0gc3RpbGwgaGF2aW5nIGlzc3VlcyB3 aXRoIF9fYnVpbHRpbl9uZXcgbm90IGJlaW5nIGludGVyY2VwdGVkIGJ5DQo+ID4gVmFsZ3Jp bmQuJm5ic3A7IEplcmVteSBGaXR6aGFyZGluZ2UgZ2F2ZSBtZSBzb21lIHN1Z2dlc3Rpb25z LCBidXQgaXQgZGlkDQo+ID4gbm90IHNvbHZlIHRoZSBpc3N1ZS4gSGVyZSBpcyB0aGUgcHJv YmxlbTogd2hlbiBJIGFtIGNvbXBsaW5nIGNlcnRhaW4NCj4gPiBjbGFzc2VzLCB0aGUgY29t cGlsZXIgZ2VuZXJhdGVzIHJlZmVyZW5jZXMgdG8gX19idWlsdGluX25ldyAodmVjX25ldywN Cj4gPiBkZWxldGUsIHZlY19kZWxldGUpIGluIHRoZSBvYmplY3QgZmlsZS4mbmJzcDsgV2hl biB0aGlzIG9iamVjdCBmaWxlIGlzDQo+ID4gbGlua2VkIGludG8gZXhlY3V0YWJsZSwgdGhl IGNvbXBpbGVyIHJlc29sdmVzIHRoZSBfX2J1aWx0aW4qIHJlZmVyZW5jZXMNCj4gPiBmcm9t IGxpYmdjYy5hLCB3aGVyZSB0aGV5IGFyZSBkZWZpbmVkIGFzICJXIiBzeW1ib2xzLg0KPiA+ IDxwPkFzIGEgcmVzdWx0LCZuYnNwOyBWYWxncmluZCBkb2VzIE5PVCBpbnRlcmNlcHQgdGhv c2UgX19idWlsdGluKg0KPiA+IGZ1bmN0aW9ucywgYW5kIG9ubHkgY2F0Y2hlcyBtYWxsb2Mo KSBhbmQgZnJlZSgpIGNhbGxzIHdoZW4gdGhlc2UgY2xhc3Nlcw0KPiA+IGFyZSB1c2VkLiBB cyB5b3UgY2FuIGltYWdpbmUsIGEgc3dhcm0gb2YgbXVzbWF0Y2hlZCBmcmVlL2RlbGV0ZS9k ZWxldGVbXSBpcw0KPg0KPiBZb3VyIG9iamVjdCBmaWxlcyBzZWVtIHRvIGJlIGZpbmUuDQo+ IFRoZSBwcm9ibGVtIGlzLCB0aGF0IHRoZSBzdGF0aWMgbGluayBwcm9jZXNzIHNob3VsZG4n dCByZXNvbHZlIF9fYnVpbHRpbl9uZXcsDQo+IGkuZS4gdGhlIGxpYmdjYy5hIHlvdSBtZW50 aW9uIHNlZW1zIHRvIGJlIHdyb25nLCBpZiBpdCByZWFsbHkgZGVmaW5lcw0KPiBfX2J1aWx0 aW5fbmV3IHN0YXRpY2FsbHkuIFBlcmhhcHMgdGhpcyBmaWxlIHNob3VsZG4ndCBiZSBsaW5r ZWQgaW4gb3IgaXMgZnJvbQ0KPiBhIHdyb25nIGNvbXBpbGVyIHZlcnNpb24/IE9yIHlvdSBk byBzb21lIHBhcnRpYWwgc3RhdGljIGxpbmtpbmcuIFdoYXQncyB5b3VyDQo+IGxpbmsgY29t bWFuZCBsaW5lPw0KPg0KPiBJIGp1c3QgY2hlY2tlZCB3aXRoIG15IG93biBpbnN0YWxsYXRp b24gb2YgR0NDIDIuOTUuMyAoU3VzZTguMSkuDQo+IElmIEkgY29tcGlsZSB5b3VyIENsYXNz ZXMyLjk1LjMubyB3aXRoIGEgZHVtbXkgbWFpbigpLCBpdCBsaW5rcyBmaW5lLCBhbmQgaW4N Cj4gdGhlIHJlc3VsdGluZyBleGVjdXRhYmxlLCB0aGVyZSAqaXMqIHRoZSBzeW1ib2wgX19i dWlsdGluX25ldywgc28gdGhlcmUgd2lsbA0KPiBiZSBubyBwcm9ibGVtIHdpdGggdmFsZ3Jp bmQgPyE/DQo+IFVzdWFsbHksICJfX2J1aWx0aW5fbmV3IiBpcyBkZWZpbmVkIGluICJsaWJz dGRjKystbGliYzYuMi0yLnNvLjMiIGFuZCB3aWxsIGJlDQo+IGxpbmtlZCBpbiBieSB0aGUg cnVudGltZSBsaWJyYXJ5Lg0KPg0KPiBKb3NlZg0KDQotLQ0KQWxleCBHLiBJdmVyc2hlbiAg ICAgICAgICAgICAgICAgICAgICAgICAgICBJbmV0IFRlY2hub2xvZ2llcywgSW5jLg0KTmV0 d29yayBQcm9kdWN0cyBEZXB0LiAgICAgICAgICAgICAgICAgICAgICAxNTAwIE4uIEdyZWVu dmlsbGUgQXZlLg0KSW5ldCBUZWNobm9sb2dpZXMgSW5jLiAgICAgICAgICAgICAgICAgICAg ICBSaWNoYXJkc29uLCBUWCA3NTA4MQ0KUGhvbmU6ICsxLTQ2OS0zMzAtNDI5NSAgICAgICAg ICAgICAgICAgICAgICBVU0ENCg== |