Hi Tamas,
Using RPC will not scale and it needs lot of effort. So our only choice is
CGO.
Best Regards
Mariappan
On Monday, January 9, 2023 at 5:04:19 PM UTC+5:30 Tamás Gulácsi wrote:
> I'd create a separate C program, that can be communicated with RPC style -
> (https://github.com/protobuf-c/
I'd create a separate C program, that can be communicated with RPC style -
(https://github.com/protobuf-c/protobuf-c-rpc may solve it easily),
and have the Go program start it like
https://github.com/hashicorp/go-plugin .
That way the stack traces and core dumps are separate, each program is
ea
Hi Ian,
Thanks. I will try this. When a process is crashed because of a
SEGMENTATION fault, it can be debugged by identifying the stack trace from
the core dump. Is there any other technique to debug this issue? Can you
please help if any other technique is there?
Best Regards
Mariappan
On Mon,
On Sun, Jan 8, 2023, 9:33 PM mariappan balraj
wrote:
> Hi Ian,
>
> Thanks for all your replies. It really shows that you have tried to give
> your best all the time. I need some direction to get a permanent solution
> for this. Is it possible to get help from the core google GO team? How to
> esc
Hi Ian,
Thanks for all your replies. It really shows that you have tried to give
your best all the time. I need some direction to get a permanent solution
for this. Is it possible to get help from the core google GO team? How to
escalate this issue and get the fix? Please give me directions. So th
On Fri, Jan 6, 2023 at 9:01 PM mariappan balraj
wrote:
>
> Thanks for your continuous support. GOLANG supports CGO to invoke C
> functions. When it is supported, the important thing is, it should provide
> better debugging support when there is any issue. In customer sites, it is
> not possible
Hi Ian,
Thanks for your continuous support. GOLANG supports CGO to invoke C
functions. When it is supported, the important thing is, it should provide
better debugging support when there is any issue. In customer sites, it is
not possible to run applications with GDB. Customers only provide core d
On Fri, Jan 6, 2023, 5:57 PM mariappan balraj
wrote:
> Hi Ian,
> Thanks for your active help. When I run the program by using gdb, I am
> getting the complete stack. No issue. The issue is there when we debug core
> dump. Could you kindly please check whether you are seeing the same
> behavior wi
Hi Ian,
Thanks for your active help. When I run the program by using gdb, I am
getting the complete stack. No issue. The issue is there when we debug core
dump. Could you kindly please check whether you are seeing the same
behavior with core dump?
Best Regards
Mariappan
On Sat, 7 Jan, 2023, 7:03
On Fri, Jan 6, 2023 at 5:28 PM mariappan balraj
wrote:
>
> I am not expecting GO stack. I am interested only in getting C stack. If I
> want go stack, I can use delve debugger to get it. From GO, using CGO,
> test3() is called which is calling test2() which is calling test1(). I am
> expecting
Hi Ian,
I am not expecting GO stack. I am interested only in getting C stack. If I
want go stack, I can use delve debugger to get it. From GO, using CGO,
test3() is called which is calling test2() which is calling test1(). I am
expecting only C stack which contains test3(), test2(), test1(). In t
On Thu, Jan 5, 2023 at 10:39 PM mariappan balraj
wrote:
>
> When I call the same function from pure C code, I am able to get the complete
> stack and it is not reporting that the stack is corrupted. I am expecting the
> same C stack when I use CGO also. Please kindly help with this.
C code and
Hi Ian,
When I call the same function from pure C code, I am able to get the
complete stack and it is not reporting that the stack is corrupted. I am
expecting the same C stack when I use CGO also. Please kindly help with
this.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x000
Hi Ian,
Thanks for your quick reply. I have now tried setting the CGO_CFLAGS to -g.
Now I am seeing the following BT. It is reporting "corrupt stack".
(gdb) bt
#0 runtime.raise () at /usr/local/go/src/runtime/sys_linux_amd64.s:159
#1 0x00443345 in runtime.dieFromSignal (sig=6) at
/usr/l
On Thu, Jan 5, 2023 at 9:02 PM mariappan balraj
wrote:
>
> Thanks for your reply. This point is clear. I am interested only in getting
> the complete C call stack only. I could able to get the GO stack by using the
> delve debugger.
>
> When I use the GDB, I am getting the following stack. In th
Hi Ian,
Thanks for your reply. This point is clear. I am interested only in getting
the complete C call stack only. I could able to get the GO stack by using
the delve debugger.
When I use the GDB, I am getting the following stack. In the stack I am
seeing the last C function called which test1()
On Thu, Dec 22, 2022 at 1:57 PM mariappan balraj
wrote:
>
> I have following programming where making CGO from GO code. test3() is called
> from Go code. Which calls test2() and which calls test1(). In test1(), there
> is a NULL pointer assignment. I could able to generate the core dump when
>
Hi,
I have following programming where making CGO from GO code. test3() is
called from Go code. Which calls test2() and which calls test1(). In
test1(), there is a NULL pointer assignment. I could able to generate the
core dump when running the program. But when I use gdb, I am not getting
the
18 matches
Mail list logo
