Bug 198350 - [www/node] segfault when installing npm on 8.4, 9.3 on i386
Summary: [www/node] segfault when installing npm on 8.4, 9.3 on i386
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: i386 Any
: --- Affects Many People
Assignee: Po-Chuan Hsieh
URL: http://beefy1.isc.freebsd.org/bulk/84...
Keywords:
Depends on:
Blocks:
 
Reported: 2015-03-06 11:39 UTC by Marcin Cieślak
Modified: 2015-05-16 19:21 UTC (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Marcin Cieślak 2015-03-06 11:39:12 UTC
Tried building node and npm on poudriere in i386 jail and unfortunately resulting
nodejs binary crashes when trying to install npm:

=======================<phase: stage          >============================
===>  Staging for npm-2.6.1
===>   Generating temporary packing list
node cli.js --cache /wrkdirs/usr/ports/www/npm/work/.cache install -g -f 
*** Signal 11

Stop in /wrkdirs/usr/ports/www/npm/work/npm-2.6.1.
*** Error code 1

Stop in /usr/ports/www/npm.

When trying to run the same command outside of jail on amd64 host it works.

Confirmed on port cluster, breaks building npm there:


http://portsmon.freebsd.org/portoverview.py?category=&portname=npm
Comment 1 Marcin Cieślak 2015-03-06 15:31:14 UTC
So, managed to get a backtrace:

(gdb) bt
#0  0x0888d9ad in uv_interface_addresses (addresses=0xffffcb68, count=0xffffcb64) at ../deps/uv/src/unix/freebsd.c:380
#1  0x0882b2ed in GetInterfaceAddresses (args=@0xffffcba0) at ../src/node_os.cc:237
#2  0x083c138d in v8::internal::FunctionCallbackArguments::Call (this=0xffffcc30, f=0x882b2a0 <GetInterfaceAddresses>) at ../deps/v8/src/arguments.cc:33
#3  0x083ea953 in Builtin_HandleApiCall (args_length=2, args_object=0xffffccac, isolate=0x29018800) at ../deps/v8/src/builtins.cc:1144

(gdb) print *ent
$2 = {ifa_next = 0x29c6c01c, ifa_name = 0x29c6c36e "\006\003\006", ifa_flags = 34883, ifa_addr = 0x29c6c150, ifa_netmask = 0x0, ifa_dstaddr = 0x0, 
  ifa_data = 0x29c6c154}

also "ifconfig -a" looks strange in this jail:

# ifconfig -a
: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST>
        inet 213.239.217.105 netmask 0xffffffe0 broadcast 213.239.217.127
        inet 213.239.217.125 netmask 0xffffffe0 broadcast 213.239.217.127
ifconfig: ioctl(SIOCGIFINFO_IN6): Device not configured
: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST>
        inet 127.0.0.1 netmask 0xff000000 
ifconfig: ioctl(SIOCGIFINFO_IN6): Device not configured

I think data returned by getifaddrs(3) are bogus and this is bug 178881

*** This bug has been marked as a duplicate of bug 178881 ***
Comment 2 Marcin Cieślak 2015-03-06 15:33:34 UTC
Only on 10.1 getifaddrs(3) appears to work, I wonder why. (also i386)

FreeBSD nodejs_10_1_i386-default 10.1-RELEASE-p6 FreeBSD 10.1-RELEASE-p6 i386

My kernel is r270025, 10.0-STABLE
Comment 3 Marcin Cieślak 2015-03-06 17:52:48 UTC
The best way to test this is to query "os.networkInterfaces()" in node

On 8.4 and 9.3 i386 os.networkInterfaces() crashes the process, on
10.1 it just gives incorrect results.

Here's output from 10.1 i386 jail (running on amd64 kernel):

> os.networkInterfaces()
{ /* .. */
  lo0: 
   [ { address: '<unknown sa family>',
       netmask: '255.255.255.224',
       family: '<unknown>',
       mac: '00:00:00:00:00:00',
       internal: true },
     { address: '<unknown sa family>',
       netmask: '255.255.255.224',
       family: '<unknown>',
       mac: '00:00:00:00:00:00',
       internal: true },
     { address: '127.0.0.1',
       netmask: '255.0.0.0',
       family: 'IPv4',
       mac: '00:00:00:00:00:00',
       internal: true } ] }

correct output:
{ /* .. */
  lo0: 
   [ { address: '::1',
       netmask: 'ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff',
       family: 'IPv6',
       mac: '00:00:00:00:00:00',
       scopeid: 0,
       internal: true },
     { address: 'fe80::1',
       netmask: 'ffff:ffff:ffff:ffff::',
       family: 'IPv6',
       mac: '00:00:00:00:00:00',
       scopeid: 2,
       internal: true },
     { address: '127.0.0.1',
       netmask: '255.0.0.0',
       family: 'IPv4',
       mac: '00:00:00:00:00:00',
       internal: true } ] }
Comment 4 Marcin Cieślak 2015-03-13 13:48:42 UTC
Here is a quick workaround to get www/npm to build on amd64 host running i386 jail:

diff -ruN /usr/ports/www/npm/Makefile npm/Makefile
--- /usr/ports/www/npm/Makefile 2015-03-11 16:10:57.000000000 +0000
+++ npm/Makefile        2015-03-13 12:50:19.000000000 +0000
@@ -3,6 +3,7 @@
 
 PORTNAME=      npm
 PORTVERSION=   2.7.0
+PORTREVISION=  1
 CATEGORIES=    www
 MASTER_SITES=  LOCAL/sunpoet
 
@@ -79,4 +80,11 @@
        @sudo ${INSTALL} -m 644 ${MS_WRKSRC}/${PORTNAME}-${MS_VERSION}.tar.xz ${DISTDIR}/
        @cd ${.CURDIR}/ && ${MAKE_CMD} makesum
 
-.include <bsd.port.mk>
+.include <bsd.port.pre.mk>
+
+.if ${ARCH} == "i386"
+# Workaround for kernel bug 178881
+EXTRA_PATCHES+=                ${PATCHDIR}/bug178881-workaround
+.endif
+
+.include <bsd.port.post.mk>
diff -ruN /usr/ports/www/npm/files/bug178881-workaround npm/files/bug178881-workaround
--- /usr/ports/www/npm/files/bug178881-workaround       1970-01-01 00:00:00.000000000 +0000
+++ npm/files/bug178881-workaround      2015-03-13 11:13:41.000000000 +0000
@@ -0,0 +1,20 @@
+--- lib/config/defaults.js.orig        2015-02-20 16:48:40.000000000 +0000
++++ lib/config/defaults.js     2015-03-13 11:11:16.000000000 +0000
+@@ -325,16 +325,7 @@
+   }
+ 
+ function getLocalAddresses() {
+-  Object.keys(os.networkInterfaces()).map(function (nic) {
+-    return os.networkInterfaces()[nic].filter(function (addr) {
+-      return addr.family === "IPv4"
+-    })
+-    .map(function (addr) {
+-      return addr.address
+-    })
+-  }).reduce(function (curr, next) {
+-    return curr.concat(next)
+-  }, []).concat(undefined)
++  return [ '127.0.0.1', undefined ]
+ }
+ 
+ exports.shorthands =

