Hey Edwin, 

Hmm, yes, if you don't mind...there is one more thing. Could you type "make clean" in the directory where vol.py exists and then re-run the plugin? This will make sure all possibly stale .pyc (compiled python objects) are removed. We basically hard-coded the vm start and end fields to be unsigned, so its really strange if they're still showing up negative. Also, could you paste just the first few lines of the linux_proc_maps output, something else may give us a clue if we see it. 

Thanks again,
Michael


On Tue, Apr 2, 2013 at 3:38 AM, Edwin Smulders <edwin.smulders@gmail.com> wrote:
Finally, it's tuesday morning, I can test your solution.

Sadly, it's still giving me the same output (revision 3263).

Is there anything else I can do to help you find a solution?

Cheers,
Edwin

On 2 April 2013 04:37, Michael Hale Ligh <michael.hale@gmail.com> wrote:
> Hey Edwin,
>
> Hope you had a nice weekend! Just wanted to check and see if you had a
> chance to determine if the linux_proc_maps plugin is printing output in a
> more accurate way now?
>
> Thanks!
> Michael
>
>
> On Fri, Mar 29, 2013 at 8:13 PM, Michael Hale Ligh <michael.hale@gmail.com>
> wrote:
>>
>> Hi Edwin,
>>
>> Could you please svn update to revision 3220 or later and re-test the
>> linux_proc_maps plugin?
>>
>> Thanks,
>> Michael
>>
>>
>> On Fri, Mar 29, 2013 at 11:19 AM, Edwin Smulders
>> <edwin.smulders@gmail.com> wrote:
>>>
>>> Correct URL: http://packages.ubuntu.com/precise/dwarfdump
>>>
>>> On 29 March 2013 16:18, Edwin Smulders <edwin.smulders@gmail.com> wrote:
>>> > On 29 March 2013 15:25, Michael Hale Ligh <michael.hale@gmail.com>
>>> > wrote:
>>> >> While we look into that, could you
>>> >> tell me what version of dwarfdump you have installed?
>>> >
>>> > I would love to tell you, but I had to go home early and due to easter
>>> > I can tell you on tuesday morning what the exact version is.
>>> > However, it was a fresh install of ubuntu 12.04 and as far as I can
>>> > tell there have been no updates to the package since december, so it
>>> > must be this version:
>>> > http://packages.ubuntu.com/precise/libdwarf-dev
>>> >
>>> >> On Fri, Mar 29, 2013 at 6:11 AM, Edwin Smulders
>>> >> <edwin.smulders@gmail.com>
>>> >> wrote:
>>> >>>
>>> >>> (Sending this a second time, first time i forgot to include the
>>> >>> mailing-list)
>>> >>> Here's the struct:
>>> >>> http://paste.ubuntu.com/5657610/
>>> >>> I did not realise the first time that I could simply dt it like that.
>>> >>>
>>> >>> I've attached the profile, if it's not too big.
>>> >>>
>>> >>> Cheers,
>>> >>> Edwin
>>> >>>
>>> >>> On 28 March 2013 18:49, Michael Hale Ligh <michael.hale@gmail.com>
>>> >>> wrote:
>>> >>> > Hey Edwin,
>>> >>> >
>>> >>> > On second thought, if you could send your profile
>>> >>> > (LinuxUbuntu-12_04-3_5_0-25x86.zip), that would be even better.
>>> >>> >
>>> >>> > Thanks!
>>> >>> > Michael
>>> >>> >
>>> >>> >
>>> >>> > On Thu, Mar 28, 2013 at 1:04 PM, Michael Hale Ligh
>>> >>> > <michael.hale@gmail.com>
>>> >>> > wrote:
>>> >>> >>
>>> >>> >> Hey Edwin,
>>> >>> >>
>>> >>> >> Sorry for the delay and thanks for the additional output. Could
>>> >>> >> you run
>>> >>> >> one more thing, please? Instead of doing dt('mm_struct', address)
>>> >>> >> could
>>> >>> >> you
>>> >>> >> just do dt('mm_struct'). That will show the actual types rather
>>> >>> >> than
>>> >>> >> the
>>> >>> >> values of a specific structure. For example:
>>> >>> >>
>>> >>> >> >>> dt('mm_struct')
>>> >>> >> 'mm_struct' (436 bytes)
>>> >>> >> 0x0   : mmap                           ['pointer',
>>> >>> >> ['vm_area_struct']]
>>> >>> >> 0x4   : mm_rb                          ['rb_root']
>>> >>> >> 0x8   : mmap_cache                     ['pointer',
>>> >>> >> ['vm_area_struct']]
>>> >>> >> 0xc   : get_unmapped_area              ['pointer', ['void']]
>>> >>> >> 0x10  : get_unmapped_exec_area         ['pointer', ['void']]
>>> >>> >> 0x14  : unmap_area                     ['pointer', ['void']]
>>> >>> >> 0x18  : mmap_base                      ['unsigned long']
>>> >>> >> 0x1c  : task_size                      ['unsigned long']
>>> >>> >> .....
>>> >>> >>
>>> >>> >> Can you paste the output of that command?
>>> >>> >>
>>> >>> >> Thanks for your patience,
>>> >>> >> Michael
>>> >>> >>
>>> >>> >>
>>> >>> >> On Thu, Mar 21, 2013 at 10:12 AM, Edwin Smulders
>>> >>> >> <edwin.smulders@gmail.com> wrote:
>>> >>> >>>
>>> >>> >>> Yes, also it seems that I was wrong about start_brk/brk, so i
>>> >>> >>> guess
>>> >>> >>> they just overflowed.
>>> >>> >>> http://paste.ubuntu.com/5634126/
>>> >>> >>>
>>> >>> >>> On 21 March 2013 14:44, Michael Ligh <michael.hale@gmail.com>
>>> >>> >>> wrote:
>>> >>> >>> > Hey Edwin,
>>> >>> >>> >
>>> >>> >>> > Can you use linux_volshell and dt() the task.mm struct? Do
>>> >>> >>> > start_stack
>>> >>> >>> > and arg_start show up as unsigned?
>>> >>> >>> >
>>> >>> >>> > MHL
>>> >>> >>> >
>>> >>> >>> > Sent from my iPhone
>>> >>> >>> >
>>> >>> >>> > On Mar 21, 2013, at 7:29 AM, Edwin Smulders
>>> >>> >>> > <edwin.smulders@gmail.com>
>>> >>> >>> > wrote:
>>> >>> >>> >
>>> >>> >>> >> I'd like to expand a bit more on this issue. I don't think
>>> >>> >>> >> it's
>>> >>> >>> >> just a
>>> >>> >>> >> formatting issue, now that I'm actually using this to develop
>>> >>> >>> >> my
>>> >>> >>> >> own
>>> >>> >>> >> plugin I noticed that the values I get from the
>>> >>> >>> >> task.mm.start_stack,
>>> >>> >>> >> task.mm.arg_start and several other values are actually
>>> >>> >>> >> negative
>>> >>> >>> >> numbers. task.mm.start_brk/task.mm.brk seem to be ok, not sure
>>> >>> >>> >> why.
>>> >>> >>> >>
>>> >>> >>> >> On 4 March 2013 10:02, Edwin Smulders
>>> >>> >>> >> <edwin.smulders@gmail.com>
>>> >>> >>> >> wrote:
>>> >>> >>> >>> Here's /proc/1264/maps
>>> >>> >>> >>>
>>> >>> >>> >>> http://paste.ubuntu.com/5584610/
>>> >>> >>> >>>
>>> >>> >>> >>> On 1 March 2013 18:01, Edwin Smulders
>>> >>> >>> >>> <edwin.smulders@gmail.com>
>>> >>> >>> >>> wrote:
>>> >>> >>> >>>> Thanks for the quick response.
>>> >>> >>> >>>> Sadly, I can't access my VMs at home, so I'll send the
>>> >>> >>> >>>> /proc/<pid>/maps first thing in the morning on monday.
>>> >>> >>> >>>>
>>> >>> >>> >>>> Cheers,
>>> >>> >>> >>>> Edwin
>>> >>> >>> >>>>
>>> >>> >>> >>>> On 1 March 2013 17:29, Michael Hale Ligh
>>> >>> >>> >>>> <michael.hale@gmail.com>
>>> >>> >>> >>>> wrote:
>>> >>> >>> >>>>> Ah, this has to do with the fact that a long and unsigned
>>> >>> >>> >>>>> long
>>> >>> >>> >>>>> on
>>> >>> >>> >>>>> x86 Linux
>>> >>> >>> >>>>> is actually 8 bytes (instead of 4 like on Windows).
>>> >>> >>> >>>>>
>>> >>> >>> >>>>> We'll take a look at changing the formatting specification
>>> >>> >>> >>>>> to
>>> >>> >>> >>>>> account for
>>> >>> >>> >>>>> this difference in sizes, and if it can't be done easily
>>> >>> >>> >>>>> before
>>> >>> >>> >>>>> the
>>> >>> >>> >>>>> 2.3
>>> >>> >>> >>>>> release, then we'll revert the patch in r3090 to
>>> >>> >>> >>>>> re-incorporate
>>> >>> >>> >>>>> mask_number.
>>> >>> >>> >>>>>
>>> >>> >>> >>>>> Please still send the output of /proc/<pid>/maps just so we
>>> >>> >>> >>>>> know
>>> >>> >>> >>>>> how it
>>> >>> >>> >>>>> looks for the future.
>>> >>> >>> >>>>> MHL
>>> >>> >>> >>>>>
>>> >>> >>> >>>>>
>>> >>> >>> >>>>> On Fri, Mar 1, 2013 at 10:53 AM, Michael Hale Ligh
>>> >>> >>> >>>>> <michael.hale@gmail.com>
>>> >>> >>> >>>>> wrote:
>>> >>> >>> >>>>>>
>>> >>> >>> >>>>>> Thanks for reporting. We just recently removed the
>>> >>> >>> >>>>>> mask_number
>>> >>> >>> >>>>>> function
>>> >>> >>> >>>>>> (http://code.google.com/p/volatility/source/detail?r=3090)
>>> >>> >>> >>>>>> because
>>> >>> >>> >>>>>> vm_start
>>> >>> >>> >>>>>> and vm_end are already unsigned (so you shouldn't see
>>> >>> >>> >>>>>> negative
>>> >>> >>> >>>>>> numbers in
>>> >>> >>> >>>>>> output).
>>> >>> >>> >>>>>>
>>> >>> >>> >>>>>> I'm guessing this may be a problem with our output
>>> >>> >>> >>>>>> formatting,
>>> >>> >>> >>>>>> but
>>> >>> >>> >>>>>> we'll
>>> >>> >>> >>>>>> look into it (the output of /proc/<pid>/maps like Andrew
>>> >>> >>> >>>>>> asked
>>> >>> >>> >>>>>> for
>>> >>> >>> >>>>>> would be
>>> >>> >>> >>>>>> useful).
>>> >>> >>> >>>>>>
>>> >>> >>> >>>>>>
>>> >>> >>> >>>>>> On Fri, Mar 1, 2013 at 10:47 AM, Andrew Case
>>> >>> >>> >>>>>> <atcuno@gmail.com>
>>> >>> >>> >>>>>> wrote:
>>> >>> >>> >>>>>>>
>>> >>> >>> >>>>>>> Can you send the output of /proc/<pid>/maps that
>>> >>> >>> >>>>>>> corresponds
>>> >>> >>> >>>>>>> to
>>> >>> >>> >>>>>>> one of
>>> >>> >>> >>>>>>> the processes with the broken plugin output?
>>> >>> >>> >>>>>>>
>>> >>> >>> >>>>>>> On Fri, Mar 1, 2013 at 6:52 AM, Edwin Smulders
>>> >>> >>> >>>>>>> <edwin.smulders@gmail.com>
>>> >>> >>> >>>>>>> wrote:
>>> >>> >>> >>>>>>>> Hi all,
>>> >>> >>> >>>>>>>>
>>> >>> >>> >>>>>>>> I've just created a profile for my Ubuntu 12.04
>>> >>> >>> >>>>>>>> (3.5.0-25)
>>> >>> >>> >>>>>>>> and
>>> >>> >>> >>>>>>>> I've
>>> >>> >>> >>>>>>>> dumped the memory using virtualbox guestcoredump.
>>> >>> >>> >>>>>>>> Using the linux_proc_maps plugin I get the following
>>> >>> >>> >>>>>>>> output:
>>> >>> >>> >>>>>>>>
>>> >>> >>> >>>>>>>> http://paste.ubuntu.com/5576450/
>>> >>> >>> >>>>>>>>
>>> >>> >>> >>>>>>>> I was expecting similar output to "cat
>>> >>> >>> >>>>>>>> /proc/<pid>/maps". As
>>> >>> >>> >>>>>>>> you
>>> >>> >>> >>>>>>>> can
>>> >>> >>> >>>>>>>> see, these "-0x4...000" addresses are obviously wrong.
>>> >>> >>> >>>>>>>> Is
>>> >>> >>> >>>>>>>> this I
>>> >>> >>> >>>>>>>> am
>>> >>> >>> >>>>>>>> doing wrong myself, or is this a bug? It happens for
>>> >>> >>> >>>>>>>> other
>>> >>> >>> >>>>>>>> processes
>>> >>> >>> >>>>>>>> as well.
>>> >>> >>> >>>>>>>>
>>> >>> >>> >>>>>>>> If this is a bug I'll make a new issue in the tracker
>>> >>> >>> >>>>>>>> with
>>> >>> >>> >>>>>>>> the
>>> >>> >>> >>>>>>>> steps
>>> >>> >>> >>>>>>>> I've followed to produce this.
>>> >>> >>> >>>>>>>>
>>> >>> >>> >>>>>>>> Cheers,
>>> >>> >>> >>>>>>>> Edwin
>>> >>> >>> >>>>>>>> _______________________________________________
>>> >>> >>> >>>>>>>> Vol-users mailing list
>>> >>> >>> >>>>>>>> Vol-users@volatilityfoundation.org
>>> >>> >>> >>>>>>>>
>>> >>> >>> >>>>>>>> http://lists.volatilityfoundation.org/mailman/listinfo/vol-users
>>> >>> >>> >>>>>>> _______________________________________________
>>> >>> >>> >>>>>>> Vol-users mailing list
>>> >>> >>> >>>>>>> Vol-users@volatilityfoundation.org
>>> >>> >>> >>>>>>>
>>> >>> >>> >>>>>>> http://lists.volatilityfoundation.org/mailman/listinfo/vol-users
>>> >>> >>> >>>>>
>>> >>> >>
>>> >>> >>
>>> >>> >
>>> >>
>>> >>
>>
>>
>