Interesting....

I think I'll build my own VM to match your specs so I can do more debugging. You're using Ubuntu 12.04 x86 desktop? Do you think the following link is what most closely resembles your base build? 

http://releases.ubuntu.com/12.04.2/ubuntu-12.04.2-desktop-i386.iso

Thanks!
Michael


On Tue, Apr 2, 2013 at 7:31 AM, Edwin Smulders <edwin.smulders@gmail.com> wrote:
This is the actual /proc/pid/maps of the process I just tested

http://paste.ubuntu.com/5670138/

On 2 April 2013 13:26, Edwin Smulders <edwin.smulders@gmail.com> wrote:
> http://paste.ubuntu.com/5670124/
>
> Change is improvement, I guess :)
>
> On 2 April 2013 13:25, Michael Hale Ligh <michael.hale@gmail.com> wrote:
>> Hey Edwin,
>>
>> OK, update to r3264 and I will keep my fingers crossed that this solves the
>> issue.
>>
>> Thanks for the quick reply!
>> Michael
>>
>>
>> On Tue, Apr 2, 2013 at 7:17 AM, Edwin Smulders <edwin.smulders@gmail.com>
>> wrote:
>>>
>>> http://paste.ubuntu.com/5670109/
>>>
>>> Cheers,
>>> Edwin
>>>
>>> On 2 April 2013 13:12, Michael Hale Ligh <michael.hale@gmail.com> wrote:
>>> > 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@volatilesystems.com
>>> >> >>> >>> >>> >>>>>>>
>>> >> >>> >>> >>> >>>>>>>
>>> >> >>> >>> >>> >>>>>>>
>>> >> >>> >>> >>> >>>>>>> http://lists.volatilityfoundation.org/mailman/listinfo/vol-users
>>> >> >>> >>> >>> >>>>>
>>> >> >>> >>> >>
>>> >> >>> >>> >>
>>> >> >>> >>> >
>>> >> >>> >>
>>> >> >>> >>
>>> >> >>
>>> >> >>
>>> >> >
>>> >
>>> >
>>
>>