Mac iTOps Tube

Monday, May 14, 2012

mmap questions

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











No comments:

Post a Comment