Thread: Re: function lca('{}'::ltree[]) caused DB Instance crash

On Friday, July 13, 2018 12:09:20 PM CEST 李海龙 wrote:
> HI,Oleg && pgsql-hackers
>
> Plese help me to check this is a bug of ltree?
>

Hi

There is indeed a bug. The _lca function in _ltree_op.c tries to allocate 0
bytes of memory, doesn't initialize it and dereference it in lca_inner.
The attached basic patch fixes it.

Regards

 Pierre

Pierre Ducroquet <p.psql@pinaraf.info> writes:
> On Friday, July 13, 2018 12:09:20 PM CEST 李海龙 wrote:
>> contrib_regression=# select lca('{}'::ltree[]);
>> server closed the connection unexpectedly

> There is indeed a bug. The _lca function in _ltree_op.c tries to allocate 0 
> bytes of memory, doesn't initialize it and dereference it in lca_inner.
> The attached basic patch fixes it.

I think the defense ought to be in lca_inner not there.

However, I don't understand why this code is returning NULL, rather than
a zero-length ltree, in the case that there's no common prefix.  That
doesn't seem consistent to me.

            regards, tom lane

I wrote:
> However, I don't understand why this code is returning NULL, rather than
> a zero-length ltree, in the case that there's no common prefix.  That
> doesn't seem consistent to me.

After looking more closely, I see that what lca() returns is the longest
common *ancestor* of the input paths, not the longest common *prefix*
... at least, by my understanding of what a prefix is.  If the longest
prefix is empty, then there's no common ancestor, so returning null in
that case isn't so insane after all.  However, the documentation seems
very misleading on this point.  I changed it around along with pushing
the crash fix.

I wonder whether there isn't a need for an lcp() that would return the
common prefix as that's usually understood.

            regards, tom lane