On 2020-09-30 23:48, Ian Lance Taylor wrote:
>> Is there a way to accomplish this in go? Normally what I'd do is `fork` a
>> process that would handle writing to a pipe, `dup` the read end of the pipe
>> to stdin and then `exec` to the process I want to run, but `syscall` doesn't
>> have a `Fork
Thanks for the info and suggestions, especially the interesting detail
about why Go has no `syscall.Fork`. Although I did get it working as
desired, the solution is complicated enough that I'll probably just live
with `exec.Command`. But it was a fun puzzle to work out. :)
--
You received this
We are working on a full scale production app with go backend.
For unit tests, we need to mock the dependent interfaces either by creating
our own mock implementation of the interface or by using third party
packages like *testify/mocks.*
If we use testify, there will be a tendency for the deve
I have enabled coredump with `ulimit -c unlimited`, and run the binary with
GOTRACEBACK=crash, but it only outputs the go stack trace when crash.
thanks.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop r
CGo is not Go -- C-land crash information fully depends on your C-compiler.
[Joop Kiefte - Chat @
Spike](https://spikenow.com/r/a/?ref=spike-organic-signature&_ts=pj5l7)
[pj5l7]
On October 2, 2020 at 0:39 GMT, aihui zhu wrote:
I have enabled coredump with `ulimit -c unlimited`, and run the
On Thu, Oct 1, 2020 at 5:39 PM aihui zhu wrote:
> I have enabled coredump with `ulimit -c unlimited`, and run the binary
> with GOTRACEBACK=crash, but it only outputs the go stack trace when crash.
Have you verified that you can generate a core dump from a pure C program
that simply dereference
On Thu, Oct 1, 2020 at 5:39 PM aihui zhu wrote:
>
> I have enabled coredump with `ulimit -c unlimited`, and run the binary with
> GOTRACEBACK=crash, but it only outputs the go stack trace when crash.
There are two different things. There is the stack trace emitted when
a program crash. And the
yes, there are only go stack trace, and no core file was generated. with a
pure C program, it could generate core file in /cores directory.
On Friday, October 2, 2020 at 10:16:51 AM UTC+8 Ian Lance Taylor wrote:
> On Thu, Oct 1, 2020 at 5:39 PM aihui zhu wrote:
> >
> > I have enabled coredump w
on a linux virtual machine GOTRACEBACK=crash works fine and would generates
core files in working directory for me.
On Friday, October 2, 2020 at 11:33:37 AM UTC+8 aihui zhu wrote:
> yes, there are only go stack trace, and no core file was generated. with a
> pure C program, it could generate c
On Thu, Oct 1, 2020 at 8:36 PM aihui zhu wrote:
> on a linux virtual machine GOTRACEBACK=crash works fine and would
> generates core files in working directory for me.
>
I just tested this trivial Go (not CGo) program:
package main
func main() {
panic("WTF")
}
I ran the above program on Lin
On Thu, Oct 1, 2020 at 9:05 PM Kurtis Rader wrote:
>
> On Thu, Oct 1, 2020 at 8:36 PM aihui zhu wrote:
>>
>> on a linux virtual machine GOTRACEBACK=crash works fine and would generates
>> core files in working directory for me.
>
>
> I just tested this trivial Go (not CGo) program:
>
> package m
C program could generate a core dump file, my os is Big Sur beta.
➜ ~ ./a.out
[1]37539 segmentation fault ./a.out
➜ ~ ulimit -c unlimited
➜ ~ ./a.out
[1]37596 segmentation fault (core dumped) ./a.out
➜ ~ cat a.c
int main() {
int a = *((int*)(0));
return a;
}
➜ ~ ls /cores -l
12 matches
Mail list logo
