Closed joy4eg closed 5 years ago
Not really enough to diagnose from here. There's no indication of where the problem occurred, not even a stack trace with function names.
Perhaps an MQ trace, if the error is actually happening in the MQ libraries. Or something in the MQ error logs or FDC files. Or running it under a debugger to trap the SEGV would show it.
Looks like we have NULL pointer dereference here:
Thread 8 "amqscb" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffd3055700 (LWP 31116)]
0x0000000000493c06 in github.com/ibm-messaging/mq-golang/ibmmq.copyGMOfromC (gogmo=0xc0000c2000, mqgmo=0x0) at /home/userx/work/golang/pkg/mod/github.com/ibm-messaging/mq-golang@v3.3.3+incompatible/ibmmq/mqiMQGMO.go:110
110 gogmo.Version = int32(mqgmo.Version)
(gdb) bt
#0 0x0000000000493c06 in github.com/ibm-messaging/mq-golang/ibmmq.copyGMOfromC (gogmo=0xc0000c2000, mqgmo=0x0) at /home/userx/work/golang/pkg/mod/github.com/ibm-messaging/mq-golang@v3.3.3+incompatible/ibmmq/mqiMQGMO.go:110
#1 0x0000000000495812 in github.com/ibm-messaging/mq-golang/ibmmq.MQCALLBACK_Go (hConn=<optimized out>, mqBuffer=<optimized out>, mqcbc=<optimized out>, mqgmo=0x0, mqmd=<optimized out>)
at /home/userx/work/golang/pkg/mod/github.com/ibm-messaging/mq-golang@v3.3.3+incompatible/ibmmq/mqicb.go:72
#2 0x0000000000491f61 in github.com/ibm-messaging/mq-golang/ibmmq._cgoexpwrap_4f43e2784329_MQCALLBACK_Go (p0=<optimized out>, p1=<optimized out>, p2=<optimized out>, p3=<optimized out>, p4=<optimized out>)
at _cgo_gotypes.go:1581
#3 0x00000000004567ab in runtime.call64 () at /usr/lib/golang/src/runtime/asm_amd64.s:523
#4 0x000000000040901b in runtime.cgocallbackg1 (ctxt=0) at /usr/lib/golang/src/runtime/cgocall.go:313
#5 0x0000000000408de6 in runtime.cgocallbackg (ctxt=0) at /usr/lib/golang/src/runtime/cgocall.go:191
#6 0x0000000000457cfb in runtime.cgocallback_gofunc () at /usr/lib/golang/src/runtime/asm_amd64.s:775
#7 0x0000000000458441 in runtime.goexit () at /usr/lib/golang/src/runtime/asm_amd64.s:1333
#8 0x0000000000000000 in ?? ()
For some reason mqgmo
that came from C code (if I understand correctly) is NULL.
Thread 8 "amqscb" hit Breakpoint 1, MQCALLBACK_Go (p0=16777221, p1=0x0, p2=0x0, p3=0x0, p4=0x628010) at _cgo_export.c:23
23 _cgo_export.c: Нет такого файла или каталога.
(gdb) p p4
$1 = (MQCBC *) 0x628010
(gdb) p *p4
$3 = {
StrucId = "CBC ",
Version = 1,
CallType = 5,
Hobj = 0,
CallbackArea = 0x0,
ConnectionArea = 0x0,
CompCode = 2,
Reason = 2033,
State = 0,
DataLength = 0,
BufferLength = 0,
Flags = 0,
ReconnectDelay = 0
}
Also I have tried to make breakpoint at ibmmq._cgoexpwrap_4f43e2784329_MQCALLBACK_Go
but it was useless because all arguments are optimized.
Hope this was helpful.
Looks like Reason = 2033
it's MQRC_NO_MSG_AVAILABLE
, which make sense, because default timeout for waiting for a new messages is 3sec
and application also crashes in this time.
So we can just add additional check, that mqmd
, mqgmo
, mqBuffer
are NOT NULL, because, as I see, they are NULL if we are trying to prepare data to invoke user callback when no message was received.
thanks for the trace. I can see what's going on. It's not quite as simple as testing for NULL though. It appears that the client connections are behaving differently than local connections for 2033 timeouts - the CallType in the CBC indicates an EVENT rather than MESSAGE. I'm not certain that's how it's meant to behave, but it does ... I'll need to look deeper into the underlying MQ libraries to see what's going on there. Feels like a bug.
And in the meantime, that event that is not associated with an hObj is leading to the sample program not ending correctly as there's no handler registered for it, which will need to be dealt with somehow.
the CallType in the CBC indicates an EVENT rather than MESSAGE.
From my point of view, it make sense, because we don't have any message to process.
Anyway, thanks for the help and investigations. Feel free to ping me if you will need to do some more testing/debugging :)
Have tested with fb10f45792754c5fd85af2d46bde27485da5a4ea and now it works fine, thanks! I guess you can close the issue and create please a new release.
Thank you!
Hey Folks,
Here is the environment information:
The issue:
amqscb
from masterExpected result:
Actual result:
Logs: