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@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@entry=0x169770d60, obj=...,
obj@entry=..., description=description@entry=0x3ffb24184ee "GI repository
object", property_name=...,
property_name@entry=..., reason=reason@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@entry=0x169770d60, obj=obj@entry=...,
description=description@entry=0x3ffb24184ee "GI repository object",
property_name=..., value=..., value@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@entry=0x169770d60, repo_obj=..., repo_obj@entry=...,
ns_id=...,
ns_id@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
