linux_pslist don't generate any output

[GoogleCodeExporter]

What steps will reproduce the problem?
1. vol.py -v --profile=LinuxAndroidARM -f RAMDUMP0000 linux_pslist

What is the expected output?

...
[    1]     0     1       78       18   0       0 init                          
[   57]     0    57       74       14   0       0 ueventd                       
[   62]     0    62      857       16   0       0 adbd                          
[   63]     0    63      667       42   0       0 sh                            
...

What do you see instead?

Olny header

What version of the product are you using? On what operating system?

vol-2.3.1
python-2.7.3
ubuntu-12.04

Please provide any additional information below.

TRACE32 extract list of process without any issue. Other plugins also give void 
output

output with -dd key is attached

Original issue reported on code.google.com by vitaly.v...@gmail.com on 15 Nov 2013 at 4:30

Attachments:

• Android.zip
• ps.log

[GoogleCodeExporter]

Original comment by jamie.l...@gmail.com on 18 Nov 2013 at 1:39

[GoogleCodeExporter]

Hello,

What tool did you acquire memory with?

Original comment by atc...@gmail.com on 18 Nov 2013 at 11:27

[GoogleCodeExporter]

Something like jtag debugger. 

Original comment by vitaly.v...@gmail.com on 19 Nov 2013 at 8:23

[GoogleCodeExporter]

Hello,

Would it be possible to send the memory sample you acquired or is it senstive? 
I can give you credentials to a private FTP server only used by the developers, 
it would not be made public.

Original comment by atc...@gmail.com on 25 Nov 2013 at 6:34

[GoogleCodeExporter]

It's under strict NDA. So all what I can - try patches from you and send debug 
logs back.

Original comment by vitaly.v...@gmail.com on 26 Nov 2013 at 8:14

[GoogleCodeExporter]

Andrew, can you provide an update on this issue? Are there some patches you can 
send Vitaly to help debug?

Original comment by michael.hale@gmail.com on 7 Mar 2014 at 5:23

[GoogleCodeExporter]

Hello Vitaly,

Do you know if there is public documentation of how the jtag interface is 
acquiring RAM? I read about trace32 and it seems to run against live systems. 
From looking at the output of -dd it shows that the ARM profile is selected, 
but then pslist falls apart. This means that the initial (static) translation 
is correct, but the dynamic ones are not. 

I have a feeling the memory dump is in a format that does not pad output so 
that the offsets retrieved from address tralsnation are wrong. On the live 
system could you run 'cat /proc/iomem' and paste the output here (or email to 
me if its sensitive)? This will help me figure out how RAM is laid out in 
physical memory. 

Original comment by atc...@gmail.com on 9 Mar 2014 at 10:39

[GoogleCodeExporter]

Hello

I will do it some time late

Original comment by vitaly.v...@gmail.com on 11 Mar 2014 at 9:35

[GoogleCodeExporter]

Hi Vitaly, 

You can get Andrew's email from the tracker (its just atcuno [at] gmail.com) 
and mine is michael [dot] hale @ gmail.com. Feel free to shoot us an email when 
you get a chance to run cat /proc/iomem and we can help you troubleshoot 
through the issue. I'll close the issue here, because it sounds like some info 
shouldn't be discussed publicly. Thanks!

Original comment by michael.hale@gmail.com on 13 Mar 2014 at 3:48

• Changed state: Done