<feed xmlns='http://www.w3.org/2005/Atom'>
<title>src-test/lib/libproc, branch releng/9.2</title>
<subtitle>FreeBSD source tree</subtitle>
<id>https://cgit-dev.freebsd.org/src-test/atom?h=releng%2F9.2</id>
<link rel='self' href='https://cgit-dev.freebsd.org/src-test/atom?h=releng%2F9.2'/>
<link rel='alternate' type='text/html' href='https://cgit-dev.freebsd.org/src-test/'/>
<updated>2013-03-01T16:18:40Z</updated>
<entry>
<title>MFC 246035:</title>
<updated>2013-03-01T16:18:40Z</updated>
<author>
<name>John Baldwin</name>
<email>jhb@FreeBSD.org</email>
</author>
<published>2013-03-01T16:18:40Z</published>
<link rel='alternate' type='text/html' href='https://cgit-dev.freebsd.org/src-test/commit/?id=96a6ad20641dadd71156250b267ef40f5a897585'/>
<id>urn:sha1:96a6ad20641dadd71156250b267ef40f5a897585</id>
<content type='text'>
- Compute the correct size to reallocate when doubling the size of the
  array of loaded objects to avoid a buffer overrun.
- Use reallocf() to avoid leaking memory if the realloc() fails.

PR:		kern/175648
</content>
</entry>
<entry>
<title>fix a serious bug in libproc's proc_attach</title>
<updated>2011-08-03T09:55:59Z</updated>
<author>
<name>Andriy Gapon</name>
<email>avg@FreeBSD.org</email>
</author>
<published>2011-08-03T09:55:59Z</published>
<link rel='alternate' type='text/html' href='https://cgit-dev.freebsd.org/src-test/commit/?id=a8375da0d32591f81e799a2bcebebc4ba918ed12'/>
<id>urn:sha1:a8375da0d32591f81e799a2bcebebc4ba918ed12</id>
<content type='text'>
proc_attach always frees any struct proc_handle data
that it allocates, but that is supposed to be done
only in error conditions.

PR:		bin/158431
Approved by:	re (kib)
MFC after:	1 week
</content>
</entry>
<entry>
<title>Fix a memory leak on the error condition</title>
<updated>2010-12-14T15:14:08Z</updated>
<author>
<name>Kevin Lo</name>
<email>kevlo@FreeBSD.org</email>
</author>
<published>2010-12-14T15:14:08Z</published>
<link rel='alternate' type='text/html' href='https://cgit-dev.freebsd.org/src-test/commit/?id=faeece5e246cd0daea41c5ce3069b344a24d91ee'/>
<id>urn:sha1:faeece5e246cd0daea41c5ce3069b344a24d91ee</id>
<content type='text'>
Reviewed by:	rpaulo
</content>
</entry>
<entry>
<title>Ignore EINTR when calling waitpid.</title>
<updated>2010-09-18T23:38:21Z</updated>
<author>
<name>Rui Paulo</name>
<email>rpaulo@FreeBSD.org</email>
</author>
<published>2010-09-18T23:38:21Z</published>
<link rel='alternate' type='text/html' href='https://cgit-dev.freebsd.org/src-test/commit/?id=320807de5eca4d3247586449cb4721b5c49f7d19'/>
<id>urn:sha1:320807de5eca4d3247586449cb4721b5c49f7d19</id>
<content type='text'>
</content>
</entry>
<entry>
<title>Several fixes for libproc:</title>
<updated>2010-08-11T17:33:26Z</updated>
<author>
<name>Rui Paulo</name>
<email>rpaulo@FreeBSD.org</email>
</author>
<published>2010-08-11T17:33:26Z</published>
<link rel='alternate' type='text/html' href='https://cgit-dev.freebsd.org/src-test/commit/?id=4c74b2455d9de9e7d7abf91d9d4304e53e50a987'/>
<id>urn:sha1:4c74b2455d9de9e7d7abf91d9d4304e53e50a987</id>
<content type='text'>
o return the correct status in proc_wstatus()
o proc_read takes a void *
o correctly allocate the objs structure array

