Re: failing to build preproc.c on solaris with sun studio

From: Noah Misch <noah(at)leadboat(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: failing to build preproc.c on solaris with sun studio
Date: 2022-08-06 23:09:24
Message-ID: 20220806230924.GA3981561@rfd.leadboat.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Aug 06, 2022 at 02:07:24PM -0700, Andres Freund wrote:
> I tried PG on the gcc compile farm solaris 11.31 host. When compiling with sun
> studio I can build the backend etc, but preproc.c fails to compile:
>
> ccache /opt/developerstudio12.6/bin/cc -m64 -Xa -g -v -O0 -D_POSIX_PTHREAD_SEMANTICS -mt -D_REENTRANT -D_THREAD_SAFE -I../include -I../../../../src/interfaces/ecpg/include -I. -I. -I../../../../src/interfaces/ecpg/ecpglib -I../../../../src/interfaces/libpq -I../../../../src/include -D_POSIX_PTHREAD_SEMANTICS -c -o preproc.o preproc.c
> Assertion failed: hmap_size (phdl->fb.map) == 0, file ../src/line_num_internal.c, line 230, function twolist_proc_clear
> Assertion failed: hmap_size (phdl->fb.map) == 0, file ../src/line_num_internal.c, line 230, function twolist_proc_clear
> cc: Fatal error in /opt/developerstudio12.6/lib/compilers/bin/acomp
> cc: Status 134
>
> the assertion is just a consequence of running out of memory, I believe, acomp
> is well over 20GB at that point.
>
> However I see that wrasse doesn't seem to have that problem. Which leaves me a
> bit confused, because I think that's the same machine and compiler binary.
>
> Noah, did you encounter this before / do anything to avoid this?

Yes. Drop --enable-debug, and override TMPDIR to some disk-backed location.

From the earliest days of wrasse, the compiler used too much RAM to build
preproc.o with --enable-debug. As of 2021-04, the compiler's "acomp" phase
needed 10G in one process, and later phases needed 11.6G across two processes.
Compilation wrote 3.7G into TMPDIR. Since /tmp consumes RAM+swap, overriding
TMPDIR relieved 3.7G of RAM pressure. Even with those protections, wrasse
intermittently reaches the 14G limit I impose (via "ulimit -v 14680064"). I
had experimented with different optimization levels, but that didn't help.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2022-08-06 23:09:28 Re: Making autovacuum logs indicate if insert-based threshold was the triggering condition
Previous Message Tom Lane 2022-08-06 23:08:27 Re: Cleaning up historical portability baggage