If anyone can come up with an example of a bus where:
- both i/o and memory resources are addressable
- access to them can be controlled
- but they can't be controlled independently
then by all means, reinstate this logic.
instead of calling CFRunLoopRun() directly. The leak wasn't reproducible on
this machine, but someone was able to produce a leak trace with Instruments
that indicates it was leaking in the CFRunLoopRun() path.
x-input.m: dequeue and ignore events when pbproxy_active is false.
x-selection.h: add an is_active method that is used by x-input.m to ignore
events.
x-selection.m: Handle nearly every preference, except for primary_on_grab,
which I don't really understand yet.
(cherry picked from commit 4d51ad851e)
Remove some unnecesssary headers.
Remove some dead code that was never called or used in pbproxy.
Make use of an NSAutoreleasePool in x_init. It could potentially cause a leak
on a startup without this.
Start adding reload_preferences to the x_selection class, as well as event
handling for that.
(cherry picked from commit 602e8ba8f7)
Fix the usage of the NSString cStringUsingEncoding: - it doesn't NUL
terminate the string, which lead to a bus error. So, we use
lengthOfBytesUsingEncoding: to get the length in bytes instead of
strlen().
(cherry picked from commit 6333d619e7)
2 of the paths leaked, when INCR transfers were done. Now we
are leak free according to the leaks program for all transfers
I have tried so far.
(cherry picked from commit aa98db576b)
NSAutoreleasePool. Now the usage is consistent. In x_input_run()
we create a pool, and release it after processing the XEvents.
Add some getpid() output to main for debugging. It needs a bit more
testing before the next release.
Don't retain the NSPasteboard as the old code did. That may have
contributed to the leak, and it made it so that we needed the
NSAutoreleasePool created in main().
Remove the _known_types, and _pasteboard instance variables from
the x_selection class. They aren't needed anymore.
The leaks program now indicates 0 leaks after some usage. I want
to test further, but this seems much better, and my memory usage
graph indicates it's not growing.
(cherry picked from commit b245d84a72)
macro causes a leak (according to the leaks program).
Attempt to fix several other leaks with release method calls.
For some reason the process still grows more than it should...
I will need to use some better methods than leaks, and malloc_history
I suspect. Whatever is leaking, it's hard to find. I need to isolate
the cases more.
Add a missing image/jpeg branch.
Remove read_prop_32 - it's not used.
(cherry picked from commit 63a680354d)
According to the press release:
Previous SGI contributions to the free and open source community
are now available under the new license. These contributions
include the SGI® OpenGL® Sample Implementation, the GLX™ API and
other GLX extensions.
[...]
"SGI has been one of the most ardent commercial supporters of free
and open source software, so it was important to us that we continue
to support the free software development community by releasing our
earlier OpenGL-related contributions under this new license," said
Steve Neuner, director of Linux, SGI. "This license ensures that all
existing user communities will benefit, and their work can proceed
unimpeded. Both Mesa and the X.org Project can continue to utilize
this code in free software distributions of GNU/Linux. Now more than
ever, software previously released by SGI under earlier GLX and SGI
Free Software License B is free."
"The GLX API" is here read to include the original GLX source release
from:
http://www.sgi.com/products/software/opensource/glx/download.html
ftp://ftp.sgi.com/sgi/opengl/glx/glx1_2.1.tgz
which includes glxext.c as included in XFree86, from which our copies
in glx/ and hw/dmx/glxProxy/ are derived.
