From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28001 invoked by alias); 25 Jul 2007 11:30:46 -0000 Received: (qmail 27960 invoked by uid 22791); 25 Jul 2007 11:30:34 -0000 X-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00,DK_POLICY_SIGNSOME,FORGED_RCVD_HELO X-Spam-Check-By: sourceware.org Received: from wildebeest.demon.nl (HELO gnu.wildebeest.org) (83.160.170.119) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 25 Jul 2007 11:30:30 +0000 Received: from dijkstra.wildebeest.org ([192.168.1.29]) by gnu.wildebeest.org with esmtp (Exim 4.43) id 1IDf71-0005Cz-9A for frysk@sourceware.org; Wed, 25 Jul 2007 13:33:05 +0200 Subject: [patch] Stat vs slurp vs linux 2.6.22 From: Mark Wielaard To: frysk@sourceware.org Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-UlXB5vg4/Yet1nDXo3Ku" Date: Wed, 25 Jul 2007 11:30:00 -0000 Message-Id: <1185363024.3597.16.camel@dijkstra.wildebeest.org> Mime-Version: 1.0 X-Mailer: Evolution 2.8.3 (2.8.3-2.fc6) X-Spam-Score: -4.3 (----) X-Virus-Checked: Checked by ClamAV on sourceware.org X-IsSubscribed: yes Mailing-List: contact frysk-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: frysk-owner@sourceware.org X-SW-Source: 2007-q3/txt/msg00170.txt.bz2 --=-UlXB5vg4/Yet1nDXo3Ku Content-Type: multipart/mixed; boundary="=-uqgEVd5uireQ9bEqObSc" --=-uqgEVd5uireQ9bEqObSc Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Content-length: 1690 Hi, On newer kernels (2.6.22) not just init (process id 1) can have a zero parent pid, but other kernel processes/threads also have a parent pid of zero (in particular kthreadd). This was done for systems with thousands of CPUs which create ten-thousand (kernel) processes and having them all children of init was not scaling (and not really necessary for the kernel-threads, which don't need to be reaped by init in the first place). This exposed a bug in our Stat parsing through LinuxHost. See http://sourceware.org/bugzilla/show_bug.cgi?id=3D4838 Stat uses slurp which was written to handle these kind of issues where /proc//stat might not exist or disappear in between calls. But it relied on the slurp() functions returning a failure value (NULL or -1). A recent rewrite of slurp to use Errno.tryOpen() which throws an Exception on error, broke Stat handling in such cases. Besides that slurp() had a bug in that it could free() a given buffer that it hadn't created itself (Stat was the owner of that buffer), this could lead to strange memory corruption. Both issues were fixed by: 2007-07-25 Mark Wielaard Fixes bug #4838 * cni/slurp.cxx (uslurp): Catch Errno after tryOpen(). (slurp): Likewise and don't free given buffer and return -1. (slurp_thread): Likewise. Tested on x86_64 (Fedora Core 6) and x86 (Fedora 7 - with new 2.6.22 kernel). The failing tests reported in the bug report PASS with this test on the new kernel. And introduces no new FAILs. It might make sense to rewrite slurp as a normal java class so these cross C/Java error handling issues. Is there a reason for slurp to have to be written in C/CNI? Cheers, Mark --=-uqgEVd5uireQ9bEqObSc Content-Disposition: inline; filename=slurp.patch Content-Type: text/x-patch; name=slurp.patch; charset=UTF-8 Content-Transfer-Encoding: base64 Content-length: 2603 SW5kZXg6IGZyeXNrLXN5cy9mcnlzay9zeXMvcHJvYy9jbmkvc2x1cnAuY3h4 DQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09DQpSQ1MgZmlsZTogL2N2cy9mcnlz ay9mcnlzay1zeXMvZnJ5c2svc3lzL3Byb2MvY25pL3NsdXJwLmN4eCx2DQpy ZXRyaWV2aW5nIHJldmlzaW9uIDEuMTANCmRpZmYgLXUgLXIxLjEwIHNsdXJw LmN4eA0KLS0tIGZyeXNrLXN5cy9mcnlzay9zeXMvcHJvYy9jbmkvc2x1cnAu Y3h4CTE4IEp1bCAyMDA3IDE4OjIzOjUyIC0wMDAwCTEuMTANCisrKyBmcnlz ay1zeXMvZnJ5c2svc3lzL3Byb2MvY25pL3NsdXJwLmN4eAkyNSBKdWwgMjAw NyAxMDo1Mzo0NyAtMDAwMA0KQEAgLTEsNiArMSw2IEBADQogLy8gVGhpcyBm aWxlIGlzIHBhcnQgb2YgdGhlIHByb2dyYW0gRlJZU0suDQogLy8NCi0vLyBD b3B5cmlnaHQgMjAwNSwgUmVkIEhhdCBJbmMuDQorLy8gQ29weXJpZ2h0IDIw MDUsIDIwMDcgUmVkIEhhdCBJbmMuDQogLy8NCiAvLyBGUllTSyBpcyBmcmVl IHNvZnR3YXJlOyB5b3UgY2FuIHJlZGlzdHJpYnV0ZSBpdCBhbmQvb3IgbW9k aWZ5IGl0DQogLy8gdW5kZXIgdGhlIHRlcm1zIG9mIHRoZSBHTlUgR2VuZXJh bCBQdWJsaWMgTGljZW5zZSBhcyBwdWJsaXNoZWQgYnkNCkBAIC00Nyw2ICs0 Nyw3IEBADQogDQogI2luY2x1ZGUgPGdjai9jbmkuaD4NCiANCisjaW5jbHVk ZSAiZnJ5c2svc3lzL0Vycm5vLmgiDQogI2luY2x1ZGUgImZyeXNrL3N5cy9j bmkvRXJybm8uaHh4Ig0KICNpbmNsdWRlICJmcnlzay9zeXMvcHJvYy9jbmkv c2x1cnAuaHh4Ig0KIA0KQEAgLTczLDcgKzc0LDE1IEBADQogICB9DQogDQog ICAvLyBPcGVuIHRoZSBmaWxlIGZpbGUuDQotICBpbnQgZmQgPSB0cnlPcGVu IChmaWxlLCBPX1JET05MWSwgMCk7DQorICBpbnQgZmQ7DQorICB0cnkNCisg ICAgew0KKyAgICAgIGZkID0gdHJ5T3BlbiAoZmlsZSwgT19SRE9OTFksIDAp Ow0KKyAgICB9DQorICBjYXRjaCAoZnJ5c2s6OnN5czo6RXJybm8gKmlnbm9y ZWQpDQorICAgIHsNCisgICAgICBmZCA9IDA7DQorICAgIH0NCiAgIGlmICgh ZmQpDQogICAgIHsNCiAgICAgICA6OmZyZWUgKGJ1Zik7DQpAQCAtMTI3LDEy ICsxMzYsMTggQEANCiAgICAgdGhyb3dSdW50aW1lRXhjZXB0aW9uICgic25w cmludGY6IGJ1ZmZlciBvdmVyZmxvdyIpOw0KICAgDQogICAvLyBPcGVuIHRo ZSBmaWxlIGZpbGUuDQotICBpbnQgZmQgPSB0cnlPcGVuIChmaWxlLCBPX1JE T05MWSwgMCk7DQotDQorICBpbnQgZmQ7DQorICB0cnkNCisgICAgew0KKyAg ICAgIGZkID0gdHJ5T3BlbiAoZmlsZSwgT19SRE9OTFksIDApOw0KKyAgICB9 DQorICBjYXRjaCAoZnJ5c2s6OnN5czo6RXJybm8gKmlnbm9yZWQpDQorICAg IHsNCisgICAgICBmZCA9IDA7DQorICAgIH0NCiAgIGlmICghZmQpDQogICAg IHsNCi0gICAgICA6OmZyZWUgKGJ1Zik7DQotICAgICAgcmV0dXJuIDA7DQor ICAgICAgcmV0dXJuIC0xOw0KICAgICB9DQogDQogDQpAQCAtMTY1LDEyICsx ODAsMTggQEANCiAgICAgdGhyb3dSdW50aW1lRXhjZXB0aW9uICgic25wcmlu dGY6IGJ1ZmZlciBvdmVyZmxvdyIpOw0KICAgDQogICAvLyBPcGVuIHRoZSBm aWxlIGZpbGUuDQotICBpbnQgZmQgPSB0cnlPcGVuIChmaWxlLCBPX1JET05M WSwgMCk7DQotDQorICBpbnQgZmQ7DQorICB0cnkNCisgICAgew0KKyAgICAg IGZkID0gdHJ5T3BlbiAoZmlsZSwgT19SRE9OTFksIDApOw0KKyAgICB9DQor ICBjYXRjaCAoZnJ5c2s6OnN5czo6RXJybm8gKmlnbm9yZWQpDQorICAgIHsN CisgICAgICBmZCA9IDA7DQorICAgIH0NCiAgIGlmICghZmQpDQogICAgIHsN Ci0gICAgICA6OmZyZWUgKGJ1Zik7DQotICAgICAgcmV0dXJuIDA7DQorICAg ICAgcmV0dXJuIC0xOw0KICAgICB9DQogDQogDQo= --=-uqgEVd5uireQ9bEqObSc-- --=-UlXB5vg4/Yet1nDXo3Ku Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part Content-length: 189 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQBGpzRIxVhZCJWr9QwRAlfOAJ0RMCrKBd/mSeZowZwHVQ2330ULAgCgi4nq VUC5CQNrMt1T6JPaYxQ7XHY= =uUcy -----END PGP SIGNATURE----- --=-UlXB5vg4/Yet1nDXo3Ku--