[go-nuts] How to read http.Response from http.Request
hey all I am trying to read the Response from http.Request like so:
func (ctr *Controller) Login(c *common.CPContext, req *http.Request, res
http.ResponseWriter) (int, interface{}) { defer func() {
var code = req.Response.StatusCode; // invalid memory address
or nil pointer dereference if code < 400 {
user.LoginAttempts = 0
} else {
user.LoginAttempts = user.LoginAttempts + 1
}
_, err := user.Update(ctx, db, boil.Infer())
if err != nil {
log.Warningf("could not save/update user model: %v",
err)
} }()}
10:18
I am getting that error:
`invalid memory address or nil pointer dereference` -
does anyone know how to read the Response StatusCode from req.Response?
--
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/53d558ff-c802-4cf7-b5f0-61f83dcef61a%40googlegroups.com.
Re: [go-nuts] building C++ wrapper for mabain lib with go1.13
On Tue, Mar 17, 2020 at 2:05 PM Mohamed Mahmoud wrote:
>
> On Tuesday, March 17, 2020 at 5:01:43 PM UTC-4, Mohamed Mahmoud wrote:
>>
>> I don't see anything obviously wrong. Add -v to -ldflags to see
>>>
>>> exactly how the external linker is being invoked. Make sure that
>>> -lmabain appears at the right point in the link line.
>>>
>>> Ian
>>
>>
>> I added -v its not showing libmabain , I am not sure what exactly you mean
>> by having -lmabain at the right point , below is my command line let me know
>> what it should be ?
>
> Step 25/26 : RUN cd ${MABAIN_SRC}/; go install -x -i -ldflags '-w
> -extldflags "-lmabain" -v'
>
> ---> Running in fd8ed360602a
>
> WORK=/tmp/go-build682038651
>
> mkdir -p $WORK/b001/
>
> swig -version
>
> cd $WORK
>
> /usr/local/go/pkg/tool/linux_amd64/compile -o ./b001/_go_.o -trimpath
> "$WORK/b001=>" -p main -complete -goversion go1.13 -D _$WORK -c=4
> ./swig_intsize.go
>
> cd /mabain_src
>
> swig -go -cgo -intgosize 64 -module mabain -o $WORK/b001/mabain_wrap.cxx
> -outdir $WORK/b001/ -c++ mabain.swigcxx
>
> CGO_LDFLAGS='"-g" "-O2"' /usr/local/go/pkg/tool/linux_amd64/cgo -objdir
> $WORK/b001/ -importpath _/mabain_src -- -I $WORK/b001/ -g -O2
> $WORK/b001/_mabain_swig.go
>
> cd $WORK
>
> gcc -fno-caret-diagnostics -c -x c - -o /dev/null || true
>
> gcc -Qunused-arguments -c -x c - -o /dev/null || true
>
> gcc -fdebug-prefix-map=a=b -c -x c - -o /dev/null || true
>
> gcc -gno-record-gcc-switches -c -x c - -o /dev/null || true
>
> cd $WORK/b001
>
> TERM='dumb' gcc -I /mabain_src -fPIC -m64 -pthread -fmessage-length=0
> -fdebug-prefix-map=$WORK/b001=/tmp/go-build -gno-record-gcc-switches -I ./ -g
> -O2 -o ./_x001.o -c _cgo_export.c
>
> TERM='dumb' gcc -I /mabain_src -fPIC -m64 -pthread -fmessage-length=0
> -fdebug-prefix-map=$WORK/b001=/tmp/go-build -gno-record-gcc-switches -I ./ -g
> -O2 -o ./_x002.o -c _mabain_swig.cgo2.c
>
> cd $WORK
>
> g++ -fno-caret-diagnostics -c -x c - -o /dev/null || true
>
> g++ -Qunused-arguments -c -x c - -o /dev/null || true
>
> g++ -fdebug-prefix-map=a=b -c -x c - -o /dev/null || true
>
> g++ -gno-record-gcc-switches -c -x c - -o /dev/null || true
>
> cd /mabain_src
>
> TERM='dumb' g++ -I . -fPIC -m64 -pthread -fmessage-length=0
> -fdebug-prefix-map=$WORK/b001=/tmp/go-build -gno-record-gcc-switches -I
> $WORK/b001/ -g -O2 -o $WORK/b001/_x003.o -c mabain_c_interface.cpp
>
> cd $WORK/b001
>
> TERM='dumb' g++ -I /mabain_src -fPIC -m64 -pthread -fmessage-length=0
> -fdebug-prefix-map=$WORK/b001=/tmp/go-build -gno-record-gcc-switches -I ./ -g
> -O2 -o ./_x004.o -c mabain_wrap.cxx
>
> TERM='dumb' gcc -I /mabain_src -fPIC -m64 -pthread -fmessage-length=0
> -fdebug-prefix-map=$WORK/b001=/tmp/go-build -gno-record-gcc-switches -I ./ -g
> -O2 -o ./_cgo_main.o -c _cgo_main.c
>
> cd /mabain_src
>
> TERM='dumb' g++ -I . -fPIC -m64 -pthread -fmessage-length=0
> -fdebug-prefix-map=$WORK/b001=/tmp/go-build -gno-record-gcc-switches -o
> $WORK/b001/_cgo_.o $WORK/b001/_cgo_main.o $WORK/b001/_x001.o
> $WORK/b001/_x002.o $WORK/b001/_x003.o $WORK/b001/_x004.o -g -O2
>
> # _/mabain_src
>
> /tmp/go-build682038651/b001/_x003.o: In function `mbOpen':
>
> ./mabain_c_interface.cpp:10: undefined reference to
> `mabain::CONSTS::ReaderOptions()'
>
> ./mabain_c_interface.cpp:12: undefined reference to `mabain::DB::DB(char
> const*, int, unsigned long, unsigned long, unsigned int)'
>
> ./mabain_c_interface.cpp:13: undefined reference to `mabain::DB::is_open()
> const'
>
> ./mabain_c_interface.cpp:14: undefined reference to `mabain::DB::StatusStr()
> const'
>
> ./mabain_c_interface.cpp:11: undefined reference to
> `mabain::CONSTS::WriterOptions()'
>
> /tmp/go-build682038651/b001/_x003.o: In function `mbFind':
>
> ./mabain_c_interface.cpp:44: undefined reference to `mabain::MBData::MBData()'
>
> ./mabain_c_interface.cpp:45: undefined reference to `mabain::DB::Find(char
> const*, int, mabain::MBData&) const'
>
> ./mabain_c_interface.cpp:44: undefined reference to
> `mabain::MBData::~MBData()'
>
> ./mabain_c_interface.cpp:44: undefined reference to
> `mabain::MBData::~MBData()'
>
> /tmp/go-build682038651/b001/_x003.o: In function `mbClose':
>
> ./mabain_c_interface.cpp:23: undefined reference to `mabain::DB::Close()'
>
> /tmp/go-build682038651/b001/_x003.o: In function `mbAdd':
>
> ./mabain_c_interface.cpp:30: undefined reference to `mabain::DB::Add(char
> const*, int, char const*, int, bool)'
>
> /tmp/go-build682038651/b001/_x003.o: In function `mbRemove':
>
> ./mabain_c_interface.cpp:37: undefined reference to `mabain::DB::Remove(char
> const*, int)'
>
> collect2: error: ld returned 1 exit status
>
> The command '/bin/sh -c cd ${MABAIN_SRC}/; go install -x -i -ldflags '-w
> -extldflags "-lmabain" -v'' returned a non-zero code: 2
It doesn't look like the -ldflags option is getting through to the linker. Try
go build "-ldflags=all=-w -extldflags=-lmabain -v"
Ian
--
You received this message because you are subscribed to the Google Groups
Re: [go-nuts] building C++ wrapper for mabain lib with go1.13
On Tuesday, March 17, 2020 at 5:01:43 PM UTC-4, Mohamed Mahmoud wrote:
>
> I don't see anything obviously wrong. Add -v to -ldflags to see
>
>> exactly how the external linker is being invoked. Make sure that
>> -lmabain appears at the right point in the link line.
>>
>> Ian
>>
>
> I added -v its not showing libmabain , I am not sure what exactly you mean
> by having -lmabain at the right point , below is my command line let me
> know what it should be ?
>
Step 25/26 : RUN cd ${MABAIN_SRC}/; go install -x -i -ldflags '-w
-extldflags "-lmabain" -v'
---> Running in fd8ed360602a
WORK=/tmp/go-build682038651
mkdir -p $WORK/b001/
swig -version
cd $WORK
/usr/local/go/pkg/tool/linux_amd64/compile -o ./b001/_go_.o -trimpath
"$WORK/b001=>" -p main -complete -goversion go1.13 -D _$WORK -c=4
./swig_intsize.go
cd /mabain_src
swig -go -cgo -intgosize 64 -module mabain -o $WORK/b001/mabain_wrap.cxx
-outdir $WORK/b001/ -c++ mabain.swigcxx
CGO_LDFLAGS='"-g" "-O2"' /usr/local/go/pkg/tool/linux_amd64/cgo -objdir
$WORK/b001/ -importpath _/mabain_src -- -I $WORK/b001/ -g -O2
$WORK/b001/_mabain_swig.go
cd $WORK
gcc -fno-caret-diagnostics -c -x c - -o /dev/null || true
gcc -Qunused-arguments -c -x c - -o /dev/null || true
gcc -fdebug-prefix-map=a=b -c -x c - -o /dev/null || true
gcc -gno-record-gcc-switches -c -x c - -o /dev/null || true
cd $WORK/b001
TERM='dumb' gcc -I /mabain_src -fPIC -m64 -pthread -fmessage-length=0
-fdebug-prefix-map=$WORK/b001=/tmp/go-build -gno-record-gcc-switches -I ./
-g -O2 -o ./_x001.o -c _cgo_export.c
TERM='dumb' gcc -I /mabain_src -fPIC -m64 -pthread -fmessage-length=0
-fdebug-prefix-map=$WORK/b001=/tmp/go-build -gno-record-gcc-switches -I ./
-g -O2 -o ./_x002.o -c _mabain_swig.cgo2.c
cd $WORK
g++ -fno-caret-diagnostics -c -x c - -o /dev/null || true
g++ -Qunused-arguments -c -x c - -o /dev/null || true
g++ -fdebug-prefix-map=a=b -c -x c - -o /dev/null || true
g++ -gno-record-gcc-switches -c -x c - -o /dev/null || true
cd /mabain_src
TERM='dumb' g++ -I . -fPIC -m64 -pthread -fmessage-length=0
-fdebug-prefix-map=$WORK/b001=/tmp/go-build -gno-record-gcc-switches -I
$WORK/b001/ -g -O2 -o $WORK/b001/_x003.o -c mabain_c_interface.cpp
cd $WORK/b001
TERM='dumb' g++ -I /mabain_src -fPIC -m64 -pthread -fmessage-length=0
-fdebug-prefix-map=$WORK/b001=/tmp/go-build -gno-record-gcc-switches -I ./
-g -O2 -o ./_x004.o -c mabain_wrap.cxx
TERM='dumb' gcc -I /mabain_src -fPIC -m64 -pthread -fmessage-length=0
-fdebug-prefix-map=$WORK/b001=/tmp/go-build -gno-record-gcc-switches -I ./
-g -O2 -o ./_cgo_main.o -c _cgo_main.c
cd /mabain_src
TERM='dumb' g++ -I . -fPIC -m64 -pthread -fmessage-length=0
-fdebug-prefix-map=$WORK/b001=/tmp/go-build -gno-record-gcc-switches -o
$WORK/b001/_cgo_.o $WORK/b001/_cgo_main.o $WORK/b001/_x001.o
$WORK/b001/_x002.o $WORK/b001/_x003.o $WORK/b001/_x004.o -g -O2
# _/mabain_src
/tmp/go-build682038651/b001/_x003.o: In function `mbOpen':
./mabain_c_interface.cpp:10: undefined reference to
`mabain::CONSTS::ReaderOptions()'
./mabain_c_interface.cpp:12: undefined reference to `mabain::DB::DB(char
const*, int, unsigned long, unsigned long, unsigned int)'
./mabain_c_interface.cpp:13: undefined reference to `mabain::DB::is_open()
const'
./mabain_c_interface.cpp:14: undefined reference to
`mabain::DB::StatusStr() const'
./mabain_c_interface.cpp:11: undefined reference to
`mabain::CONSTS::WriterOptions()'
/tmp/go-build682038651/b001/_x003.o: In function `mbFind':
./mabain_c_interface.cpp:44: undefined reference to
`mabain::MBData::MBData()'
./mabain_c_interface.cpp:45: undefined reference to `mabain::DB::Find(char
const*, int, mabain::MBData&) const'
./mabain_c_interface.cpp:44: undefined reference to
`mabain::MBData::~MBData()'
./mabain_c_interface.cpp:44: undefined reference to
`mabain::MBData::~MBData()'
/tmp/go-build682038651/b001/_x003.o: In function `mbClose':
./mabain_c_interface.cpp:23: undefined reference to `mabain::DB::Close()'
/tmp/go-build682038651/b001/_x003.o: In function `mbAdd':
./mabain_c_interface.cpp:30: undefined reference to `mabain::DB::Add(char
const*, int, char const*, int, bool)'
/tmp/go-build682038651/b001/_x003.o: In function `mbRemove':
./mabain_c_interface.cpp:37: undefined reference to
`mabain::DB::Remove(char const*, int)'
collect2: error: ld returned 1 exit status
The command '/bin/sh -c cd ${MABAIN_SRC}/; go install -x -i -ldflags '-w
-extldflags "-lmabain" -v'' returned a non-zero code: 2
--
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/f6f24f25-a43b-4834-8dd2-45eec94bc902%40googlegroups.com.
Re: [go-nuts] building C++ wrapper for mabain lib with go1.13
I don't see anything obviously wrong. Add -v to -ldflags to see
> exactly how the external linker is being invoked. Make sure that
> -lmabain appears at the right point in the link line.
>
> Ian
>
I added -v its not showing libmabain , I am not sure what exactly you mean
by having -lmabain at the right point , below is my command line let me
know what it should be ?
Step 25/26 : RUN cd ${MABAIN_SRC}/; go install -x -i -ldflags '-w
-extldflags "-lmabain" -v'
---> Running in fd8ed360602a
WORK=/tmp/go-build682038651
mkdir -p $WORK/b001/
swig -version
cd $WORK
/usr/local/go/pkg/tool/linux_amd64/compile -o ./b001/_go_.o -trimpath
"$WORK/b001=>" -p main -complete -goversion go1.13 -D _$WORK -c=4
./swig_intsize.go
cd /mabain_src
swig -go -cgo -intgosize 64 -module mabain -o $WORK/b001/mabain_wrap.cxx
-outdir $WORK/b001/ -c++ mabain.swigcxx
CGO_LDFLAGS='"-g" "-O2"' /usr/local/go/pkg/tool/linux_amd64/cgo -objdir
$WORK/b001/ -importpath _/mabain_src -- -I $WORK/b001/ -g -O2
$WORK/b001/_mabain_swig.go
cd $WORK
gcc -fno-caret-diagnostics -c -x c - -o /dev/null || true
gcc -Qunused-arguments -c -x c - -o /dev/null || true
gcc -fdebug-prefix-map=a=b -c -x c - -o /dev/null || true
gcc -gno-record-gcc-switches -c -x c - -o /dev/null || true
cd $WORK/b001
TERM='dumb' gcc -I /mabain_src -fPIC -m64 -pthread -fmessage-length=0
-fdebug-prefix-map=$WORK/b001=/tmp/go-build -gno-record-gcc-switches -I ./
-g -O2 -o ./_x001.o -c _cgo_export.c
TERM='dumb' gcc -I /mabain_src -fPIC -m64 -pthread -fmessage-length=0
-fdebug-prefix-map=$WORK/b001=/tmp/go-build -gno-record-gcc-switches -I ./
-g -O2 -o ./_x002.o -c _mabain_swig.cgo2.c
cd $WORK
g++ -fno-caret-diagnostics -c -x c - -o /dev/null || true
g++ -Qunused-arguments -c -x c - -o /dev/null || true
g++ -fdebug-prefix-map=a=b -c -x c - -o /dev/null || true
g++ -gno-record-gcc-switches -c -x c - -o /dev/null || true
cd /mabain_src
TERM='dumb' g++ -I . -fPIC -m64 -pthread -fmessage-length=0
-fdebug-prefix-map=$WORK/b001=/tmp/go-build -gno-record-gcc-switches -I
$WORK/b001/ -g -O2 -o $WORK/b001/_x003.o -c mabain_c_interface.cpp
cd $WORK/b001
TERM='dumb' g++ -I /mabain_src -fPIC -m64 -pthread -fmessage-length=0
-fdebug-prefix-map=$WORK/b001=/tmp/go-build -gno-record-gcc-switches -I ./
-g -O2 -o ./_x004.o -c mabain_wrap.cxx
TERM='dumb' gcc -I /mabain_src -fPIC -m64 -pthread -fmessage-length=0
-fdebug-prefix-map=$WORK/b001=/tmp/go-build -gno-record-gcc-switches -I ./
-g -O2 -o ./_cgo_main.o -c _cgo_main.c
cd /mabain_src
TERM='dumb' g++ -I . -fPIC -m64 -pthread -fmessage-length=0
-fdebug-prefix-map=$WORK/b001=/tmp/go-build -gno-record-gcc-switches -o
$WORK/b001/_cgo_.o $WORK/b001/_cgo_main.o $WORK/b001/_x001.o
$WORK/b001/_x002.o $WORK/b001/_x003.o $WORK/b001/_x004.o -g -O2
# _/mabain_src
/tmp/go-build682038651/b001/_x003.o: In function `mbOpen':
./mabain_c_interface.cpp:10: undefined reference to
`mabain::CONSTS::ReaderOptions()'
./mabain_c_interface.cpp:12: undefined reference to `mabain::DB::DB(char
const*, int, unsigned long, unsigned long, unsigned int)'
./mabain_c_interface.cpp:13: undefined reference to `mabain::DB::is_open()
const'
./mabain_c_interface.cpp:14: undefined reference to
`mabain::DB::StatusStr() const'
./mabain_c_interface.cpp:11: undefined reference to
`mabain::CONSTS::WriterOptions()'
/tmp/go-build682038651/b001/_x003.o: In function `mbFind':
./mabain_c_interface.cpp:44: undefined reference to
`mabain::MBData::MBData()'
./mabain_c_interface.cpp:45: undefined reference to `mabain::DB::Find(char
const*, int, mabain::MBData&) const'
./mabain_c_interface.cpp:44: undefined reference to
`mabain::MBData::~MBData()'
./mabain_c_interface.cpp:44: undefined reference to
`mabain::MBData::~MBData()'
/tmp/go-build682038651/b001/_x003.o: In function `mbClose':
./mabain_c_interface.cpp:23: undefined reference to `mabain::DB::Close()'
/tmp/go-build682038651/b001/_x003.o: In function `mbAdd':
./mabain_c_interface.cpp:30: undefined reference to `mabain::DB::Add(char
const*, int, char const*, int, bool)'
/tmp/go-build682038651/b001/_x003.o: In function `mbRemove':
./mabain_c_interface.cpp:37: undefined reference to
`mabain::DB::Remove(char const*, int)'
collect2: error: ld returned 1 exit status
The command '/bin/sh -c cd ${MABAIN_SRC}/; go install -x -i -ldflags '-w
-extldflags "-lmabain" -v'' returned a non-zero code: 2
--
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/911b9b18-9f2c-4615-85e6-a89d04430a10%40googlegroups.com.
Re: [go-nuts] building C++ wrapper for mabain lib with go1.13
On Tue, Mar 17, 2020 at 9:04 AM wrote: > > I have created swigcxx file , since swig now is natively integrated in go > tools > I ran the following to build a test program that interact with the mabain > wrapper go package to test the APIs > > go install -x -i -ldflags '-w -extldflags "-lmabain"' > > > However I ran into linker errors that I am not able to resolve > > > # mabain > > /tmp/go-build378478658/b001/_x003.o: In function `mbOpen': > > ./mabain_c_interface.cpp:10: undefined reference to > `mabain::CONSTS::ReaderOptions()' > > ./mabain_c_interface.cpp:12: undefined reference to `mabain::DB::DB(char > const*, int, unsigned long, unsigned long, unsigned int)' > > ./mabain_c_interface.cpp:13: undefined reference to `mabain::DB::is_open() > const' > > ./mabain_c_interface.cpp:14: undefined reference to `mabain::DB::StatusStr() > const' > > ./mabain_c_interface.cpp:11: undefined reference to > `mabain::CONSTS::WriterOptions()' > > /tmp/go-build378478658/b001/_x003.o: In function `mbFind': > > ./mabain_c_interface.cpp:44: undefined reference to `mabain::MBData::MBData()' > > ./mabain_c_interface.cpp:45: undefined reference to `mabain::DB::Find(char > const*, int, mabain::MBData&) const' > > ./mabain_c_interface.cpp:44: undefined reference to > `mabain::MBData::~MBData()' > > ./mabain_c_interface.cpp:44: undefined reference to > `mabain::MBData::~MBData()' > > /tmp/go-build378478658/b001/_x003.o: In function `mbClose': > > ./mabain_c_interface.cpp:23: undefined reference to `mabain::DB::Close()' > > /tmp/go-build378478658/b001/_x003.o: In function `mbAdd': > > ./mabain_c_interface.cpp:30: undefined reference to `mabain::DB::Add(char > const*, int, char const*, int, bool)' > > /tmp/go-build378478658/b001/_x003.o: In function `mbRemove': > > ./mabain_c_interface.cpp:37: undefined reference to `mabain::DB::Remove(char > const*, int)' > > collect2: error: ld returned 1 exit status > > > > root@e75d907ebd87:/usr/local/lib# ls -ltr > > total 1844 > > -rwxr-xr-x 1 root root 1887608 Mar 17 11:42 libmabain.so > > root@e75d907ebd87:/usr/local/lib# > > > > root@e75d907ebd87:/usr/local/lib# objdump -t libmabain.so | grep ReaderOption > > 00022b60 g F .text 0003 > _ZN6mabain6CONSTS13ReaderOptionsEv > > > Any suggestions on how to fix this linker error ? I don't see anything obviously wrong. Add -v to -ldflags to see exactly how the external linker is being invoked. Make sure that -lmabain appears at the right point in the link line. Ian -- 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/CAOyqgcWhbQJZ8tqT4LrOe2sR%3DUdfJXDos15r27R-VgpB3%2BfB8w%40mail.gmail.com.
Re: [go-nuts] Re: Mem-Leak in Go method
My only thought was that maybe you had more Go routines accessing it than you
thought.
It is remains constant after a while it is most likely not a memory leak. It is
done what surprising that the memory consumption in a steady state would be 4x
the equivalent C program.
> On Mar 17, 2020, at 9:21 AM, Nitish Saboo wrote:
>
>
> Hi Robert,
>
> Thanks for your response.
> Since patterndb is a global variable(not a thread-local variable) and I have
> a single goroutine that calls load_pattern_db() method, therefore it was not
> looking correct to me to pin a goroutine to a thread.
> I once again tested the code flow. Apologies for making confusion in my last
> mail. When I called load_pattern_db() for about 6-7 times, every time the
> following lines were getting printed. It looks like patterndb instance is
> getting freed and the memory is becoming constant at around 29%.
>
> Patterndb Free Entered
> Patterndb Free called
> Patterndb New called
>
> node.c
> -
>
> PatternDB *patterndb;
>
> int load_pattern_db(const gchar* file, key_value_cb cb)
> {
> printf("Patterndb Free Entered\n")
> if(patterndb != NULL){
> printf("Patterndb Free called\n"); <<< It is getting printed
> pattern_db_free(patterndb);
> }
> printf("Patterndb New called\n")
> patterndb = pattern_db_new();
> pattern_db_reload_ruleset(patterndb, configuration, file);
> pattern_db_set_emit_func(patterndb, pdbtool_pdb_emit_accumulate, cb);
> return 0;
> }
>
> But, what made you feel that Go global variable would report a race
> condition? Since it is a single goroutine what would cause a race condition
> here ?
>
> Thanks,
> Nitish
>
>> On Tue, Mar 17, 2020 at 6:31 PM Robert Engels wrote:
>> I’ve been thinking about this some more, and I think that LockOSThread()
>> should not be needed - that the Go thread multiplexing must perform memory
>> fences otherwise the simplest of Go apps would have concurrency issues.
>>
>> So, that leads me to believe that your “single routine” is not correct. I
>> would add code on the Go side that does similar Go global variable handling
>> at the call site for the C call. Then run under the race detector - I’m
>> guessing that it will report a race on the Go global.
>>
>>> On Mar 16, 2020, at 2:46 PM, Robert Engels wrote:
>>>
>>> In the single Go routine, use LockOSThread(). Then it was always be
>>> accessed on the same thread removing the memory synchronization problems.
>>>
> On Mar 16, 2020, at 11:28 AM, Nitish Saboo
> wrote:
>
Hi,
So finally I got a little hint of the problem from what Robert described
earlier in the mail. Thank you so much Robert.
Looks like patterndb instance is not getting freed.
node.c
-
PatternDB *patterndb;
int load_pattern_db(const gchar* file, key_value_cb cb)
{
if(patterndb != NULL){
printf("Patterndb Free called\n"); <<< Not getting printed
pattern_db_free(patterndb);
}
patterndb = pattern_db_new();
pattern_db_reload_ruleset(patterndb, configuration, file);
pattern_db_set_emit_func(patterndb, pdbtool_pdb_emit_accumulate, cb);
return 0;
}
patterndb is a global variable in C wrapper code that internally calls
some syslog-ng library api's.Since load_pattern_db() method is getting
called from a single goroutine every 3 mins, patterndb instance is not
getting free because the statement inside if clause ('if(patterndb !=
NULL)') is not getting printed when I call 'load_pattern_db()'
method.Looks like that is the leak here.
1)Can someone please help me understand the problem in detail as in why am
I facing this issue?
2)Though patterndb instance is a global variable in the C wrapper code,
why is it not getting freed?
3)How can I fix this issue?
Thanks,
Nitish
> On Mon, Mar 16, 2020 at 8:17 PM Nitish Saboo
> wrote:
> Hi Robert,
>
> Sorry I did not understand your point completely.
> I have a global variable patterndb on C side and It is getting called
> from a single goroutine every 3 mins. Why do I need to synchronize it?
> Even though the goroutine gets pinned to different threads, it can access
> the same global variable every time and free it ...right ?
>
> Thanks,
> Nitish
>
>
>> On Mon, Mar 16, 2020 at 8:10 PM Robert Engels
>> wrote:
>> Yes, you have a shared global variable you need to synchronize.
>>
On Mar 16, 2020, at 9:35 AM, Nitish Saboo
wrote:
>>>
>>> Hi,
>>>
>>> Are you saying it is working as expected?
>>>
>>> Thanks,
>>> Nitish
>>>
On Mon, Mar 16, 2020 at 7:42 PM Volker Dobler
wrote:
> On Monday, 16 March 2020 14:25:52 UTC+1, Nitish Saboo wrote:
>
[go-nuts] OPI: IBM Job: Go Compiler Developer on IBM's Z Enterprise
Interesting. I just stumbled on it (I have no affiliations). https://careers.ibm.com/ShowJob/Id/850903/Go%20Compiler%20Developer *"The IBM Compiler development team is looking to hire Open Source software developers with a passion for Golang to join our mission in developing a world class offering on IBM platforms. The IBM Toronto Lab is the compilation hub within IBM, known for developing world-class compilers and runtimes. You will get an opportunity to work alongside technical experts in both compilation and cloud development in helping to accelerate our mainframe’s journey to the cloud.As a developer on this team, you will be responsible for working with internal teams and with the Open Source Community for designing, developing and testing the Golang compiler and libraries. You will also be responsible for optimizing and tuning that code for the IBM's Z Enterprise platform and for ensuring that those features are accepted upstream by the Golang community. The main responsibilities of the team include:- enable the latest version of Golang compiler on IBM's Z Enterprise platform- problem determination, problem recreation, providing fixes, validating fixes and getting fixes accepted by the Golang Community.- optimizing and tuning that code for IBM's Z Enterprise platform- Collaborate with members of the container development and deployments teams situated across the globe on a daily basis.- Influence the design of future generation of hardware and OS enhancements thorough collaboration with IBM hardware/OS teams.- Software developers on the team will participate in all aspects of the software development process, from design to implementation, from testing to product delivery and support. Ideal candidates should feel comfortable working in an agile software development environment. The job is located at the IBM Canada Software Lab in Markham Ontario, one of the largest Research and Development (R) facilities in Canada."* Glen -- 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/944c3e5a-c054-4b5d-9758-2c1028785b8b%40googlegroups.com.
Re: [go-nuts] SIGILL running 1.14 on macOS
On Feb 26, 2020, at 2:00 PM, James Pettyjohn wrote: > > A little further digging shows that VZEROUPPER is part of the AVX instruction > set, not supported on any Apple computers prior to 2011 from what I can tell. > > Given the rc1 code worked fine, that could be an alternative for Darwin where > the CPU does not support AVX. While not ideal, I'd argue it's better than > cutting off support for these machines which can run High Sierra. Once > support for High Sierra is dropped then it should not matter as it takes a > 2013 or later model to run anything after High Sierra. There are quite a lot of extant machines running Nehalem-generation Xeons (55/56xx) and routers running older Atoms that don't support AVX. I had a similar problem with the Suricata package for OpenBSD. - Dave -- 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/08181A18-07F3-4BF5-8E12-4D661170C17B%40gmail.com.
[go-nuts] Re: SIGILL running 1.14 on macOS
Sooner the better, it's crept into downstream packages. E.g. docker installed via brew is toast as it was built in 1.14. On Wednesday, March 4, 2020 at 1:16:13 PM UTC-8, Jon Conradt wrote: > > You can follow the progress toward 1.14.1 via > https://github.com/golang/go/milestone/137 > > Looking at 1.13.0 and 1.12.0 it looks like the time between a .0 release > and a .0 release is about three weeks. So I'm hoping for a St. Patrick's > Day releases of 1.14.1 > > Jon > -- 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/e30f0353-e0df-4970-b319-9cc2e8e595ff%40googlegroups.com.
[go-nuts] Re: building C++ wrapper for mabain lib with go1.13
On Tuesday, March 17, 2020 at 12:04:34 PM UTC-4, Mohamed Mahmoud wrote: > > I have created swigcxx file , since swig now is natively integrated in go > tools > I ran the following to build a test program that interact with the mabain > wrapper go package to test the APIs > > go install -x -i -ldflags '-w -extldflags "-lmabain"' > > > However I ran into linker errors that I am not able to resolve > > > # mabain > > /tmp/go-build378478658/b001/_x003.o: In function `mbOpen': > > ./mabain_c_interface.cpp:10: undefined reference to > `mabain::CONSTS::ReaderOptions()' > > ./mabain_c_interface.cpp:12: undefined reference to `mabain::DB::DB(char > const*, int, unsigned long, unsigned long, unsigned int)' > > ./mabain_c_interface.cpp:13: undefined reference to `mabain::DB::is_open() > const' > > ./mabain_c_interface.cpp:14: undefined reference to > `mabain::DB::StatusStr() const' > > ./mabain_c_interface.cpp:11: undefined reference to > `mabain::CONSTS::WriterOptions()' > > /tmp/go-build378478658/b001/_x003.o: In function `mbFind': > > ./mabain_c_interface.cpp:44: undefined reference to > `mabain::MBData::MBData()' > > ./mabain_c_interface.cpp:45: undefined reference to `mabain::DB::Find(char > const*, int, mabain::MBData&) const' > > ./mabain_c_interface.cpp:44: undefined reference to > `mabain::MBData::~MBData()' > > ./mabain_c_interface.cpp:44: undefined reference to > `mabain::MBData::~MBData()' > > /tmp/go-build378478658/b001/_x003.o: In function `mbClose': > > ./mabain_c_interface.cpp:23: undefined reference to `mabain::DB::Close()' > > /tmp/go-build378478658/b001/_x003.o: In function `mbAdd': > > ./mabain_c_interface.cpp:30: undefined reference to `mabain::DB::Add(char > const*, int, char const*, int, bool)' > > /tmp/go-build378478658/b001/_x003.o: In function `mbRemove': > > ./mabain_c_interface.cpp:37: undefined reference to > `mabain::DB::Remove(char const*, int)' > > collect2: error: ld returned 1 exit status > > > root@e75d907ebd87:/usr/local/lib# ls -ltr > > total 1844 > > -rwxr-xr-x 1 root root 1887608 Mar 17 11:42 *libmabain.so* > > root@e75d907ebd87:/usr/local/lib# > > > root@e75d907ebd87:/usr/local/lib# objdump -t libmabain.so | grep > ReaderOption > > 00022b60 g F .text 0003 > _ZN6mabain6CONSTS13*ReaderOption*sEv > > > Any suggestions on how to fix this linker error ? > I have added the changes and steps to build here https://github.com/msherif4/mabain/tree/gointerface/swig/golang > > Thanks!! > -- 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/b9854a83-6c46-4f23-921a-51e2e4a279eb%40googlegroups.com.
[go-nuts] building C++ wrapper for mabain lib with go1.13
I have created swigcxx file , since swig now is natively integrated in go tools I ran the following to build a test program that interact with the mabain wrapper go package to test the APIs go install -x -i -ldflags '-w -extldflags "-lmabain"' However I ran into linker errors that I am not able to resolve # mabain /tmp/go-build378478658/b001/_x003.o: In function `mbOpen': ./mabain_c_interface.cpp:10: undefined reference to `mabain::CONSTS::ReaderOptions()' ./mabain_c_interface.cpp:12: undefined reference to `mabain::DB::DB(char const*, int, unsigned long, unsigned long, unsigned int)' ./mabain_c_interface.cpp:13: undefined reference to `mabain::DB::is_open() const' ./mabain_c_interface.cpp:14: undefined reference to `mabain::DB::StatusStr() const' ./mabain_c_interface.cpp:11: undefined reference to `mabain::CONSTS::WriterOptions()' /tmp/go-build378478658/b001/_x003.o: In function `mbFind': ./mabain_c_interface.cpp:44: undefined reference to `mabain::MBData::MBData()' ./mabain_c_interface.cpp:45: undefined reference to `mabain::DB::Find(char const*, int, mabain::MBData&) const' ./mabain_c_interface.cpp:44: undefined reference to `mabain::MBData::~MBData()' ./mabain_c_interface.cpp:44: undefined reference to `mabain::MBData::~MBData()' /tmp/go-build378478658/b001/_x003.o: In function `mbClose': ./mabain_c_interface.cpp:23: undefined reference to `mabain::DB::Close()' /tmp/go-build378478658/b001/_x003.o: In function `mbAdd': ./mabain_c_interface.cpp:30: undefined reference to `mabain::DB::Add(char const*, int, char const*, int, bool)' /tmp/go-build378478658/b001/_x003.o: In function `mbRemove': ./mabain_c_interface.cpp:37: undefined reference to `mabain::DB::Remove(char const*, int)' collect2: error: ld returned 1 exit status root@e75d907ebd87:/usr/local/lib# ls -ltr total 1844 -rwxr-xr-x 1 root root 1887608 Mar 17 11:42 *libmabain.so* root@e75d907ebd87:/usr/local/lib# root@e75d907ebd87:/usr/local/lib# objdump -t libmabain.so | grep ReaderOption 00022b60 g F .text 0003 _ZN6mabain6CONSTS13*ReaderOption*sEv Any suggestions on how to fix this linker error ? Thanks!! -- 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/94efc828-fab2-4a2a-b486-7c25b57c522c%40googlegroups.com.
Re: [go-nuts] Re: Mem-Leak in Go method
Hi Robert,
Thanks for your response.
Since patterndb is a global variable(not a thread-local variable) and I
have a single goroutine that calls load_pattern_db() method, therefore it
was not looking correct to me to pin a goroutine to a thread.
I once again tested the code flow. Apologies for making confusion in my
last mail. When I called load_pattern_db() for about 6-7 times, every time
the following lines were getting printed. It looks like patterndb instance
is getting freed and the memory is becoming constant at around 29%.
Patterndb Free Entered
Patterndb Free called
Patterndb New called
node.c
-
PatternDB *patterndb;
int load_pattern_db(const gchar* file, key_value_cb cb)
{
printf("Patterndb Free Entered\n")
if(patterndb != NULL){
printf("Patterndb Free called\n"); <<< It is getting printed
pattern_db_free(patterndb);
}
printf("Patterndb New called\n")
patterndb = pattern_db_new();
pattern_db_reload_ruleset(patterndb, configuration, file);
pattern_db_set_emit_func(patterndb, pdbtool_pdb_emit_accumulate, cb);
return 0;
}
But, what made you feel that Go global variable would report a race
condition? Since it is a single goroutine what would cause a race condition
here ?
Thanks,
Nitish
On Tue, Mar 17, 2020 at 6:31 PM Robert Engels wrote:
> I’ve been thinking about this some more, and I think that LockOSThread()
> should not be needed - that the Go thread multiplexing must perform memory
> fences otherwise the simplest of Go apps would have concurrency issues.
>
> So, that leads me to believe that your “single routine” is not correct. I
> would add code on the Go side that does similar Go global variable handling
> at the call site for the C call. Then run under the race detector - I’m
> guessing that it will report a race on the Go global.
>
> On Mar 16, 2020, at 2:46 PM, Robert Engels wrote:
>
> In the single Go routine, use LockOSThread(). Then it was always be
> accessed on the same thread removing the memory synchronization problems.
>
> On Mar 16, 2020, at 11:28 AM, Nitish Saboo
> wrote:
>
>
> Hi,
>
> So finally I got a little hint of the problem from what Robert described
> earlier in the mail. Thank you so much Robert.
> Looks like patterndb instance is not getting freed.
>
> node.c
> -
>
> PatternDB *patterndb;
>
> int load_pattern_db(const gchar* file, key_value_cb cb)
> {
> if(patterndb != NULL){
> printf("Patterndb Free called\n"); <<< Not getting printed
> pattern_db_free(patterndb);
> }
> patterndb = pattern_db_new();
> pattern_db_reload_ruleset(patterndb, configuration, file);
> pattern_db_set_emit_func(patterndb, pdbtool_pdb_emit_accumulate, cb);
> return 0;
> }
>
>
> patterndb is a global variable in C wrapper code that internally calls
> some syslog-ng library api's.Since load_pattern_db() method is getting
> called from a single goroutine every 3 mins, patterndb instance is not
> getting free because the statement inside if clause ('if(patterndb !=
> NULL)') is not getting printed when I call 'load_pattern_db()' method.Looks
> like that is the leak here.
>
>
> 1)Can someone please help me understand the problem in detail as in why am
> I facing this issue?
>
> 2)Though patterndb instance is a global variable in the C wrapper code,
> why is it not getting freed?
>
> 3)How can I fix this issue?
>
> Thanks,
> Nitish
>
> On Mon, Mar 16, 2020 at 8:17 PM Nitish Saboo
> wrote:
>
>> Hi Robert,
>>
>> Sorry I did not understand your point completely.
>> I have a global variable patterndb on C side and It is getting called
>> from a single goroutine every 3 mins. Why do I need to synchronize it?
>> Even though the goroutine gets pinned to different threads, it can access
>> the same global variable every time and free it ...right ?
>>
>> Thanks,
>> Nitish
>>
>>
>> On Mon, Mar 16, 2020 at 8:10 PM Robert Engels
>> wrote:
>>
>>> Yes, you have a shared global variable you need to synchronize.
>>>
>>> On Mar 16, 2020, at 9:35 AM, Nitish Saboo
>>> wrote:
>>>
>>>
>>> Hi,
>>>
>>> Are you saying it is working as expected?
>>>
>>> Thanks,
>>> Nitish
>>>
>>> On Mon, Mar 16, 2020 at 7:42 PM Volker Dobler <
>>> dr.volker.dob...@gmail.com> wrote:
>>>
On Monday, 16 March 2020 14:25:52 UTC+1, Nitish Saboo wrote:
>
> Hi,
>
> I upgraded the go version and compiled the binary against go version
> 'go version go1.12.4 linux/amd64'.
> I ran the program for some time. I made almost 30-40 calls to the
> method Load_Pattern_Db().
> The program starts with 6% Mem Usage. The memory usage increases only
> when I call 'LoadPatternDb()' method and LoadPatternDb() method is called
> by a goroutine at regular intervals of 3 minutes(making use of ticker here
> ).
>
> What I observed is:
>
> 1)After almost 16-17 calls to the method 'LoadPatternDb(), the memory
> usage got almost constant at 29%. But I did not expect the program to take
> this much memory.
>When I restart the
Re: [go-nuts] Re: Mem-Leak in Go method
I’ve been thinking about this some more, and I think that LockOSThread() should
not be needed - that the Go thread multiplexing must perform memory fences
otherwise the simplest of Go apps would have concurrency issues.
So, that leads me to believe that your “single routine” is not correct. I would
add code on the Go side that does similar Go global variable handling at the
call site for the C call. Then run under the race detector - I’m guessing that
it will report a race on the Go global.
> On Mar 16, 2020, at 2:46 PM, Robert Engels wrote:
>
> In the single Go routine, use LockOSThread(). Then it was always be accessed
> on the same thread removing the memory synchronization problems.
>
>> On Mar 16, 2020, at 11:28 AM, Nitish Saboo wrote:
>>
>>
>> Hi,
>>
>> So finally I got a little hint of the problem from what Robert described
>> earlier in the mail. Thank you so much Robert.
>> Looks like patterndb instance is not getting freed.
>>
>> node.c
>> -
>>
>> PatternDB *patterndb;
>>
>> int load_pattern_db(const gchar* file, key_value_cb cb)
>> {
>> if(patterndb != NULL){
>> printf("Patterndb Free called\n"); <<< Not getting printed
>> pattern_db_free(patterndb);
>> }
>> patterndb = pattern_db_new();
>> pattern_db_reload_ruleset(patterndb, configuration, file);
>> pattern_db_set_emit_func(patterndb, pdbtool_pdb_emit_accumulate, cb);
>> return 0;
>> }
>>
>>
>> patterndb is a global variable in C wrapper code that internally calls some
>> syslog-ng library api's.Since load_pattern_db() method is getting called
>> from a single goroutine every 3 mins, patterndb instance is not getting free
>> because the statement inside if clause ('if(patterndb != NULL)') is not
>> getting printed when I call 'load_pattern_db()' method.Looks like that is
>> the leak here.
>>
>>
>> 1)Can someone please help me understand the problem in detail as in why am I
>> facing this issue?
>>
>> 2)Though patterndb instance is a global variable in the C wrapper code, why
>> is it not getting freed?
>>
>> 3)How can I fix this issue?
>>
>> Thanks,
>> Nitish
>>
>>> On Mon, Mar 16, 2020 at 8:17 PM Nitish Saboo
>>> wrote:
>>> Hi Robert,
>>>
>>> Sorry I did not understand your point completely.
>>> I have a global variable patterndb on C side and It is getting called from
>>> a single goroutine every 3 mins. Why do I need to synchronize it?
>>> Even though the goroutine gets pinned to different threads, it can access
>>> the same global variable every time and free it ...right ?
>>>
>>> Thanks,
>>> Nitish
>>>
>>>
On Mon, Mar 16, 2020 at 8:10 PM Robert Engels
wrote:
Yes, you have a shared global variable you need to synchronize.
> On Mar 16, 2020, at 9:35 AM, Nitish Saboo
> wrote:
>
>
> Hi,
>
> Are you saying it is working as expected?
>
> Thanks,
> Nitish
>
>> On Mon, Mar 16, 2020 at 7:42 PM Volker Dobler
>> wrote:
>>> On Monday, 16 March 2020 14:25:52 UTC+1, Nitish Saboo wrote:
>>> Hi,
>>>
>>> I upgraded the go version and compiled the binary against go version
>>> 'go version go1.12.4 linux/amd64'.
>>> I ran the program for some time. I made almost 30-40 calls to the
>>> method Load_Pattern_Db().
>>> The program starts with 6% Mem Usage. The memory usage increases only
>>> when I call 'LoadPatternDb()' method and LoadPatternDb() method is
>>> called by a goroutine at regular intervals of 3 minutes(making use of
>>> ticker here ).
>>>
>>> What I observed is:
>>>
>>> 1)After almost 16-17 calls to the method 'LoadPatternDb(), the memory
>>> usage got almost constant at 29%. But I did not expect the program to
>>> take this much memory.
>>>When I restart the service the Mem Usage again starts with 6%.
>>>
>>> a) Is this the sign of memory leaking?
>>
>> No, as explained above.
>>
>>>
>>> b) Till this moment I did not see memory getting reclaimed or going
>>> down but it did become constant.
>>> As mentioned by experts above, the same sort of behavior is seen here.
>>> But I did not expect the memory usage to grow this much. Is this
>>> expected?
>> Yes. (Well, no. But your gut feeling of how much memory
>> should grow is not a suitable benchmark to compare
>> actual growth to.)
>>
>>>
>>> 2)I will run mem-profiling at intervals(10 minutes, 100 minutes..etc)
>>> as mentioned in the earlier email.
>>>
>>> a) Which all mem-stats variables should I look into for debugging this
>>> kind of behavior?
>> Alloc/HeapAlloc
>> But probably this is plain useless as nothing here indicates
>> that you do have any memory issues.
>>
>> V.
>>
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "golang-nuts" group.
>> To unsubscribe from
