[Geany-Devel] About Malloc memory for each tab?

[Pengfei Sun]

Hi Lex,

I checked again the gap buffer and heap memory dump. I made mistakes last
time. scintilla_send_message returned the virtual address which was the
address of text in the heap. However, I also found parts of text (each
line) which locate in different address in the heap. So I made the mistake.

I still have one question about memory allocation of geany. When you type
some text in the one window of geany, which function is responsible for
allocating the memory space in the heap? g_new, g_new0, g_malloc,
g_slice_alloc??  I remembered you mentioned that "The buffer itself is
allocated by Scintilla which means its allocated by C++ new". But I don't
find the exact location in the source code of geany.

Thank you very much!

Best Regards,
Pengfei

On Wed, Oct 14, 2015 at 5:13 AM, Lex Trotman <elextr at gmail.com> wrote:

> On 13 October 2015 at 04:43, Pengfei Sun <shaotian330 at gmail.com> wrote:
> > Hi Lex,
> >
> > Thanks for you hint about scintilla. Matthew also mentioned to use the
> > scintilla. I tried his patch, but there is still one problem about the
> > address of buffer. I don't know why the address of output is not
> consistent
> > with address of buffer in the dumped heap memory?
>
> The Scintilla buffer is a gap buffer, its contents are moved depending
> on user actions, and depending on what else Geany is doing it can copy
> all or parts of the buffer to C memory.  So your string can appear in
> lots of places in memory, C heap, C++ heap (which may or may not be
> the same as the C heap) not just in the buffer.
>
> Cheers
> Lex
>
> >
> > Best Regards,
> > Pengfei
> >
> > On Fri, Oct 9, 2015 at 7:12 PM, Lex Trotman <elextr at gmail.com> wrote:
> >>
> >> On 10 October 2015 at 08:42, Pengfei Sun <shaotian330 at gmail.com> wrote:
> >> > Hi Lex,
> >> >
> >> > Thanks for your suggestions.
> >> >
> >> > I work on memory forensics. My part of project is to locate memory of
> >> > the
> >> > sensitive data. For example, when I use the geany open one sensitive
> >> > file,
> >> > and the content will be in the memory (heap). I hope I can locate all
> >> > memory
> >> > related this sensitive file. And later I can do some analysis or
> >> > protection.
> >> >
> >>
> >> The buffer itself is allocated by Scintilla which means its allocated
> >> by C++ new.
> >>
> >> > Now, I override malloc and can log all malloc functions to get return
> >> > address and size (I think g_malloc is a wrapper of malloc). But I
> still
> >> > cannot building the mapping between the special file and related heap
> >> > memory. I know each open or created file have different ID
> >> > (GeanyDocument->id). However, I still cannot figure out how to trace
> the
> >> > related memory of different ID. Assume I have open three files, so
> there
> >> > are
> >> > three windows and three different GeanyDocument->id. I write or change
> >> > some
> >> > things among these three windows. Meanwhile, I log all
> >> > malloc/realloc/calloc
> >> > functions. I try to figure out which malloc belong to window 1, which
> >> > belong
> >> > to window2 or window 3?  Do you have any further suggestions for my
> >> > case?
> >> >
> >>
> >> Use only one window :)
> >>
> >> > Thank you very much.
> >> >
> >> > Best Regards,
> >> > Pengfei
> >> >
> >> > On Fri, Oct 9, 2015 at 5:45 PM, Lex Trotman <elextr at gmail.com> wrote:
> >> >>
> >> >> On 10 October 2015 at 05:05, Pengfei Sun <shaotian330 at gmail.com>
> wrote:
> >> >> > Dear All,
> >> >> >
> >> >> > I am always using geany, but now this is the first time I prepare
> to
> >> >> > look at
> >> >> > geany source code. I have one question about memory allocation.
> When
> >> >> > we
> >> >> > open
> >> >> > one new file, there will be one new window in geany. How could I
> >> >> > track
> >> >> > all
> >> >> > memory allocation(g_malloc) related with this window? Or would it
> be
> >> >> > possible to track all related functions with this window?
> >> >>
> >> >> The only way to track all allocations is to track Glib/GTK operations
> >> >> (some of these functions use Gslice, which does its own allocations
> >> >> from large blocks and may not show on malloc, or will show allocating
> >> >> the large block not all of which is for the one window).
> >> >>
> >> >> Also track g_malloc that Geany uses, though you can force that to
> >> >> always malloc I think.
> >> >>
> >> >> Also track malloc in case some libraries use it.
> >> >>
> >> >> And to track C++ new as used by the editing component (which again
> >> >> need not use malloc).
> >> >>
> >> >> One question is why do you want to do this,what are you trying to
> >> >> achieve? There might be a better way.
> >> >>
> >> >> Geany is mostly event driven (though a few things are timer driven)
> so
> >> >> if you only perform actions on one window most code run will relate
> to
> >> >> that window.
> >> >>
> >> >> Cheers
> >> >> Lex
> >> >>
> >> >> >
> >> >> > Thank you very much!
> >> >> >
> >> >> > Best Regards,
> >> >> > Pengfei
> >> >> >
> >> >> >
> >> >> > _______________________________________________
> >> >> > Devel mailing list
> >> >> > Devel at lists.geany.org
> >> >> > https://lists.geany.org/cgi-bin/mailman/listinfo/devel
> >> >> >
> >> >> _______________________________________________
> >> >> Devel mailing list
> >> >> Devel at lists.geany.org
> >> >> https://lists.geany.org/cgi-bin/mailman/listinfo/devel
> >> >
> >> >
> >> >
> >> > _______________________________________________
> >> > Devel mailing list
> >> > Devel at lists.geany.org
> >> > https://lists.geany.org/cgi-bin/mailman/listinfo/devel
> >> >
> >> _______________________________________________
> >> Devel mailing list
> >> Devel at lists.geany.org
> >> https://lists.geany.org/cgi-bin/mailman/listinfo/devel
> >
> >
> >
> > _______________________________________________
> > Devel mailing list
> > Devel at lists.geany.org
> > https://lists.geany.org/cgi-bin/mailman/listinfo/devel
> >
> _______________________________________________
> Devel mailing list
> Devel at lists.geany.org
> https://lists.geany.org/cgi-bin/mailman/listinfo/devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.geany.org/pipermail/devel/attachments/20151015/1a72a24b/attachment.html>