gvdb test: avoid infinite recursion

/gvdb/reader/corrupted/7% was failing when run with random seed
R02S2a7b9704dbb5ea704b0d724329af0fbf.

This is a fuzz test, and it turns out that this particular seed ended up
producing a file that was valid, but contained a self-referential table.

The testcase happily recursed though this table's subtable (itself) and
so on, until it ran out of stack space, causing a crash.

This bug would not impact realworld users of gvdb: these users only ever
recurse through tables a finite number of times.  For dconf, subtables
are not used at all.  For GSettings, each schema is a subtable, but from
within that subtable we only lookup values.

0 files changed, 0 insertions, 0 deletions