M**********n
发帖数: 432 | 1 I have a big core dump file ( created by using kill ). The program has a lot
of threads. How can I figure out how much memory does each thread use with
gdb? |
t****t
发帖数: 6806 | 2 memory is shared across all threads, so your question doesn't make sense at
all.
lot
with
【在 M**********n 的大作中提到】
: I have a big core dump file ( created by using kill ). The program has a lot
: of threads. How can I figure out how much memory does each thread use with
: gdb?
|
M**********n
发帖数: 432 | 3 Is there any way that I can find out why the core is so big? We know that
the program assumes a log of memory when being killed to generate the core
file.
at
【在 t****t 的大作中提到】
: memory is shared across all threads, so your question doesn't make sense at
: all.
:
: lot
: with
|
t****t
发帖数: 6806 | 4 why the core is so big? because you allocated a lot of memory. why you
allocated a lot of memory? i think only you know...
【在 M**********n 的大作中提到】
: Is there any way that I can find out why the core is so big? We know that
: the program assumes a log of memory when being killed to generate the core
: file.
:
: at
|
M**********n
发帖数: 432 | 5 You were not answering my question.
Of course there are a lot memory allocated, which is the exact problem we
want to find out. However, this is not the expected result. So we want to
figure out why it is so (maybe by using gdb and the core). Unfortunately we
only have the core file from the customer. And we can not reproduce the
result from our side.
【在 t****t 的大作中提到】
: why the core is so big? because you allocated a lot of memory. why you
: allocated a lot of memory? i think only you know...
|
t****t
发帖数: 6806 | 6 no this was not your question, your question was "why the core is so big",
and I answered that.
so you actually want to know "who (which line) and when memory is allocated,
with core file only", and that makes sense.
i would say it's very difficult, with core only. if memory is corrupted, i
would say it's impossible. gdb does not know the memory allocation data
structure, you need to check glibc -- and you must make sure which glibc
your client used.
i will suggest you run your code locally with valgrind first.
we
【在 M**********n 的大作中提到】
: You were not answering my question.
: Of course there are a lot memory allocated, which is the exact problem we
: want to find out. However, this is not the expected result. So we want to
: figure out why it is so (maybe by using gdb and the core). Unfortunately we
: only have the core file from the customer. And we can not reproduce the
: result from our side.
|
D*******a
发帖数: 3688 | 7 or use tcmalloc which can generate a heap map.
allocated,
【在 t****t 的大作中提到】
: no this was not your question, your question was "why the core is so big",
: and I answered that.
: so you actually want to know "who (which line) and when memory is allocated,
: with core file only", and that makes sense.
: i would say it's very difficult, with core only. if memory is corrupted, i
: would say it's impossible. gdb does not know the memory allocation data
: structure, you need to check glibc -- and you must make sure which glibc
: your client used.
: i will suggest you run your code locally with valgrind first.
:
|