Sponsored by:	The FreeBSD Foundation
</content>
</entry>
<entry>
<title>Revert SHLIB_MAJOR to 2.</title>
<updated>2010-07-31T17:14:54Z</updated>
<author>
<name>Rui Paulo</name>
<email>rpaulo@FreeBSD.org</email>
</author>
<published>2010-07-31T17:14:54Z</published>
<link rel='alternate' type='text/html' href='https://cgit-dev.freebsd.org/src-test/commit/?id=fe0c8f8973937fa88519a823a5c50d6edfaf136a'/>
<id>urn:sha1:fe0c8f8973937fa88519a823a5c50d6edfaf136a</id>
<content type='text'>
As discussed with kan@, since DTrace is the only consumer of libproc
right now, there's no need for a major shlib bump.
</content>
</entry>
<entry>
<title>Bump the shared library major version due to ABI conflicts.</title>
<updated>2010-07-31T16:11:11Z</updated>
<author>
<name>Rui Paulo</name>
<email>rpaulo@FreeBSD.org</email>
</author>
<published>2010-07-31T16:11:11Z</published>
<link rel='alternate' type='text/html' href='https://cgit-dev.freebsd.org/src-test/commit/?id=295790277a7a1fbb39075ff041873634caa730da'/>
<id>urn:sha1:295790277a7a1fbb39075ff041873634caa730da</id>
<content type='text'>
Sponsored by:	The FreeBSD Foundation
</content>
</entry>
<entry>
<title>New version of libproc. Changes are:</title>
<updated>2010-07-31T16:10:20Z</updated>
<author>
<name>Rui Paulo</name>
<email>rpaulo@FreeBSD.org</email>
</author>
<published>2010-07-31T16:10:20Z</published>
<link rel='alternate' type='text/html' href='https://cgit-dev.freebsd.org/src-test/commit/?id=8eb20f364fe0e4a0cbbbce6b8456a75324ae95d8'/>
<id>urn:sha1:8eb20f364fe0e4a0cbbbce6b8456a75324ae95d8</id>
<content type='text'>
* breakpoint setup support
* register query
* symbol to address mapping and vice-versa
* more misc utility functions based on their Solaris counterpart

Also, I've written some test cases.

Sponsored by:	The FreeBSD Foundation
</content>
</entry>
<entry>
<title>Removed redundant -I. from CFLAGS and "yes" from WITHOUT_MAN.</title>
<updated>2010-02-25T22:16:30Z</updated>
<author>
<name>Ruslan Ermilov</name>
<email>ru@FreeBSD.org</email>
</author>
<published>2010-02-25T22:16:30Z</published>
<link rel='alternate' type='text/html' href='https://cgit-dev.freebsd.org/src-test/commit/?id=13c89dbfa7bf13ab8ad113fc0345a6667e891a3c'/>
<id>urn:sha1:13c89dbfa7bf13ab8ad113fc0345a6667e891a3c</id>
<content type='text'>
</content>
</entry>
<entry>
<title>Build lib/ with WARNS=6 by default.</title>
<updated>2010-01-02T09:58:07Z</updated>
<author>
<name>Ed Schouten</name>
<email>ed@FreeBSD.org</email>
</author>
<published>2010-01-02T09:58:07Z</published>
<link rel='alternate' type='text/html' href='https://cgit-dev.freebsd.org/src-test/commit/?id=daaf5759104f210a9315f49f80f1e0f01a8b3bff'/>
<id>urn:sha1:daaf5759104f210a9315f49f80f1e0f01a8b3bff</id>
<content type='text'>
Similar to libexec/, do the same with lib/. Make WARNS=6 the norm and
lower it when needed.

I'm setting WARNS?=0 for secure/. It seems secure/ includes the
Makefile.inc provided by lib/. I'm not going to touch that directory.
Most of the code there is contributed anyway.
</content>
</entry>
</feed>
