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

[Pengfei Sun]

Hi Lex,

I have one question about tab switch in the geany. I know the different tab
has different doc->id. I think there is only one thread which manages all
tabs, right?  I wonder when we switch different tabs to edit the document.
How does geany manage or recognize different tabs? g_main_context_check
will be called in g_main_loop_run. Whether the data structure GMainContext
will include some information which can recognize the different tab?

Thank you very much!

Best Regards,
Pengfei

On Fri, Oct 16, 2015 at 3:14 PM, Pengfei Sun <shaotian330 at gmail.com> wrote:

> Thanks Lex.
>
> On Thu, Oct 15, 2015 at 5:33 PM, Lex Trotman <elextr at gmail.com> wrote:
>
>> On 16 October 2015 at 06:42, Pengfei Sun <shaotian330 at gmail.com> wrote:
>> > 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.
>>
>> Splitvector.h:94
>>
>> >
>> > 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
>> >
>> >
>> >
>> > _______________________________________________
>> > 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/20151023/7ec3a63c/attachment.html>