Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
DescriptionFrank Ramsay (HPE)
2015-04-06 14:00:05 UTC
Created attachment 1011386[details]
Tarball of Abrt report
Description of problem:
kernel: traps: polkitd[1488] general protection ip:7ffff69e5cf2 sp:7fffffffdfd0 error:0 in libmozjs-17.0.so[7ffff68a7000+3b3000
abrt-hook-ccpp: Saved core dump of pid 1488 (/usr/lib/polkit-1/polkitd) to /var/tmp/abrt/ccpp-2015-03-27-07:28:02-1488 (65474560 bytes)
(gdb) bt
#0 js::ShapeTable::search (this=0x7ffff0625f80, id=id@entry=140737226257184, adding=adding@entry=false) at /usr/src/debug/mozjs17.0.0/js/src/jsscope.cpp:163
#1 0x00007ffff6a8c648 in search (adding=false, pspp=<synthetic pointer>, id=140737226257184, start=<optimized out>, cx=0x7ffff051de48)
at /usr/src/debug/mozjs17.0.0/js/src/jsscope.h:1085
#2 js::ObjectImpl::nativeLookup (this=<optimized out>, cx=cx@entry=0x5555557b6950, id=140737226257184) at /usr/src/debug/mozjs17.0.0/js/src/vm/ObjectImpl.cpp:265
#3 0x00007ffff69a39dc in LookupPropertyWithFlagsInline (propp=..., objp=..., flags=65535, id=..., obj=..., cx=0x5555557b6950)
at /usr/src/debug/mozjs17.0.0/js/src/jsobj.cpp:4051
#4 js_GetPropertyHelperInline (vp=..., getHow=1, id_=<optimized out>, receiver=..., obj=..., cx=<optimized out>) at /usr/src/debug/mozjs17.0.0/js/src/jsobj.cpp:4277
#5 js::GetPropertyHelper (cx=0x5555557b6950, obj=..., id=..., getHow=1, vp=...) at /usr/src/debug/mozjs17.0.0/js/src/jsobj.cpp:4365
#6 0x00007ffff69800ee in js::Interpret (cx=0x5555557b6950, entryFrame=<optimized out>, interpMode=js::JSINTERP_NORMAL)
at /usr/src/debug/mozjs17.0.0/js/src/jsinterpinlines.h:270
#7 0x00007ffff698574d in js::RunScript (cx=0x5555557b6950, script=<optimized out>, fp=0x7ffff0f3a068) at /usr/src/debug/mozjs17.0.0/js/src/jsinterp.cpp:309
#8 0x00007ffff69859c9 in js::InvokeKernel (cx=0x5555557b6950, args=..., construct=js::NO_CONSTRUCT) at /usr/src/debug/mozjs17.0.0/js/src/jsinterp.cpp:363
#9 0x00007ffff6985d15 in js::Invoke (cx=0x5555557b6950, thisv=..., fval=..., argc=3, argv=0x7fffffffe700, rval=0x7fffffffe6f0)
at /usr/src/debug/mozjs17.0.0/js/src/jsinterp.h:119
#10 0x00007ffff68f155a in JS_CallFunctionName (cx=0x5555557b6950, objArg=<optimized out>, name=name@entry=0x5555555693ab "_runRules", argc=argc@entry=3,
argv=argv@entry=0x7fffffffe700, rval=rval@entry=0x7fffffffe6f0) at /usr/src/debug/mozjs17.0.0/js/src/jsapi.cpp:5837
#11 0x000055555556071d in call_js_function_with_runaway_killer (rval=0x7fffffffe6f0, argv=0x7fffffffe700, argc=3, function_name=0x5555555693ab "_runRules",
authority=0x5555557818d0) at polkitbackendjsauthority.c:1019
#12 polkit_backend_js_authority_check_authorization_sync (_authority=<optimized out>, caller=<optimized out>, subject=0x7fffe4033d30, user_for_subject=0x7fffe4035c90,
subject_is_local=1, subject_is_active=1, action_id=0x555555c386c3 "org.freedesktop.NetworkManager.sleep-wake", details=0x555555baecc0,
implicit=POLKIT_IMPLICIT_AUTHORIZATION_NOT_AUTHORIZED) at polkitbackendjsauthority.c:1180
#13 0x000055555556481d in check_authorization_sync (authority=authority@entry=0x5555557818d0, caller=caller@entry=0x555555b72700, subject=subject@entry=0x7fffe4033d30,
action_id=action_id@entry=0x555555c386c3 "org.freedesktop.NetworkManager.sleep-wake", details=details@entry=0x555555baecc0,
flags=flags@entry=POLKIT_CHECK_AUTHORIZATION_FLAGS_NONE, out_implicit_authorization=out_implicit_authorization@entry=0x7fffffffe924, checking_imply=checking_imply@entry=0,
error=error@entry=0x7fffffffe928) at polkitbackendinteractiveauthority.c:1131
#14 0x00005555555651f0 in polkit_backend_interactive_authority_check_authorization (authority=0x5555557818d0, caller=<optimized out>, subject=0x7fffe4033d30,
action_id=0x555555c386c3 "org.freedesktop.NetworkManager.sleep-wake", details=0x555555baecc0, flags=POLKIT_CHECK_AUTHORIZATION_FLAGS_NONE, cancellable=0x7fffe4030d30,
callback=0x55555555dcd0 <check_auth_cb>, user_data=0x555555c39810) at polkitbackendinteractiveauthority.c:952
#15 0x000055555555e1fa in server_handle_check_authorization (invocation=0x5555558f36c0, caller=0x555555b72700, parameters=0xc22b2ab815f13c00, server=0x5555557c2390)
at polkitbackendauthority.c:787
#16 server_handle_method_call (connection=<optimized out>, sender=sender@entry=0x7fffe40207e0 ":1.8",
object_path=object_path@entry=0x7fffe4019220 "/org/freedesktop/PolicyKit1/Authority",
interface_name=interface_name@entry=0x7fffe4007af0 "org.freedesktop.PolicyKit1.Authority", method_name=method_name@entry=0x7fffe400ba20 "CheckAuthorization",
parameters=parameters@entry=0x7fffe402e560, invocation=invocation@entry=0x5555558f36c0, user_data=user_data@entry=0x5555557c2390) at polkitbackendauthority.c:1214
#17 0x00007ffff7915c61 in call_in_idle_cb (user_data=0x5555558f36c0) at gdbusconnection.c:4875
#18 0x00007ffff73109ba in g_main_dispatch (context=0x55555577fdf0) at gmain.c:3061
#19 g_main_context_dispatch (context=context@entry=0x55555577fdf0) at gmain.c:3660
#20 0x00007ffff7310d08 in g_main_context_iterate (context=0x55555577fdf0, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3731
#21 0x00007ffff7310fda in g_main_loop_run (loop=0x5555557c2880) at gmain.c:3925
#22 0x000055555555d4b5 in main (argc=1, argv=0x7fffffffedf8) at polkitd.c:236
(gdb) list
158 hash0 = HashId(id);
159 hash1 = HASH1(hash0, hashShift);
160 spp = entries + hash1;
161
162 /* Miss: return space for a new entry. */
163 stored = *spp; <== we die *HERE*
164 if (SHAPE_IS_FREE(stored))
165 return spp;
166
167 /* Hit: return entry. */
(gdb) p spp
$1 = (js::Shape **) 0x72006505a65d05
^^^^^^^^^^^^^^^^
and as expected, the following confirms why we died:
(gdb) p *spp
Cannot access memory at address 0x72006505a65d05
(gdb) p *(js::Shape **) 0x72006505a65d05
Cannot access memory at address 0x72006505a65d05
Given that spp's address is derived from that of entries:
160 spp = entries + hash1;
this means that entries itself is bogus:
(gdb) p entries
$2 = (js::Shape **) 0x72006500730075
(gdb) p *entries
Cannot access memory at address 0x72006500730075
and given the function reads:
139 /*
140 * Double hashing needs the second hash code to be relatively prime to table
141 * size, so we simply make hash2 odd.
142 */
143 #define HASH1(hash0,shift) ((hash0) >> (shift))
144 #define HASH2(hash0,log2,shift) ((((hash0) << (log2)) >> (shift)) | 1)
145
146 Shape **
147 ShapeTable::search(jsid id, bool adding)
148 {
149 js::HashNumber hash0, hash1, hash2;
150 int sizeLog2;
151 Shape *stored, *shape, **spp, **firstRemoved;
152 uint32_t sizeMask;
153
154 JS_ASSERT(entries);
155 JS_ASSERT(!JSID_IS_EMPTY(id));
156
157 /* Compute the primary hash address. */
158 hash0 = HashId(id);
159 hash1 = HASH1(hash0, hashShift);
160 spp = entries + hash1;
161
162 /* Miss: return space for a new entry. */
163 stored = *spp;
it would *seem* that whatever messed up entries is not this thread.
Looking at the other threads, didn't reveal anything strikingly useful:
(gdb) thread apply all bt
Thread 6 (Thread 0x7fffe3fff700 (LWP 1501)):
#0 0x00007ffff63b5b7d in poll () at ../sysdeps/unix/syscall-template.S:81
#1 0x00007ffff7310c94 in g_main_context_poll (priority=2147483647, n_fds=1, fds=0x7fffd8001290, timeout=15052, context=0x7fffd80008c0) at gmain.c:4025
..
Thread 5 (Thread 0x7ffff1b3a700 (LWP 1499)):
#0 pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1 0x00007ffff4c23270 in PR_WaitCondVar (cvar=0x555555798d70, timeout=4294967295) at ../../../nspr/pr/src/pthreads/ptsynch.c:385
..
Thread 4 (Thread 0x7ffff0f39700 (LWP 1500)):
#0 pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1 0x00007ffff4c23270 in PR_WaitCondVar (cvar=0x5555557a3fb0, timeout=4294967295) at ../../../nspr/pr/src/pthreads/ptsynch.c:385
..
Thread 3 (Thread 0x7ffff233b700 (LWP 1498)):
#0 0x00007ffff63b5b7d in poll () at ../sysdeps/unix/syscall-template.S:81
#1 0x00007ffff7310c94 in g_main_context_poll (priority=2147483647, n_fds=2, fds=0x7fffe40010c0, timeout=-1, context=0x5555557962a0) at gmain.c:4025
..
Thread 2 (Thread 0x7ffff2b3c700 (LWP 1489)):
#0 0x00007ffff63b5b7d in poll () at ../sysdeps/unix/syscall-template.S:81
#1 0x00007ffff7310c94 in g_main_context_poll (priority=2147483647, n_fds=2, fds=0x7fffec0008e0, timeout=-1, context=0x555555787380) at gmain.c:4025
#2 g_main_context_iterate (context=context@entry=0x555555787380, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3726
..
/* the failing thread */
Thread 1 (Thread 0x7ffff7fd0840 (LWP 1488)):
#0 js::ShapeTable::search (this=0x7ffff0625f80, id=id@entry=140737226257184, adding=adding@entry=false) at /usr/src/debug/mozjs17.0.0/js/src/jsscope.cpp:163
#1 0x00007ffff6a8c648 in search (adding=false, pspp=<synthetic pointer>, id=140737226257184, start=<optimized out>, cx=0x7ffff051de48)
at /usr/src/debug/mozjs17.0.0/js/src/jsscope.h:1085
#2 js::ObjectImpl::nativeLookup (this=<optimized out>, cx=cx@entry=0x5555557b6950, id=140737226257184) at /usr/src/debug/mozjs17.0.0/js/src/vm/ObjectImpl.cpp:265
I'll put a tarball of the abrt report, including the coredump, on
efs for you to grab and pass on to Red Hat.
may be related to:
https://bugzilla.redhat.com/show_bug.cgi?id=910262https://bugzilla.redhat.com/show_bug.cgi?id=1095484
And upstream BZ too:
https://bugs.freedesktop.org/show_bug.cgi?id=69501
Tarball of Abrt report attached to BZ.
Note: The general protection fault can be easily reproduced by following script
#!/bin/bash
RUN_COMMAND='while virsh -r -c qemu:///system nodeinfo >/dev/null; do :; done'
yum -y groupinstall 'Virtualization Host'
systemctl start libvirtd.service
id oneadmin &>/dev/null || useradd -m oneadmin
su -c "${RUN_COMMAND}" -- oneadmin
On virtualization infrastructures where libvirt management commands are executed by unprivileged users and when PolicyKit is not explicitly disabled in libvirtd.conf, this leads to often virsh failures. Which is unfortunate.
Please see:
https://forum.opennebula.org/t/polkitd-traps-general-protection-ip-in-libmozjs-17-0-so/399
*** This bug has been marked as a duplicate of bug 1271789 ***
Comment 34Frank Ramsay (HPE)
2015-12-01 16:01:03 UTC
I don't have access to bz 1271789 I'm assuming this is because I'm am SGI Partner Engineer.
Is there any information that can be shared so I know how this is progressing?