jslint fails to install due to Spidermonkey segfault in variant test

[macports.org@…]

When trying to install jslint, I get the following error:

> sudo port install jslint
--->  Computing dependencies for jslint
--->  Configuring jslint
Error: You need to install spidermonkey with the +fileobject variant in order to use jslint.
Error: Target org.macports.configure returned: incompatible spidermonkey installation
Log for jslint is at: /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_jslint/main.log
Error: Status 1 encountered during processing.
To report a bug, see <http://guide.macports.org/#project.tickets>

Now the error message it reports does not really make sense considering:

> port installed spidermonkey
The following ports are currently installed:
  spidermonkey @1.7.0_5+fileobject (active)

I looked for the test performed in the portfile, the test is the following:

exec ${prefix}/bin/js -e "new File();"

which, when tried from the command-line, yields:

> js -e "new File();"
[1]    95301 segmentation fault  js -e "new File();"

(this is with a freshly installed spidermonkey, by the way)

Makes sense that the jslint configure step would yield an error.

Still, the following passes with flying colors:

js -e "File"

while the following does not:

js -e "FooObject"

Would it be possible to avoid the new File() stuff, and use a bare File, in the test? It is sufficient to get the js process to bail out: (with a reinstalled spidermonkey without +fileobject)

> js -e File
-e:1: ReferenceError: File is not defined

Note: the return code for the js process is 3 for a ReferenceError (e.g. FooObject not defined) and 139 for the segfault. I do not know if it's possible to test for a precise return code.

PS: should I report the spidermonkey segfault as a different bug?

[rudloff@…]

js -e "File" seems to do the trick, but you still won't be able to use jslint if new File(); does not work.
You should probably report the segfault to ​Mozilla.

[macports.org@…]

Are you sure about that? Because new File(filename) works without any issue on this installation:

> js -e "new File();"           
[1]    98402 segmentation fault  js -e "new File();"
> js -e "new File('/dev/null');"
>                                     

and I fail to see why jslint would care for creating a file object with no backing file.

Indeed, the patchfile used to make jslint useable from the command-line creates a file object with an argument, not a no-arg one.

I'll probably report the issue if it still manifests itself in Spidermonkey 1.8.5 (if/when macports udpates to it)

[rudloff@…]

Oh, OK. I thought new File() always failed, even with a filename. I will update the portfile.

[ryandesign@…]

Please supply diffs, not entire new portfiles.

Using the attached portfile still causes the configure phase to fail for me.

[ryandesign@…]

Replying to macports.org@…:

I'll probably report the issue if it still manifests itself in Spidermonkey 1.8.5 (if/when macports udpates to it)

Already requested in #29446.

[macports.org@…]

Replying to rudloff@…:

Oh, OK. I thought new File() always failed, even with a filename. I will update the portfile.

As I said originally, the presence of a File object (so just js -e File) should suffice to know if spidermonkey was installed with +fileobject, which is all the jslint port should care for really.

Replying to ryandesign@…:

Replying to macports.org@…:

I'll probably report the issue if it still manifests itself in Spidermonkey 1.8.5 (if/when macports udpates to it)

Already requested in #29446.

Yeah I saw, hence why I didn't open a new bug on the subject, and just said I'd recheck when the bug's closed.

[macports.org@…]

This patch makes the jslint port:

• refuse to install if spidermonkey is installed without +fileobject
• install correctly if spidermonkey is installed with +fileobject

[ryandesign@…]

Thanks, looks good to me. r78870