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