Re: gs_group_1 crashing on 13beta2/s390x - Mailing list pgsql-hackers

From Andres Freund
Subject Re: gs_group_1 crashing on 13beta2/s390x
Date
Msg-id 20201016001254.w2nfj7gd74jmb5in@alap3.anarazel.de
Whole thread Raw
In response to Re: gs_group_1 crashing on 13beta2/s390x  (Andres Freund <andres@anarazel.de>)
Responses Re: gs_group_1 crashing on 13beta2/s390x
List pgsql-hackers
Hi,

On 2020-10-15 15:37:01 -0700, Andres Freund wrote:
> On 2020-10-15 15:29:24 -0700, Andres Freund wrote:
> > Pushed now to 11-master.
> 
> Ugh - there's a failure with an old LLVM version (3.9):
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=dragonet&dt=2020-10-15%2022%3A24%3A04
> 
> Need to rebuild that locally to reproduce.

It's a bug that was fixed in LLVM 4, but too late to be backported to
3.9.

The easiest seems to be to just use a wrapper function that does the
necessary pre-checks. Something like the below (in llvmjit_wrap.cpp).

Since the wrapper still needs to call into
LLVMGetAttributeCountAtIndexPG, it seems easier to just use the seperate
function name, rather than #define'ing LLVMGetAttributeCountAtIndex() to
the PG version?

/*
 * Like LLVM's LLVMGetAttributeCountAtIndex(), works around a bug in LLVM 3.9.
 *
 * In LLVM <= 3.9, LLVMGetAttributeCountAtIndex() segfaults if there are no
 * attributes at an index (fixed in LLVM commit ce9bb1097dc2).
 */
unsigned
LLVMGetAttributeCountAtIndexPG(LLVMValueRef F, uint32 Idx)
{
    /*
     * This is more expensive, so only do when using a problematic LLVM
     * version.
     */
#if LLVM_VERSION_MAJOR < 4
    if (!llvm::unwrap<llvm::Function>(F)->getAttributes().hasAttributes(Idx))
        return 0;
#endif

    /*
     * There is no nice public API to determine the count nicely, so just
     * always fall back to LLVM's C API.
     */
    return LLVMGetAttributeCountAtIndex(F, Idx);
}


Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Some remaining htonl() and ntohl() calls in the code
Next
From: Andres Freund
Date:
Subject: Re: pg_upgrade: fail early if a tablespace dir already exists for new cluster version