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.
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 |