When using a HashTable, a nice and convenient way to get to all its values is by using its get_values() function. This function returns a List. The documentation for this function call specifies:

===
The content of the list is owned by the hash table and should not be modified or freed. Use g_list_free() when done using the list.
===

However, when the list goes out of scope in Vala, it tries to free the contents of the list as well. This causes the data in the HashTable to be corrupt. Example code demonstrating the problem:

int main(string[] args)
{
	HashTable<string, string> table = new HashTable<string, string>(str_hash, str_equal);
	table.insert("abc", "def");
	table.insert("ghi", "jkl");
	table.insert("mno", "pqr");
	
	{
		List<string> list = table.get_values();
	}
	
	stdout.printf("%s\n", table.lookup("ghi"));
	
	return 0;
}

If you comment out the scope in which the get_values() call is made, the output is as you would expect:

$ ./hash_list 
jkl
$ 

However, if you leave it in, this is the output I get from a couple of sample runs:

$ ./hash_list 
�_p	
$ ./hash_list 
�?�
$ ./hash_list 
�
$ ./hash_list 
ȯO
$ ./hash_list 
ȿ�	
$ 

In my larger application, where I discovered this bug, more sinister things happen, resulting in segmentation faults or glibc corruption errors. I haven't tested, but I'm pretty certain a similar problem would occur with the get_keys() call.

You should have a way of telling your compiler to free the list but not its contents, I assume a [CCode] attribute on the get_values() specification could help with this, although not knowing how the vala compiler works, that's just a guess.