Note the following comment elsewhere in Modules/readline.c:
/* the history docs don't say so, but the address of state
changes each time history_get_history_state is called
which makes me think it's freshly malloc'd memory...
on the other hand, the address of the last line stays the
same as long as history isn't extended, so it appears to
be malloc'd but managed by the history package... */
free(state);
It is indeed not documented that state is malloced, but the implementation of history_get_history_state () is as follows:
/* Return the current HISTORY_STATE of the history. */
HISTORY_STATE *
history_get_history_state ()
{
HISTORY_STATE *state;
state = (HISTORY_STATE *)xmalloc (sizeof (HISTORY_STATE));
state->entries = the_history;
state->offset = history_offset;
state->length = history_length;
state->size = history_size;
state->flags = 0;
if (history_stifled)
state->flags |= HS_STIFLED;
return (state);
}
xmalloc () is an error checking wrapper around malloc, so free () can be used to deallocate the memory.
On the other hand it seems wasteful to request full state in a function that only needs history_length which is directly exported by the readline library. I am attaching a patch that reads history_length directly.

Not directly related to the issue at hand, but I've noticed that while readline.get_current_history_length() is tested in the unittests, readline.get_history_length() is not. Attached patch adds tests for reading and writing history files.
Also, I find it confusing that readline module static variable _history_length is named almost the same as readline library exported variable history_length. Maybe _history_length could be renamed to max_history_file_length.

It appears that the tests that I attached fail when libedit is used. This is clearly due to bugs in libedits readline emulation:
1. read_history does not update history_length
2. history_truncate_file does not preserver the history cookie ("_HiStOrY_V2_").
Does anyone know where libedit bugs should be reported?

I my experience, reporting bugs in open source components of OSX to bugreport.apple.com is a waste of time. Such reports are largely ignored and they are not visible to upstream developers.
I believe the upstream for libedit is NetBSD, http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libedit, but I cannot find their bug tracker.

Without filing a bug Apple won't know that something is wrong and they will definitly not fix the issue. If you file an issue and post the radar number I'll ping the Python maintainer inside Apple. There's little change that this will be fixed, but you never know.

I've fixed this leak in r83670 through r83672. It's still using the old, inefficient method (get the state, read the length, free the state), because without good tests I don't want to disturb things too much. In particular, it's not clear whether libedit keeps the history_length variable properly updated.
There are still the remaining issues of:
- better testing for the readline module, and
- attempting to work around libedit bugs.
Perhaps those should become separate issues, though?

As a note for future reference, FreeBSD/NetBSD/OpenBSD doesn't use the term "bug", but instead uses the term "problem report" (the NetBSD website says "bug" though BTW).
The PR system for NetBSD can be accessed here: http://www.netbsd.org/cgi-bin/sendpr.cgi?gndb=netbsd .

The leak had been fixed in #9450.
"There are still the remaining issues of:
- better testing for the readline module, and
- attempting to work around libedit bugs.
Perhaps those should become separate issues, though?"
If those are current issues and anyone cares enough, yes, separate issues.