[lldb-dev] VMRange merging in ProcessElfCore and DoReadMemory

Wed Feb 19 16:09:37 PST 2014

Hi,

It was just theoretical issue I speculated about, because I was trying to
find reason why Unwind ThreadPlan for any other thread than thread group
leader fails - and this seems to be already created and cached.

If you want to give it a shot, I'll attach one of my puppets (10 threads,
doing nothing but sleep).
Also I use bfd linker so it has nothing to do with gold in my case.

core was created by kernel (ulimit -c unlimited; kill -3 IIRC)

Please note strange backtraces (clearly .text is not accessible):

(lldb) target create a.out -c core.9025
Core file '/home/prak/soft/test/core.9025' (x86_64) was loaded.
Process 0 stopped
* thread #1: tid = 0, 0x00007fddcd16b4a2 libpthread.so.0`pthread_join +
162, name = 'a.out', stop reason = signal SIGQUIT
    frame #0: 0x00007fddcd16b4a2 libpthread.so.0`pthread_join + 162
libpthread.so.0`pthread_join + 162:
-> 0x7fddcd16b4a2:  addb   %al, (%rax)
   0x7fddcd16b4a4:  addb   %al, (%rax)
   0x7fddcd16b4a6:  addb   %al, (%rax)
   0x7fddcd16b4a8:  addb   %al, (%rax)
  thread #2: tid = 1, 0x00007fddcc867aad libc.so.6, stop reason = signal
SIGQUIT
    frame #0: 0x00007fddcc867aad libc.so.6
libc.so.6`??? + 45:
-> 0x7fddcc867aad:  addb   %al, (%rax)

libc.so.6`??? + 47:
   0x7fddcc867aaf:  addb   %al, (%rax)

libc.so.6`??? + 49:
   0x7fddcc867ab1:  addb   %al, (%rax)

libc.so.6`??? + 51:
   0x7fddcc867ab3:  addb   %al, (%rax)
  thread #3: tid = 2, 0x00007fddcc867aad libc.so.6, stop reason = signal
SIGQUIT
    frame #0: 0x00007fddcc867aad libc.so.6

and so on it goes for other threads, what looks in memory like 0x00 ...

We managed to unwind main thread though.

bt
* thread #1: tid = 0, 0x00007fddcd16b4a2 libpthread.so.0`pthread_join +
162, name = 'a.out', stop reason = signal SIGQUIT
  * frame #0: 0x00007fddcd16b4a2 libpthread.so.0`pthread_join + 162
    frame #1: 0x0000000000469c77 a.out`std::thread::join() + 39
    frame #2: 0x0000000000433e0b a.out`main + 162 at main.cc:30
    frame #3: 0x00007fddcc7d2b05 libc.so.6`__libc_start_main + 245
    frame #4: 0x0000000000433b81 a.out`_start + 41
(lldb) thread 2
invalid command 'thread 2'
(lldb) thread select 2
* thread #2: tid = 1, 0x00007fddcc867aad libc.so.6, stop reason = signal
SIGQUIT
    frame #0: 0x00007fddcc867aad libc.so.6
libc.so.6`??? + 45:
-> 0x7fddcc867aad:  addb   %al, (%rax)

libc.so.6`??? + 47:
   0x7fddcc867aaf:  addb   %al, (%rax)

libc.so.6`??? + 49:
   0x7fddcc867ab1:  addb   %al, (%rax)

libc.so.6`??? + 51:
   0x7fddcc867ab3:  addb   %al, (%rax)

* thread #2: tid = 1, 0x00007fddcc867aad libc.so.6, stop reason = signal
SIGQUIT
    frame #0: 0x00007fddcc867aad libc.so.6
libc.so.6`??? + 45:
-> 0x7fddcc867aad:  addb   %al, (%rax)

libc.so.6`??? + 47:
   0x7fddcc867aaf:  addb   %al, (%rax)

libc.so.6`??? + 49:
   0x7fddcc867ab1:  addb   %al, (%rax)

libc.so.6`??? + 51:
   0x7fddcc867ab3:  addb   %al, (%rax)
image dump sections
Dumping sections for 6 modules.
Sections for '/home/prak/soft/test/a.out' (x86_64):
  SectID     Type             Load Address                             File
Off.  File Size  Flags      Section Name
  ---------- ---------------- ---------------------------------------
 ---------- ---------- ---------- ----------------------------
  ...
  0x0000000e code             [0x0000000000433840-0x000000000048b7b2)
 0x00033840 0x00057f72 0x00000006 a.out..text

....

Sections for '/usr/lib/libc.so.6' (x86_64):
  SectID     Type             Load Address                             File
Off.  File Size  Flags      Section Name
  ---------- ---------------- ---------------------------------------
 ---------- ---------- ---------- ----------------------------
....
  0x0000000d code             [0x00007fddcc7d0490-0x00007fddcc8fb253)
 0x0001f490 0x0012adc3 0x00000006 libc.so.6..text
....

(lldb) memory read 0x0000000000433840
0x00433840: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 ................
0x00433850: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 ................
(lldb) x 0x00007fddcceb9510
0x7fddcceb9510: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 ................
0x7fddcceb9520: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 ................

Other sections from ELF's are not there too.

Some single threaded program like /usr/bin/sleep fail with core created by
linux kernel, yet fine while created by gcore (may it add .text section to
core? - x <address of .text> seems fine then)

I've noticed that all Target::ReadMemory and friends go directly to Process
instead of trying to read from Modules.
That's probably no probably no problem for plugins like POSIXProcess and
derived since those have everything mapped in memory, and can read it
anyway.

Today I won't pursue it any more, since it is past my bedtime already, but
I'll tinker with that bit more probably during weekend.

Thanks,
/Piotr

2014-02-20 0:16 GMT+01:00 Todd Fiala <tfiala at google.com>:

> [Moving LLVM to BCC and adding lldb-dev]
>
> Hi Piotr!
>
> Thanks for the note.
>
> On Wed, Feb 19, 2014 at 2:54 PM, Piotr Rak <piotr.rak at gmail.com> wrote:
>
>
>> But when we are requested to do read at boundary of two such not merged
>> VMRanges, we will read correct data from from file to the end of
>> 'last_entry->data.GetRangeEnd()' and then we fill rest with '\0'.
>> I think that we should split our requested read operation, to all such
>> ranges in this case.
>>
>> Is that correct?
>>
>>
> For the elf core file support, each of those memory regions represent a
> memory segment of the elf file.  I don't *think* you should be having any
> memory objects which span across segments.  So while it might be true that
> a request for a contiguous range of VM memory starts off in one segment's
> VM map entry and might zero fill if it would cover multiple segments that
> were not merged, I'm not sure what would be driving the need to do that.
>
> What is the scenario where the need to read memory over multiple segments
> is showing up?
>
> If we did need to do it, I think you are right in that we'd need to merge
> reads from each of the VM regions that overlapped with the read request.
>
> Let me know what you find!
>
> Thanks,
> Todd
> --
> Todd Fiala |  Software Engineer | tfiala at google.com |  650-943-3180
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20140220/92485a48/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: main.cc
Type: text/x-c++src
Size: 384 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20140220/92485a48/attachment.cc>