Date: Sat, 20 Apr 2013 18:32:08 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: Carl Shapiro <carl.shapiro@gmail.com> Cc: FreeBSD Hackers <freebsd-hackers@freebsd.org> Subject: Re: MADV_FREE and wait4 EFAULT Message-ID: <20130420153208.GD67273@kib.kiev.ua> In-Reply-To: <CANVK_Qjsa8-%2BtELi--Z6QttxhbkzxTQ1_aGyz=BGcYh3ng2qfw@mail.gmail.com> References: <CANVK_QgKRkpzWjA=H2u2HTp_vpxFhNLBGTVuFZmMEpBLTbzeaA@mail.gmail.com> <20130417082143.GW2930@kib.kiev.ua> <CANVK_QgRBO5ZU=NHCr1XTvtxYpWk6LjWEv8Q-70mY6CzqHO2TA@mail.gmail.com> <20130419124942.GA67273@kib.kiev.ua> <CANVK_Qjsa8-%2BtELi--Z6QttxhbkzxTQ1_aGyz=BGcYh3ng2qfw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--pZs/OQEoSSbxGlYw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Apr 19, 2013 at 11:53:22AM -0700, Carl Shapiro wrote: > On Fri, Apr 19, 2013 at 5:49 AM, Konstantin Belousov <kostikbel@gmail.com= >wrote: >=20 > > It would be of some interest to see the evidence. > > >=20 > Certainly. Here is some of the debugging messages that I added to my > application. The first line is a print statement that executes after the > system call returns. (As an aside, we issue system calls directly and do > not link against the C library.) The other 2 lines of interest are output > from the dump of /proc/curproc/map that correspond to the status and rusa= ge > addresses. >=20 > wait4 returned EFAULT, status is 0xc20021c0e8 rusage is 0xc2000eaf30 > ... > 0xc1ffff0000 0xc200100000 245 0 0xfffffe07cd9ebbc8 rw- 1 0 0x3000 COW NNC > default - CH 1001 > ... > 0xc200200000 0xc200300000 250 0 0xfffffe0215e3ed98 rw- 1 0 0x3000 COW NNC > default - CH 1001 >=20 > I realize this might not be satisfying but I am happy to provide any other > information you might be interested in. >=20 > Is your code multithreaded ? > > >=20 > Yes. Just observations/speculations: the addresses you shown are not the (usual) addresses for the malloc heap on amd64. It is possible to allocate and map enough shared libraries to make malloc start using these addresses, but more likely your app is using custom mmap() calls, possibly with the explicite address hints or MAP_FIXED. Am I right ? If yes and your app is multithreaded, it is possible that other thread performs some manipulations on the address space while current thread tries to access the range. >=20 > The test case is required to decide whether the bug is in the application > > or in the OS. > > >=20 > To be clear, I do not have a strong reason to believe there bug is in > FreeBSD. My original enquiry was solely into whether we were misusing > MADV_FREE pages. However, the wait4 failure is very suspicious because t= he > only two addresses written to are "out" parameters. In fact, the question is, why are you trying to access the memory after the MADV_FREE. Was it correctly marked as 'still used' to prevent mmaps there ? Note that all this is pure speculation. --pZs/OQEoSSbxGlYw Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRcrT3AAoJEJDCuSvBvK1B5noQAJXqtOP+Q7pavJEYcovI8dxp T9hwMEeu26AbMg1tC498o5lWFc4oO0evwbgTNje+f3Rn7DkRBClr1cDFmTi/Y594 Nzip21ywYCG9IYZJ/NI7txzQ7grFdSaaLh0NnC7a/7ctpXY2wKRO46DOAsEHxnkN RurnfgScIxwPXW7jWxAUapVZKmwxbThe3+v03it7GmVoMDqtSCtW+3d+RsyP9a3o QuY2XymUh2sqmpXsCNUP3qvu/RWfSQfhaTbyaMzyUOl9rGpPe4a20oSvxHbVkkgQ CtonV+A0j21nal1mx5gPiXPVwMQNBh2sb1QEeI4HJoQ/bdnfb9iq/WnoLDyfXYUg 6eD/9b3pp0vthoaIPgcb4fbDenRWNkjbRyrjYHrLl6fFM3X7TT0A2sLEPWogr6sO bXJHBNCP+Jd96dyHw0pJS396KPZIZ0zeo0lAIEzB2la8734q0kMXWf4Fb0/be80u OOmY7urPIo19FVHULFZhx8zPL5t5WcOiyHJCAYxk6vPs+QgOv3XcWdFjJzDm8X1T tSxDASPLLUohPWNzwItXg0+ri2kHs/hlfg2ejfOtNKsAb5xwyukf5IeyB51h5ryc u2Q0WJlJ/IlT+e0ZCjLdPnjXGACDU+HydhWnDXJvQV4uBApKErRw0qGewJaf/nFc u8aX6u6apcjQlHivYqDB =enUq -----END PGP SIGNATURE----- --pZs/OQEoSSbxGlYw--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130420153208.GD67273>