it just cheats npm to think it only has 127.0.0.1 IPv4 address.

of course the "i386" test is wrong, because we have a problem
probably only on amd64 host/i386 guest combination.
Comment 5 Bryan Drewery freebsd_committer freebsd_triage 2015-03-25 01:42:49 UTC
This may be a duplicate, but it is not fixed. I searched for open npm bugs and could not find this.
Comment 6 commit-hook freebsd_committer freebsd_triage 2015-05-16 17:03:28 UTC
A commit references this bug:

Author: sunpoet
Date: Sat May 16 17:02:38 UTC 2015
New revision: 386559
URL: https://svnweb.freebsd.org/changeset/ports/386559

Log:
  - Revert r386459
  - Add workaround for i386 to deal with kernel bug 178881 [1]
    (PR/178881: getifaddrs(3) does not report IPv6 addresses properly in 32-bit compatibility mode)

  PR:		198350 [1]
  Submitted by:	Marcin Cieslak <saper@saper.info> [1]
  Thanks to:	adamw, bdrewery
  MFH:		2015Q2

Changes:
  head/www/npm/Makefile
  head/www/npm/files/
  head/www/npm/files/extra-patch-bug-178881
Comment 7 Po-Chuan Hsieh freebsd_committer freebsd_triage 2015-05-16 17:04:48 UTC
Committed. Thanks!
Comment 8 Marcin Cieślak 2015-05-16 19:20:42 UTC
(In reply to commit-hook from comment #6)

>  - Add workaround for i386 to deal with kernel bug 178881 [1]
>    (PR/178881: getifaddrs(3) does not report IPv6 addresses properly in 32-bit > compatibility mode)

This workaround disables getifaddr(3) functionality completely in npm.
Actually it should work fine for i386 userland running on i386 kernels; only i386 userland on the amd64 kernel is affected.
Comment 9 Marcin Cieślak 2015-05-16 19:21:40 UTC
(i386 on i386 should not have this patch, only i386 on amd64 - that's why it's just a workaround, not a general solution).