mmap questions

[de]

Hi,

I'm working with a legacy system and it suddenly begins to core
recently. By doing a strace, I found the following in the trace:

1. [pid xxx] mmap(NULL, 20480, PROT_READ|PROT_WRITE, MAP_SHARED, 116,
0x799300) = 0x2a955d700
2. [pid xxx] munmap(0x2a955d700, 20480) = 0
3. [pid xxx] mmap(NULL, 20480, PROT_READ|PROT_WRITE, MAP_SHARED, 116,
0x799400) = 0x2a955d700
4. [pid xxx] munmap(0x2a955d700, 20480) = 0
5. [pid xxx] mmap(NULL, 20480, PROT_READ|PROT_WRITE, MAP_SHARED, 116,
0x799800) = 0x2a955d700
6. [pid xxx] munmap(0x2a955d700, 20480) = 0
7. [pid xxx] mmap(NULL, 20480, PROT_READ|PROT_WRITE, MAP_SHARED, 116,
0x4eef000) = 0x2a955d700
8. [pid xxx] mmap(NULL, 18446744071562084352, PROT_READ|PROT_WRTITE,
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 EINVAL (Invalid argument)
9. [pid xxx] mmap(NULL, 18446744071562084352, PROT_READ|PROT_WRTITE,
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 EINVAL (Invalid argument)
10. [pid xxx] mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|
MAP_ANONYMOUS, -1, 0) = 0x2a955dc00

My questions are as following:
1. Does it look right for line 3 above to request mmap with offset
0x799400? Line 1 says it needs mmap with offset 0x799300 and length =
20480. It looks like the first mmap should cover from offset 0x799300
to offset 0x799300 (which is 127479808 decimal) + (decimal)20480 =>
0x7998000. I would imagine line 5 will be the next mmap directly
following line 1. Why line 3 above tries to mmap something in the
middle again? The trace file shows a lot mmap calls in this pattern,
i.e. there is always a mmap call in between of one offset and offset +
len.

(1.a As a side note to question 1 above, it seems 0x799300 got
converted to 127479808 decimal on a 64-bit Windows Calculator but
7967488 on a 32-bit one. I guess it overflows 32-bit one.)

2. Does it look right for line 7 above without munmap? I know
sometimes munmap isn't required. But given line 2,4,6 all have munmap,
I don't know why line 7 doesn't have a matching munmap.

3. Line 8 and 9 definitely are the problem. The length argument is way
too large. But what are line 8 and 9 trying to do by MAP_PRIVATE|
MAP_ANONYMOUS? Is this just trying to allocate more memory, which has
nothing to do with fd 116?

Thanks

[Scott Lurndal]

de <davis...@yahoo.com> writes:
>Hi,

>3. Line 8 and 9 definitely are the problem. The length argument is way
>too large. But what are line 8 and 9 trying to do by MAP_PRIVATE|
>MAP_ANONYMOUS? Is this just trying to allocate more memory, which has
>nothing to do with fd 116?

They are allocating swap space (anonymous space). The length argument is
asking for more swap space than is available.

If you really have 116 open files, ok. Otherwise, look for a file descriptor
leak.

scott