Thread: Write past chunk end?

Write past chunk end?

From
"Magnus Hagander"
Date:
I'm testing out the latest version of Palles ICU patch on win32, and I
got the build syste mworking. But it no longer works when built - it
used to...

When initdb:ing with this version and -E UNICODE, I get:
WARNING: detected write past chunk end in Analyze Column 01472ED0


Any ideas on how to debug this?

(The net result is that it sorts things in the wrong order, so things
are clearly broken..)

//Magnus


Re: Write past chunk end?

From
Alvaro Herrera
Date:
On Thu, Jul 28, 2005 at 07:51:02PM +0200, Magnus Hagander wrote:
> I'm testing out the latest version of Palles ICU patch on win32, and I
> got the build syste mworking. But it no longer works when built - it
> used to...
> 
> When initdb:ing with this version and -E UNICODE, I get:
> WARNING: detected write past chunk end in Analyze Column 01472ED0

Search for a AllocSetContextCreate whose name is "Analyze Column";
somebody is writing more memory than allocated.

> Any ideas on how to debug this?

The problem is that it's detected in MemoryContextCheck, long after the
clobber occured.  You could set a watchpoint in gdb, I think.

-- 
Alvaro Herrera (<alvherre[a]alvh.no-ip.org>)
"Investigación es lo que hago cuando no sé lo que estoy haciendo"
(Wernher von Braun)


Re: Write past chunk end?

From
"Magnus Hagander"
Date:
> > I'm testing out the latest version of Palles ICU patch on
> win32, and I
> > got the build syste mworking. But it no longer works when
> built - it
> > used to...
> >
> > When initdb:ing with this version and -E UNICODE, I get:
> > WARNING: detected write past chunk end in Analyze Column 01472ED0
>
> Search for a AllocSetContextCreate whose name is "Analyze
> Column"; somebody is writing more memory than allocated.
>
> > Any ideas on how to debug this?
>
> The problem is that it's detected in MemoryContextCheck, long
> after the clobber occured.  You could set a watchpoint in
> gdb, I think.

That's what I was afraid of. Well, some shotgun-debugging later, I found
the problem. A "+1" that should be "+2" because UTF-16 is two-byte... As
the data is freed very soon afterwards this didn't cause a crash, but I
bet it would've given the same warning if it was run on FreeBSD with
debugging and asserts enabled.

Anyway. Thanks, got it sorted.

//Magnus