I have this in my ~/.gdbinit: set history size unlimited but I generally always use emacs so I've never noticed this. It doesn't work because while set_history_size_command knows how to map "unlimited" (== UINT_MAX) to DTRT, init_history does not, which passes UINT_MAX to stifle_history, which takes an int, and boom.
Just for the record, it's not a recent bug. Problem is present in gdb on debian jessie (gdb v7.7.1) for instance.
dup of 16999 *** This bug has been marked as a duplicate of bug 16999 ***
The master branch has been updated by Patrick Palka <ppalka@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=ebfd00d210ca6190239140b250499e194fd5af20 commit ebfd00d210ca6190239140b250499e194fd5af20 Author: Patrick Palka <patrick@parcs.ath.cx> Date: Sun Apr 26 14:13:59 2015 -0400 Fix PR gdb/17820 This patch is a comprehensive fix for PR 17820 which reports that using "set history size unlimited" inside one's gdbinit file doesn't really work. There are three small changes in this patch. The most important change this patch makes is to decode the argument of the "size" subcommand using add_setshow_zuinteger_unlimited_cmd() instead of using add_setshow_uinteger_cmd(). The new decoder takes an int * and maps unlimited to -1 whereas the old decoder takes an unsigned int * and maps unlimited to UINT_MAX. Using the new decoder simplifies our handling of unlimited and makes it easier to interface with readline which itself expects a signed-int history size. The second change is the factoring of the [stifle|unstifle]_history logic into a common function which is now used by both init_history() and set_history_size_command(). This is technically the change that fixes the PR itself. Thirdly, this patch initializes history_size_setshow_var to -2 to mean that the variable has not been set yet. Now init_history() tests for -2 instead of 0 to determine whether to give the variable a default value. This means that having "set history size 0" in one's gdbinit file will actually keep the history size at 0 and not reset it to 256. gdb/ChangeLog: PR gdb/17820 * top.c (history_size_setshow_var): Change type to signed. Initialize to -2. Update documentation. (set_readline_history_size): Define. (set_history_size_command): Use it. Remove logic for handling out-of-range sizes. (init_history): Use set_readline_history_size(). Test for a value of -2 instead of 0 when determining whether to set a default history size. (init_main): Decode the argument of the "size" command as a zuinteger_unlimited. gdb/testsuite/ChangeLog: PR gdb/17820 * gdb.base/gdbinit-history.exp: New test. * gdb.base/gdbinit-history/unlimited/.gdbinit: New file. * gdb.base/gdbinit-history/zero/.gdbinit: New file.
The master branch has been updated by Patrick Palka <ppalka@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=2093d2d31460dc351145c4c295ea4a101e0c5aed commit 2093d2d31460dc351145c4c295ea4a101e0c5aed Author: Patrick Palka <patrick@parcs.ath.cx> Date: Thu Jun 4 10:12:27 2015 -0400 Don't truncate the history file when history size is unlimited We still do not handle "set history size unlimited" correctly. In particular, after writing to the history file, we truncate the history even if it is unlimited. This patch makes sure that we do not call history_truncate_file() if the history is not stifled (i.e. if it's unlimited). This bug causes the history file to be truncated to zero on exit when one has "set history size unlimited" in their gdbinit file. Although this code exists in GDB 7.8, the bug is masked by a pre-existing bug that's been only fixed in GDB 7.9 (PR gdb/17820). gdb/ChangeLog: * top.c (gdb_safe_append_history): Do not call history_truncate_file if the history is not stifled. gdb/testsuite/ChangeLog: * gdb.base/gdbinit-history.exp: Add test case to check that an unlimited history file does not get truncated on exit.