[google] Separating ChangeLogs from different branches

2011-02-04 Thread Diego Novillo
While doing the integration->main merge today, I realized that I misnamed the ChangeLog.google files. If both branches name them the same, merges will be ugly and we won't be able to tell them apart easily. I renamed all the existing ChangeLog.google to ChangeLog.google-integration. We'll have a

Re: hints on debugging memory corruption...

2011-02-04 Thread Joern Rennecke
Quoting Tom Tromey : "Basile" == Basile Starynkevitch writes: Basile> So I need to understand who is writing the 0x101 in that field. One thing to watch out for is that the memory can be recycled. I've been very confused whenever I've forgotten this. I have a hack for the GC (appended -

Re: hints on debugging memory corruption...

2011-02-04 Thread Tom Tromey
> "Basile" == Basile Starynkevitch writes: Basile> So I need to understand who is writing the 0x101 in that field. valgrind can sometimes catch this, assuming that the write is an invalid one. Basile> An obvious strategy is to use the hardware watchpoint feature of GDB. Basile> However, one

[google] Merged google/integration into google/main

2011-02-04 Thread Diego Novillo
This merge brings all the integration patches. I've also created a ChangeLog.google-main to separate the changes from both branches. Tested on x86_64. Diego.

Re: hints on debugging memory corruption...

2011-02-04 Thread Laurynas Biveinis
2011/2/4 Basile Starynkevitch : > An obvious strategy is to use the hardware watchpoint feature of GDB. > However, one cannot nicely put a watchpoint on an address which is not > mmap-ed yet. Actually, you can do this with a recent enough GDB (7.1 AFAIK). It will keep watchpoint disabled until the

Re: hints on debugging memory corruption...

2011-02-04 Thread Joern Rennecke
Quoting Basile Starynkevitch : Hello All (Sorry for such a basic question; very probably there are some GDB tricks that I ignore). In my MELT branch I have now some corrputed memory (maybe because I am inserting a pass at the wrong place in the pass tree). At some point, I call bb_debug, and i

Re: hints on debugging memory corruption...

2011-02-04 Thread Ian Lance Taylor
Basile Starynkevitch writes: > In my MELT branch I have now some corrputed memory (maybe because I am > inserting a pass at the wrong place in the pass tree). At some point, I call > bb_debug, and it crashes because the field bb_next contains 0x101 (which is > not a valid adress). > > So I need t

Re: hints on debugging memory corruption...

2011-02-04 Thread Richard Henderson
On 02/04/2011 07:42 AM, Basile Starynkevitch wrote: > An obvious strategy is to use the hardware watchpoint feature of GDB. > However, one cannot nicely put a watchpoint on an address which is not > mmap-ed yet. I typically find the location at which the object containing the address is allocated.

hints on debugging memory corruption...

2011-02-04 Thread Basile Starynkevitch
Hello All (Sorry for such a basic question; very probably there are some GDB tricks that I ignore). In my MELT branch I have now some corrputed memory (maybe because I am inserting a pass at the wrong place in the pass tree). At some point, I call bb_debug, and it crashes because the field bb_nex