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 <shaotian...@gmail.com> wrote: > Thanks Lex. > > On Thu, Oct 15, 2015 at 5:33 PM, Lex Trotman <ele...@gmail.com> wrote: > >> On 16 October 2015 at 06:42, Pengfei Sun <shaotian...@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 <ele...@gmail.com> wrote: >> >> >> >> On 13 October 2015 at 04:43, Pengfei Sun <shaotian...@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 <ele...@gmail.com> >> wrote: >> >> >> >> >> >> On 10 October 2015 at 08:42, Pengfei Sun <shaotian...@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 <ele...@gmail.com> >> wrote: >> >> >> >> >> >> >> >> On 10 October 2015 at 05:05, Pengfei Sun <shaotian...@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@lists.geany.org >> >> >> >> > https://lists.geany.org/cgi-bin/mailman/listinfo/devel >> >> >> >> > >> >> >> >> _______________________________________________ >> >> >> >> Devel mailing list >> >> >> >> Devel@lists.geany.org >> >> >> >> https://lists.geany.org/cgi-bin/mailman/listinfo/devel >> >> >> > >> >> >> > >> >> >> > >> >> >> > _______________________________________________ >> >> >> > Devel mailing list >> >> >> > Devel@lists.geany.org >> >> >> > https://lists.geany.org/cgi-bin/mailman/listinfo/devel >> >> >> > >> >> >> _______________________________________________ >> >> >> Devel mailing list >> >> >> Devel@lists.geany.org >> >> >> https://lists.geany.org/cgi-bin/mailman/listinfo/devel >> >> > >> >> > >> >> > >> >> > _______________________________________________ >> >> > Devel mailing list >> >> > Devel@lists.geany.org >> >> > https://lists.geany.org/cgi-bin/mailman/listinfo/devel >> >> > >> >> _______________________________________________ >> >> Devel mailing list >> >> Devel@lists.geany.org >> >> https://lists.geany.org/cgi-bin/mailman/listinfo/devel >> > >> > >> > >> > _______________________________________________ >> > Devel mailing list >> > Devel@lists.geany.org >> > https://lists.geany.org/cgi-bin/mailman/listinfo/devel >> > >> _______________________________________________ >> Devel mailing list >> Devel@lists.geany.org >> https://lists.geany.org/cgi-bin/mailman/listinfo/devel >> > >
_______________________________________________ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel