Bug 223956 - www/w3m from head fails to build
Summary: www/w3m from head fails to build
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: arm64 Any
: --- Affects Only Me
Assignee: MANTANI Nobutaka
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-11-29 01:09 UTC by dave
Modified: 2018-05-26 13:46 UTC (History)
1 user (show)

See Also:
bugzilla: maintainer-feedback? (nobutaka)

Attachments
Log of build (45.27 KB, text/x-log)
2017-11-29 01:09 UTC, dave 		no flags Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description dave 2017-11-29 01:09:25 UTC 
Created attachment 188384 [details]
Log of build

I am runnuing poudriere on a FreeBSD 12.0-CURRENT #6 r319962 server.

I am making my first pass at building ports for a Raspberry Pi 3.

I have created a jail that matches the host's O/S via:

poudriere jail -c -x -j rpi3v12 -m svn -a arm64.aarch64 -v head@319962

The build was then exectued via:

poudriere bulk -T -j rpi3v12 -p head -z default -f /usr/local/etc/poudriere-list-rpi

Lots of ports build then www/w3m fails with:

./mktable 100 functable.tab > functable.c
<jemalloc>: jemalloc_arena.c:353: Failed assertion: "p[i] == 0"
*** Signal 6

Stop.
make[1]: stopped in /wrkdirs/usr/ports/www/w3m/work/w3m-1ac245b

The same port builds happily on my RPI2 jail under the same poudriere environment.

I have attached the build log.
Comment 1 dave 2017-12-06 04:16:50 UTC 
After reading https://wiki.freebsd.org/arm64/rpi3 which mentions issues with 
jemalloc, I tried the build in two additional ways.

I tried with MALLOC_CONF inside the jail and I also tried with this set on the jail's host.

The failure still occurs.
Comment 2 Mikael Urankar freebsd_committer freebsd_triage 2017-12-06 08:43:32 UTC 
It builds fine on the cluster:
http://thunderx1.nyi.freebsd.org/data/head-arm64-default/p454157_s325785/logs/w3m-0.5.3.20170102.log
Comment 3 dave 2017-12-07 01:37:57 UTC 
I will try again with an absolutely up to date rpi3 jail.  I was currently matching the jail version to the Host version to avoid poudriere sqwaking about the jail being newer than the Host.

I will report back results.
Comment 4 dave 2017-12-07 06:05:57 UTC 
Tried with fresh jail and fresh ports tree.

Same problem is seen.
Comment 5 Mikael Urankar freebsd_committer freebsd_triage 2017-12-12 11:00:54 UTC 
It builds fine on real hw, it's a qemu bug.
Comment 6 Mikael Urankar freebsd_committer freebsd_triage 2018-05-24 17:16:23 UTC 
Here is a patch to fix the qemu bug (I've sent the patch to sbruno@):

--- bsd-user/aarch64/target_arch_vmparam.h.orig 2018-05-24 18:59:54.028444000 +0200
+++ bsd-user/aarch64/target_arch_vmparam.h      2018-05-24 19:00:41.441577000 +0200
@@ -55,7 +55,7 @@
 // #define TARGET_RESERVED_VA  0xf7000000
 
                 /* KERNBASE - 512 MB */
-#define TARGET_VM_MAXUSER_ADDRESS   (0x000000800000000UL - (512UL * 1024 * 1024))
+#define TARGET_VM_MAXUSER_ADDRESS   (0x00007fffff000000ULL - (512UL * 1024 * 1024))
 #define TARGET_USRSTACK             TARGET_VM_MAXUSER_ADDRESS
 
 static inline abi_ulong get_sp_from_cpustate(CPUARMState *state)

I think this PR can be closed.