Created attachment 589090 [details] Build log Build fails with the following errors: In member function 'void js::jit::X86Encoding::BaseAssemblerX64::movq_mr(int32_t, js::jit::X86Encoding::RegisterID, js::jit::X86Encoding::RegisterID, int, js::jit::X86Encoding::RegisterID)', inlined from 'void js::jit::Assembler::movq(const js::jit::Operand&, js::jit::Register)' at /var/tmp/portage/www-client/seamonkey-2.49.5/work/seamonkey-2.49.5/mozilla/js/src/jit/x64/Assembler-x64.h:397:25: /var/tmp/portage/www-client/seamonkey-2.49.5/work/seamonkey-2.49.5/mozilla/js/src/jit/x64/BaseAssembler-x64.h:596:13: error: '%s' directive argument is null [-Werror=format-overflow=] 596 | spew("movq " MEM_obs ", %s", ADDR_obs(offset, base, index, scale), GPReg64Name(dst)); $ emerge --info www-client/seamonkey Portage 2.3.75 (python 3.6.9-final-0, default/linux/amd64/17.1/desktop, gcc-9.2.0, glibc-2.29-r5, 5.2.11-gentoo x86_64) ================================================================= System Settings ================================================================= System uname: Linux-5.2.11-gentoo-x86_64-AMD_FX-tm-8350_Eight-Core_Processor-with-gentoo-2.6 KiB Mem: 16366536 total, 6512384 free KiB Swap: 1048572 total, 1048572 free Timestamp of repository gentoo: Thu, 05 Sep 2019 15:00:01 +0000 Head commit of repository gentoo: 655894f94f348402d11e21e42fb8654c8a291df4 sh bash 5.0_p11 ld GNU ld (Gentoo 2.32 p2) 2.32.0 app-shells/bash: 5.0_p11::gentoo dev-java/java-config: 2.2.0-r4::gentoo dev-lang/perl: 5.30.0::gentoo dev-lang/python: 2.7.16::gentoo, 3.6.9::gentoo dev-util/cmake: 3.15.3::gentoo sys-apps/baselayout: 2.6-r1::gentoo sys-apps/openrc: 0.42.1::gentoo sys-apps/sandbox: 2.18::gentoo sys-devel/autoconf: 2.13-r1::gentoo, 2.69-r4::gentoo sys-devel/automake: 1.16.1-r1::gentoo sys-devel/binutils: 2.32-r1::gentoo sys-devel/gcc: 9.2.0::gentoo sys-devel/gcc-config: 2.0::gentoo sys-devel/libtool: 2.4.6-r5::gentoo sys-devel/make: 4.2.1-r4::gentoo sys-kernel/linux-headers: 5.2::gentoo (virtual/os-headers) sys-libs/glibc: 2.29-r5::gentoo Repositories: gentoo location: /var/db/repos/gentoo sync-type: rsync sync-uri: rsync://rsync.gentoo.org/gentoo-portage priority: -1000 sync-rsync-extra-opts: sync-rsync-verify-metamanifest: yes sync-rsync-verify-jobs: 1 sync-rsync-verify-max-age: 24 ACCEPT_KEYWORDS="amd64 ~amd64" ACCEPT_LICENSE="*" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O2 -march=native -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/lib64/libreoffice/program/sofficerc /usr/share/gnupg/qualified.txt" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/dconf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo" CXXFLAGS="-O2 -march=native -pipe" DISTDIR="/var/cache/distfiles" EMERGE_DEFAULT_OPTS="--quiet-build --keep-going --jobs 9 --load-average 9" ENV_UNSET="DBUS_SESSION_BUS_ADDRESS DISPLAY GOBIN PERL5LIB PERL5OPT PERLPREFIX PERL_CORE PERL_MB_OPT PERL_MM_OPT XAUTHORITY XDG_CACHE_HOME XDG_CONFIG_HOME XDG_DATA_HOME XDG_RUNTIME_DIR" FCFLAGS="-O2 -pipe" FEATURES="assume-digests binpkg-docompress binpkg-dostrip binpkg-logs config-protect-if-modified distlocks ebuild-locks fixlafiles ipc-sandbox merge-sync multilib-strict network-sandbox news parallel-fetch pid-sandbox preserve-libs protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userpriv usersandbox usersync xattr" FFLAGS="-O2 -pipe" GENTOO_MIRRORS="ftp://mirror.csclub.uwaterloo.ca/gentoo-distfiles/ ftp://mirror.bytemark.co.uk/gentoo/ http://ftp.halifax.rwth-aachen.de/gentoo/" LANG="C.utf8" LDFLAGS="-Wl,-O1 -Wl,--as-needed" LINGUAS="en it" MAKEOPTS="-j9 -l9" PKGDIR="/var/cache/binpkgs" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir-times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --exclude=/.git" PORTAGE_TMPDIR="/var/tmp" USE="X a52 aac acl acpi alsa amd64 berkdb bluetooth branding bzip2 cairo cdda cdr cli consolekit crypt cups cxx dbus dri dts dvd dvdr emboss encode exif fam flac gdbm gif glamor gpm gtk gtk3 iconv icu jpeg lcms libnotify libtirpc logrotate mad mng mp3 mp4 mpeg mtp multilib ncurses nls nptl nsplugin ogg opengl openmp pam pango pcre pdf png policykit ppds pulseaudio readline sdl seccomp spell split-usr ssl startup-notification svg tcpd tiff truetype udev udisks unicode upower usb vorbis wifi wxwidgets x264 xattr xcb xml xv xvid zlib" ABI_X86="64" ADA_TARGET="gnat_2018" ALSA_CARDS="hda-intel" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="karbon sheets words" CAMERAS="canon" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" CPU_FLAGS_X86="aes avx fma3 fma4 mmx mmxext popcnt sse sse2 sse3 sse4_1 sse4_2 sse4a ssse3 xop" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock isync itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf skytraq superstar2 timing tsip tripmate tnt ublox ubx" INPUT_DEVICES="evdev" KERNEL="linux" L10N="en it" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" NETBEANS_MODULES="apisupport cnd groovy gsf harness ide identity j2ee java mobility nb php profiler soa visualweb webcommon websvccommon xml" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php7-2" POSTGRES_TARGETS="postgres10 postgres11" PYTHON_SINGLE_TARGET="python3_6" PYTHON_TARGETS="python2_7 python3_6" RUBY_TARGETS="ruby24 ruby25" SANE_BACKENDS="niash" USERLAND="GNU" VIDEO_CARDS="nouveau" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" Unset: CC, CPPFLAGS, CTARGET, CXX, INSTALL_MASK, LC_ALL, PORTAGE_BINHOST, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS ================================================================= Package Settings ================================================================= www-client/seamonkey-2.49.9.1_p0::gentoo was built with the following: USE="dbus gmp-autoupdate ipc jemalloc pulseaudio startup-notification -calendar -chatzilla -crypt -custom-cflags -custom-optimization -debug -force-gtk3 -jack -minimal (-neon) -roaming (-selinux) (-system-cairo) -system-harfbuzz -system-icu -system-jpeg -system-libevent -system-libvpx -system-sqlite -test -wifi" ABI_X86="(64)" L10N="it -cs -de -en-GB -es-AR -es-ES -fr -hu -ja -lt -nl -pl -pt-PT -ru -sk -sv -zh-CN -zh-TW" CFLAGS="-march=native -pipe -mno-avx" CXXFLAGS="-march=native -pipe -fno-delete-null-pointer-checks -fno-lifetime-dse -fno-schedule-insns2 -mno-avx" LDFLAGS="-Wl,-O1 -Wl,--as-needed -Wl,-rpath=/usr/lib64/seamonkey,--enable-new-dtags"
The problem originally occured on an XFCE-based box, if it matters. I have hit the same build problem on a different box, ~amd64 and LXDE-based. The XFCE one was installed from stage3 just a few weeks ago. On a third box, ~x86 and LXDE-based, the package builds without problems. I am switching to a different browser/email package combination so this problem has become less important for me but I can keep the package around for any checks that may help troubleshoot the issue, if necessary. Let me know.
(In reply to raffaele from comment #1) > The problem originally occured on an XFCE-based box, if it matters. I have > hit the same build problem on a different box, ~amd64 and LXDE-based. The > XFCE one was installed from stage3 just a few weeks ago. On a third box, > ~x86 and LXDE-based, the package builds without problems. > > I am switching to a different browser/email package combination so this > problem has become less important for me but I can keep the package around > for any checks that may help troubleshoot the issue, if necessary. Let me > know. False positive. LSF simply disables Werror=format: http://www.linuxfromscratch.org/blfs/view/cvs/xsoft/seamonkey.html " GCC-9 generates some false positives with -Werror=format, which prevent building SeaMonkey. Remove this flag with the following command: grep -rl -- '-Werror=format' | xargs sed -i 's/error=format/no-&/' " Works for me.
(In reply to Attila Tóth from comment #2) > LSF simply disables Werror=format: > GCC-9 generates some false positives I wouldn't call those "false positives". Passing NULL to a "%s" printf() format is a super-undefined behaviour. The C standard (I don't think C++ defines it but only refers to the C standard?) says that the argument should point to a character array. That's all, and NULL doesn't point to valid character array. Some compiler implementations happen to have chosen to have printf() print a specific string when they receive a NULL argument for "%s". But even those do it very erratically: On my setup with my gcc, printf("%s") will print '(null)'. But printf("%s\n") will segfault! Try this example: ------------------------ #include <stdio.h> int main(void) { printf("1: %s\n", NULL); printf("2: "); printf("%s", NULL); printf("\n"); printf("3: "); printf("%s\n", NULL); } ------------------------ With clang, it will print 3 '(null)' strings if you compile with -O0, but it will segfault on the third if you compile with -O1 (or more). With gcc, it always segfaults on the third. And with g++, it never segfaults. ################### Anyway, this sloppy stuff should be fixed upstream. As far as distros/users are concerned, I guess it is enough to assume that, considering the specific compilers used, and the specific cases involved, one may go with ignoring the undefined behaviour error/warning. NB: I am not a maintainer, this is just my opinion :-)
(In reply to stephane.goujet from comment #3) > (In reply to Attila Tóth from comment #2) > > > > LSF simply disables Werror=format: > > GCC-9 generates some false positives > > I wouldn't call those "false positives". Passing NULL to a "%s" printf() > format is a super-undefined behaviour. > > The C standard (I don't think C++ defines it but only refers to the C > standard?) says that the argument should point to a character array. That's > all, and NULL doesn't point to valid character array. > > Some compiler implementations happen to have chosen to have printf() print a > specific string when they receive a NULL argument for "%s". But even those > do it very erratically: > > On my setup with my gcc, printf("%s") will print '(null)'. But > printf("%s\n") will segfault! > > > Try this example: > ------------------------ > #include <stdio.h> > > int main(void) { > printf("1: %s\n", NULL); > printf("2: "); > printf("%s", NULL); > printf("\n"); > printf("3: "); > printf("%s\n", NULL); > } > ------------------------ > > With clang, it will print 3 '(null)' strings if you compile with -O0, but it > will segfault on the third if you compile with -O1 (or more). With gcc, it > always segfaults on the third. And with g++, it never segfaults. > > ################### > > Anyway, this sloppy stuff should be fixed upstream. As far as distros/users > are concerned, I guess it is enough to assume that, considering the specific > compilers used, and the specific cases involved, one may go with ignoring > the undefined behaviour error/warning. > > NB: I am not a maintainer, this is just my opinion :-) Thanks. However I tried to modify the code to check the imput parameters before, but the compiler still bails out. Or I tried to do it wrong...
(In reply to Attila Tóth from comment #4) > However I tried to modify the code to check the imput parameters before, but > the compiler still bails out. Or I tried to do it wrong... Hmmm... Am I right if I suppose you tested the last parameter (GP...) in that line? -------------------- spew("movq " MEM_obs ", %s", ADDR_obs(offset, base, index, scale), GPReg64Name(dst)) -------------------- If that's the case, I would say we are not looking at the right "%s". There is the obvious one, but there are also several formats hidden in the MEM_obs macro :-( MEM_obs is defined (in "mozilla/js/src/jit/x86-shared/AssemblerBuffer-x86-shared.h") as: -------------------- #define MEM_obs MEM_o "(%s,%s,%d)" -------------------- and MEM_o itself is defined -------------------- #define MEM_o "%s0x%x" -------------------- So that's a total of 3 extra "%s" which can fail. The final format is something like "movq %s0x%x(%s,%s,%d) %s". And they are fed by the ADDR_obs() macro, defined in the same file. I guess that's in this macro (and the one it calls) that tests for NULL should be inserted. I don't have time at the moment to investigate further, sorry. (And I also don't have gcc-9 on my setup to test anything + I have other problems compiling this damn version of semaonkey, so maybe I don't even manage to get compilation to the point of that error ;-) ).
(In reply to stephane.goujet from comment #5) > (In reply to Attila Tóth from comment #4) > > However I tried to modify the code to check the imput parameters before, but > > the compiler still bails out. Or I tried to do it wrong... > > Hmmm... > > Am I right if I suppose you tested the last parameter (GP...) in that line? > > -------------------- > spew("movq " MEM_obs ", %s", ADDR_obs(offset, base, index, scale), > GPReg64Name(dst)) > -------------------- > > If that's the case, I would say we are not looking at the right "%s". There > is the obvious one, but there are also several formats hidden in the MEM_obs > macro :-( > > MEM_obs is defined (in > "mozilla/js/src/jit/x86-shared/AssemblerBuffer-x86-shared.h") as: > > -------------------- > #define MEM_obs MEM_o "(%s,%s,%d)" > -------------------- > > and MEM_o itself is defined > > -------------------- > #define MEM_o "%s0x%x" > -------------------- > > So that's a total of 3 extra "%s" which can fail. The final format is > something like "movq %s0x%x(%s,%s,%d) %s". > > And they are fed by the ADDR_obs() macro, defined in the same file. I guess > that's in this macro (and the one it calls) that tests for NULL should be > inserted. > > I don't have time at the moment to investigate further, sorry. (And I also > don't have gcc-9 on my setup to test anything + I have other problems > compiling this damn version of semaonkey, so maybe I don't even manage to > get compilation to the point of that error ;-) ). I also tried to track down those sequence of macros, creating a rabbit-hole. I'm not convinced those macros are helping us. I tried multiple parameters and may have failed to do that properly. It's also interesting that there are more functions similar to this one from regards of the parameters. Why only this one bothers the compiler? I also don't have enough time to get to the end of this. Additionally, I don't like the concept, that the user cannot choose whether to enable jit support. Older versions of mozilla stuff had a configuration option to do that...
(In reply to Attila Tóth from comment #6) > I also tried to track down those sequence of macros, creating a rabbit-hole. Ok, so I was wrong, you didn't make the same mistake I would have made. Eh eh. > It's also interesting that there > are more functions similar to this one from regards of the parameters. Why > only this one bothers the compiler? It's strange. The 1st argument matching a "%s" is coming from PRETTYHEX and resolves to a string literal, and the other 3 seem to resolve to calls to GPReg64Name, which just return one element of an array of string literals, and this array contains no NULL. So I don't see where any NULL could come from. Could you try protecting the access to 'names' in "mozilla/js/src/jit/x86-shared/Constants-x86-shared.h" from a theoretical out-of-bounds index? Something like this: ------------------ inline const char* GPReg64Name(RegisterID reg) { static const char* const names[] = { "%rax", "%rcx", "%rdx", "%rbx", "%rsp", "%rbp", "%rsi", "%rdi" #ifdef JS_CODEGEN_X64 ,"%r8", "%r9", "%r10", "%r11", "%r12", "%r13", "%r14", "%r15" #endif }; MOZ_ASSERT(size_t(reg) < mozilla::ArrayLength(names)); /* return names[reg]; */ if(reg<invalid_reg) { return names[reg]; } else { return "boo!" } } ------------------ Perhaps it will please GCC. Just a thought.
Going through old bug reports for www-client/seamonkey. The package in question has left the ebuild tree already for quite some time. Is this still an issue?
