Bug#927081: gnome-shell: FTBFS on s390x: crash in throw_property_lookup_error()

[Simon McVittie]

Package: libmozjs-60-dev
Version: 60.2.3-3
Severity: important
Tags: help
Control: affects -1 src:gnome-shell src:gjs
X-Debbugs-Cc: debian-s390 at lists.debian.org

mozjs60 and gjs now pass most of their tests on s390x, but there seems
to be some problem when gjs' debug output prints the JS::HandleId
representing a property name as a JSFlatString*, which is causing
gnome-shell to fail tests there. I don't know whether this is related to
whatever bug makes non262/extensions/clone-errors.js fail during mozjs60
unit tests, or to the many test failures seen in gjs (but gjs doesn't
FTBFS because, perhaps unwisely, build-time test failures are ignored).

I suspect that the root cause of all these bugs might be more instances
of mozjs60 casting struct types to other struct types and making
assumptions about which struct fields coincide.

% gdb obj-s390x-linux-gnu/src/run-js-test tests/core
...
Core was generated by `/home/smcv/gnome-shell-3.30.2/obj-s390x-linux-gnu/tests/../src/run-js-test unit'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x000003ffb23eddfc in gjs_debug_flat_string (fstr=<optimized out>) at gjs/jsapi-util-string.cpp:392
392     gjs/jsapi-util-string.cpp: No such file or directory.
[Current thread is 1 (Thread 0x3ffb34bdcc0 (LWP 57720))]
(gdb) bt
#0  0x000003ffb23eddfc in gjs_debug_flat_string(JSFlatString*) (fstr=<optimized out>)
    at gjs/jsapi-util-string.cpp:392
#1  0x000003ffb23ef4c4 in gjs_debug_id[abi:cxx11](jsid) (id=...) at /usr/include/mozjs-60/jsapi.h:4843
#2  0x000003ffb23e8f8c in throw_property_lookup_error(JSContext*, JS::HandleObject, char const*, JS::HandleId, char const*) (cx=cx at entry=0x169770d60, obj=..., 
    obj at entry=..., description=description at entry=0x3ffb24184ee "GI repository object", property_name=..., 
    property_name at entry=..., reason=reason at entry=0x3ffb241b3b8 "it was not an object") at gjs/jsapi-util.cpp:143
#3  0x000003ffb23e9908 in gjs_object_require_property(JSContext*, JS::Handle<JSObject*>, char const*, JS::Handle<jsid>, JS::MutableHandle<JSObject*>)
    (cx=cx at entry=0x169770d60, obj=obj at entry=..., description=description at entry=0x3ffb24184ee "GI repository object", property_name=..., value=..., value at entry=...) at gjs/jsapi-util.cpp:251
#4  0x000003ffb23d83d6 in lookup_override_function (function=..., ns_name=..., cx=0x169770d60)
    at /usr/include/mozjs-60/js/RootingAPI.h:1152
#5  0x000003ffb23d83d6 in resolve_namespace_object(JSContext*, JS::HandleObject, JS::HandleId, char const*)
    (context=context at entry=0x169770d60, repo_obj=..., repo_obj at entry=..., ns_id=..., 
    ns_id at entry=..., ns_name=0x169879b40 "Clutter") at gi/repo.cpp:135
#6  0x000003ffb23d8864 in repo_resolve(JSContext*, JS::HandleObject, JS::HandleId, bool*)
    (context=0x169770d60, obj=..., id=..., resolved=0x3ffc9bfb8e0) at ./gjs/jsapi-util.h:117
#7  0x000003ffaf53b78a in js::CallResolveOp
    (recursedp=<synthetic pointer>, propp=..., id=..., obj=..., cx=0x169770d60)
    at ./debian/build/dist/include/js/RootingAPI.h:545
...
(gdb) info locals
c = <optimized out>
ix = 0
str = <optimized out>
len = <optimized out>
nogc = <optimized out>
out = <incomplete type>
chars = 0x436c757474657200 <error: Cannot access memory at address 0x436c757474657200>

Note that if you interpret the big-endian integer 0x436c757474657200 as
ASCII, it reads "Clutter", suggesting that the bytes at the beginning
of a char[] containing "Clutter" have been interpreted as though they
were a pointer - possibly a JSInlineString being misinterpreted as
a JSFlatString?

Regards,
    smcv