Read map

[realuptime]

Hi,

memleax failed by exiting wiith read map error:

if (read(fd, ms->data, end - start) != end - start) {
    printf("Error: read map of %s\n", path);
    exit(6);
}

Cange it to:

if ( (readRet = read(fd, ms->data, end - start)) != end - start) { printf("Error: read map of %s. read:%d should:%d errno:%d\n", path, readRet, end-start, errno); // exit(6); }

=> Error: read map of /lib/x86_64-linux-gnu/libgcc_s.so.1. read:90096 should:90112 errno:0

it seems that read() is returning less bytes than requested. So I commented the exit points and it works. Maybe you have time to investigate why this is happening.

Regards, Catalin,.

[realuptime]

And after a few minutes it crashed:

CallStack[130843]: expired-memory frees after 53 seconds CallStack[130843]: expired-memory frees after 53 seconds CallStack[130843]: expired-memory frees after 59 seconds Warning: too many expired-free at CallStack[130843]. will not show this CallStack later CallStack[130843]: expired-memory frees after 263 seconds CallStack[130843]: expired-memory frees after 54 seconds CallStack[130843]: expired-memory frees after 54 seconds Segmentation fault

[realuptime]

And BTW, it crashed the running program! This is serious!

[WuBingzheng]

Thanks for your report. Sorry for crashing your program. If memleax failed on init (reading maps), it may fail later when running. And it crashes without detaching the target process, so the process crashes. I will fix it as soon as possible. What's your OS?

BTW, what's your program? Why there are so many (13084) CallStacks which may have memory leak? If most of expired-memory-blocks are freed later in 60 seconds, maybe you want try -e 60.

[realuptime]

System: debian 8.2 Linux www 2.6.32-34-pve #1 SMP Fri Dec 19 07:42:04 CET 2014 x86_64 GNU/Linux gcc 4.9.2

Program: backgammon server writen in c++ (c++11). It does a few mallocs here and there, but has only a small leak that gets to a few MBs in a month. It uses a thread per client connection.

Unfortunately I cannot debug in production, but I will try to debug it when I have time.

Thank you, Catalin.

On Wed, Jun 15, 2016 at 9:16 AM, WuBingzheng notifications@github.com wrote:

Thanks for your report. Sorry for crashing your program. If memleax failed on init (reading maps), it may fail later when running. And it crashes without detaching the target process, so the process crashes. I will fix it as soon as possible. What's your OS?

BTW, what's your program? Why there are so many (13084) CallStacks which may have memory leak? If most of expired-memory-blocks are freed later in 60 seconds, maybe you want try -e 60.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/WuBingzheng/memleax/issues/6#issuecomment-226097657, or mute the thread https://github.com/notifications/unsubscribe/ARw540SUBRaqjrFN8dWFkEGLDWQADTMHks5qL5iwgaJpZM4I1Qwu .

[WuBingzheng]

I am downloading Debian. It's slow.

Could you reproduce the crash, not in production of course? Do you have the coredump for crash?

Could you give the output of the following cmds:

find /usr/ -name libgcc_s-* | xargs readelf -S  | tail  -20
cat /proc/${your-program-pid}/maps | grep libgcc_s

[WuBingzheng]

I run memleax on Debian. It fails on reading maps of libgcc_s, but not crashes. Now I think the failure is not matter, and should not cause crash. So maybe another bug of memleax caused your crash. Hope you can reproduce the crash.

[WuBingzheng]

I found a serious bug, which leads crash when you have many CallStacks. I have fixed it just now. Maybe you want to try it.

I am going to add a SIGSEGV handler, to print backtrace when crash, and detach target process before exit to avoid it crashing too. But it need some time.