0

First, I insert key=str1,value=header_buff

Second, I use str2 to lookup the pointer

Third, I free the pointer which I malloc'd, but failed. Why?

#include <stdio.h>
#include <glib.h>
int main()
{
  GHashTable *hash; ///define my hashtable

  char str1[20] = "key";
  char str2[20] = "key";

  char *header_buff = (char*) malloc(sizeof(char) * 1024 * 1024);
  memcpy(header_buff, "value", 5);
  printf("%p\n", header_buff);

  hash = g_hash_table_new(g_str_hash, g_direct_hash); ///here I use (g_str_hash, g_direct_hash)
  g_hash_table_insert(hash, str1, header_buff); /// insert the str1 as key

  char * c = (char*) g_hash_table_lookup(hash, str2); ///use str2 to find the value
  if (c)
  {
    printf("%s\n", c);   ///can print the string "value"
    printf("%p\n", c);
    free(c); ///the same address? but I can't free the mem!
    c = NULL;
  }
  return 0;
}
Jonathan Leffler
  • 730,956
  • 141
  • 904
  • 1,278
user2692550
  • 1
  • 1
  • 4
    Add `#include ` to your include file list, and **remove the cast from the `malloc()` return value**. [See this question for why](http://stackoverflow.com/questions/605845/do-i-cast-the-result-of-malloc/605858#605858). – WhozCraig Aug 17 '13 at 19:05
  • 2
    The [reference for `g_hash_table_lookup`](https://developer.gnome.org/glib/2.36/glib-Hash-Tables.html#g-hash-table-lookup) doesn't say anything about needing to free the pointer returned. Instead you should free the pointer you actually allocate. – Some programmer dude Aug 17 '13 at 19:05
  • 1
    Also, shouldn't cast the returns from `malloc` or `g_hash_table_lookup`. – Some programmer dude Aug 17 '13 at 19:05
  • 2
    Another also, when you "can't free the mem", what do you mean by that? What happens when you do? Does your program crash? Maybe GLIB take "ownership" of the pointer? – Some programmer dude Aug 17 '13 at 19:08
  • 1
    You still won't receive any result from `g_hash_table_lookup()` if using `g_direct_hash` and two differnt pointers to insert and lookup. – alk Aug 17 '13 at 19:17
  • 1
    Personally, I think it's worth writing complete, correct sentences. But for others, the code may be enough... @user2692550: You can edit the post to improve e.g. the grammar or to add missing details. – oberlies Aug 17 '13 at 19:24
  • @WhozCraig, your comment has absolutely nothing to do with the problem. – JackCColeman Aug 17 '13 at 20:08
  • @JackCColeman It would seem some disagree with you. But the answer-blocks are just below these comments, and I'm sure the OP would benefit from your insight, so by all means. – WhozCraig Aug 17 '13 at 20:18
  • @WhozCraig, my comment is addressed to yourself. – JackCColeman Aug 17 '13 at 20:44

2 Answers2

3

From the documentation:

GHashTable *        g_hash_table_new  (GHashFunc hash_func,
                                       GEqualFunc key_equal_func);

So, you are using two hash functions instead of one hash and one equal function, which in turn will not work.

This is how it should look.

table = g_hash_table_new (g_str_hash,g_str_equal);

Be aware that g_direct_* might not work if you do not use the same instance of string though containing the same characters. It would directly compare the gchar pointers!

drahnr
  • 6,782
  • 5
  • 48
  • 75
  • +1 for pointing out the difference between the hasher and the comparator requirements of the api. I'm not familiar with the google api, but your logic seems sound. The note about direct-comparators is very helpful as well. – WhozCraig Aug 17 '13 at 20:48
-1

A wild guess is you're missing #include and sizeof(int) != sizeof(void *) on your platform.

Joshua
  • 40,822
  • 8
  • 72
  • 132
  • Mind explaining, I do not see a reason why this should be related to a key failing to lookup its associated value (if `sizeof (int)` > `sizeof (void)` will result in `0` padding on the left, the second case would result in formal information reduction which would happen on `insert` as well as on `lookup`, thus does not yield an issue (the bucket distribution compared to using a full length key might change, but to no effect for the API enduser). – drahnr Aug 18 '13 at 05:45