On 23-Apr-20 7:36 AM, Feng Li wrote:
Hi,
I have tested as follows, the core dump file is ~ 200KB.
It should generate one core dump file each crash.
#include
#include
#include
#include
#include
#include
int main(int argc, char** argv) {
// FIXME(fengli): X
uint64_t size = 1<<30;
void*
On 22-Apr-20 4:13 AM, Li Feng wrote:
Really？So weird.
I have tested on 4 machines, running CentOS 7.
The core dump size is the same as the first argument GiB.
Thanks,
Feng Li
Burakov, Anatoly 于2020年4月22日周三 上午1:02写道：
On 21-Apr-20 5:38 PM, Feng Li wrote:
Hi Anatoly,
This program could run l
Really？So weird.
I have tested on 4 machines, running CentOS 7.
The core dump size is the same as the first argument GiB.
Thanks,
Feng Li
Burakov, Anatoly 于2020年4月22日周三 上午1:02写道：
>
> On 21-Apr-20 5:38 PM, Feng Li wrote:
> > Hi Anatoly,
> >
> > This program could run like this:
> > gcc test_map.
Hi Anatoly,
This program could run like this:
gcc test_map.c
./a.out 2 &
gcore `pidof a.out`
You will get a core dump sized to 2GiB.
Thanks,
Feng Li
Burakov, Anatoly 于2020年4月21日周二 下午8:19写道：
>
> On 21-Apr-20 12:06 PM, Feng Li wrote:
> > #include
> > #include
> > #include
> > #include
> > #i
Hi David,
Mmap with PROT_NONE does not affected the core dump size.
Here is a simple test prog:
#include
#include
#include
#include
#include
#include
int main(int argc, char** argv) {
// FIXME(fengli): X
uint64_t gb = atoi(argv[1]);
void* ptr = mmap(0, gb << 30, PROT_NONE,
On 21-Apr-20 5:38 PM, Feng Li wrote:
Hi Anatoly,
This program could run like this:
gcc test_map.c
./a.out 2 &
gcore `pidof a.out`
You will get a core dump sized to 2GiB.
Thanks,
Feng Li
I did just that, and my core dump was ~100K in size. Hence my asking
about any special configuration req
On 21-Apr-20 12:06 PM, Feng Li wrote:
#include
#include
#include
#include
#include
#include
int main(int argc, char** argv) {
// FIXME(fengli): X
uint64_t gb = atoi(argv[1]);
void* ptr = mmap(0, gb << 30, PROT_NONE, MAP_PRIVATE |
MAP_ANONYMOUS, -1, 0);
if (ptr == (v
On Mon, Apr 20, 2020 at 11:41 AM Feng Li wrote:
>
> Thank you, Marchand,
David is fine.
>
> I have just tested your patch, and it doesn't work.
> The core dump file is still very very large, the same to virtual memory size.
Please double check that the patch is in.
I remember checking coredump
Thank you, Marchand,
I have just tested your patch, and it doesn't work.
The core dump file is still very very large, the same to virtual memory size.
David Marchand 于2020年4月20日周一 下午3:13写道：
>
> On Mon, Apr 20, 2020 at 9:10 AM Li Feng wrote:
> > Li Feng 于2020年4月20日周一 下午3:04写道：
> > >
> > > Avoid
On Mon, Apr 20, 2020 at 9:10 AM Li Feng wrote:
> Li Feng 于2020年4月20日周一 下午3:04写道：
> >
> > Avoid dump all mmapped memory to coredump file when crash.
> > Otherwise it will very large and it's hard to analyze with gdb.
> >
> > In my test, it will dump 128GiB memory to coredump file when integrated
>
Add cc dev@dpdk.org
Thanks,
Feng Li
Li Feng 于2020年4月20日周一 下午3:04写道：
>
> Avoid dump all mmapped memory to coredump file when crash.
> Otherwise it will very large and it's hard to analyze with gdb.
>
> In my test, it will dump 128GiB memory to coredump file when integrated
> to spdk with default
11 matches
Mail list logo
