You may indeed have a leak. I did not check your code that carefully. But i do wonder about your statement:
> > 1)As soon as I call LoadPatternDB() method in parser.go there is some > increase in memory consumption(some memory leak). Ideally that should not > have happened. > Go is a garbage collected language. So it is not uncommon for code to allocate memory even when it is not obvious why. Just because memory is allocated, or even seems to increase over time, does not mean there is a leak. In Go, you have a leak if the memory increases *unbounded *over time. You need to run your code for a long, long time, and see if the memory usage eventually stabilizes. If it does, then you do not have a leak. There are many discussions on this topic, but one from just a few days might be helpful: https://groups.google.com/d/topic/golang-nuts/QoKBlrrq3Ww/discussion Of course, you may have an actual leak. But "some increase in memory" is not enough to say that you do. On Monday, March 9, 2020 at 7:34:31 AM UTC-4, Nitish Saboo wrote: > > Hi > > Following are my Go code and C header file and C wrapper code > > parser.go > ========== > var f *os.File > > func LoadPatternDB(patterndb string) { > path := C.CString(patterndb) > defer C.free(unsafe.Pointer(path)) > C.load_pattern_db(path, (C.key_value_cb)(unsafe.Pointer(C.callOnMeGo_cgo))) > } > > //export ParsedData > func ParsedData(k *C.char, val *C.char, val_len C.size_t) { > f.WriteString(C.GoString(k)) > f.WriteString("\n") > } > > cfunc.go > ======== > /* > #include <stdio.h> > // The gateway function > void callOnMeGo_cgo(char *k, char *val, size_t val_len) > { > void ParsedData(const char *k, const char *val, size_t val_len); > ParsedData(k, val, val_len); > } > */ > import "C" > > node.h > ======= > > #ifndef TEST_H_INCLUDED > #define TEST_H_INCLUDED > > #include <stdlib.h> > > typedef void (*key_value_cb)(const char* k, const char* val, size_t > val_len); > int load_pattern_db(const char* file, key_value_cb cb); > > #endif > > node.c > --------- > int load_pattern_db(const gchar* file, key_value_cb cb) > { > patterndb = pattern_db_new(); > pattern_db_reload_ruleset(patterndb, configuration, file); > pattern_db_set_emit_func(patterndb, pdbtool_pdb_emit_accumulate, cb); > return 0; > } > > > I am calling '*LoadPatternDB*' method in my parser.go file that makes a > cgo call '*C.load_pattern_db'* where I am passing a callback function to > the C code. > The C code is a wrapper code that internally calls some syslog-ng library > apis' > > What I observed is: > > 1)As soon as I call LoadPatternDB() method in parser.go there is some > increase in memory consumption(some memory leak).Ideally that should not > have happened. > > 2)To verify if the C code had some issue, I called the C wrapper code > method '*load_pattern_db*' from my main.c in the following manner to > completely eliminate Go code here.What I found is there is no increase in > memory consumption after every call ('load_pattern_db' was called 5 > times).Hence there is no memory leak from C code.So the issue lies in the > Go code in '*LoadPatternDB*' method in parser.go > > main.c > ======= > > void check(char *key, char *value, size_t value_len) > { > printf("I am in function check\n"); > } > > int main(void){ > char* filename = "/home/nitish/default.xml"; > key_value_cb s = check; > int i; > for (i=1; i<=5; i++) > { > load_pattern_db(filename, s); > printf("Sleeping for 5 second.\n"); > sleep(5); > } > printf("Loading done 5 times.\n"); > return 0; > } > > 3)Can someone please guide me and help me figure out the mem-leak in > 'LoadPatternDB' method in parser.go at very first glance? Is the callback > function pointer an issue here ? > > 4)What tool can I use to check this mem-leak ? > > Thanks, > Nitish > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/9d360b1e-47ca-4e71-8547-80fad296f5ff%40googlegroups.com.
