Bug 1394837

js seems to crash on current aarch64 kernels - is this the cause? Will someone handle the patching and rebuild of js dependencies?

(In reply to Tomas Mraz from comment #1)
> js seems to crash on current aarch64 kernels - is this the cause? Will
> someone handle the patching and rebuild of js dependencies?

You need to be a little more specific there, last I looked this issue was fixed on the js package as of 1.8.5-16

Hmm that's weird as the js keeps crashing (only on aarch64) even on js-1.8.5-26.fc26 (it does not crash when run on old kernel). Perhaps it regressed? I've tried to apply something similar as the patch on bug 1395969 and it allowed the build tests of js to progress further but later it crashed too. (It was not a serious attempt at fix as I do not know the js code, I just wanted to see if it is related.)
See https://bugzilla.redhat.com/show_bug.cgi?id=1424039 and https://bugzilla.redhat.com/show_bug.cgi?id=1423793 which are most probably the same issue.

On 2017-Feb-28, we have reached the Fedora 26 Change Checkpoint: Completion deadline (testable).

At this point, all accepted changes should be substantially complete, and testable. Additionally, if a change is to be enabled by default, it must be enabled at Change Completion deadline as well.

Change tracking bug should be set to the MODIFIED state to indicate it achieved completeness.

Incomplete and non testable Changes will be reported to FESCo for 2017-Mar-03 meeting.

This bug appears to have been reported against 'rawhide' during the Fedora 26 development cycle.
Changing version to '26'.

This was all working before the rebuild, but in that same timeframe gjs was upgraded, and the world was rebuilt with gcc7. So last week I also saw that gjs, firefox and quite a number of other things were no longer working. My plan is to start working through these issues.

Just to be clear here, I don't think the problems I see are related to 48-bit VAs.

That is because they are missing the 48-bit VA crash related signature. To expand upon this, crashes that are likely the result of 48-bit VAs are generally accesses to addresses that have their 47th address bit cleared. This is the result of pointer manipulations that incorrectly clear the 47th bit out of a valid address with that bit set. Futhermore these kinds of crashes can be fixed by rebooting to a 42-bit VA kernel. 

I don't see this behavior at the moment.

I should be consistent with my terminology. To clear up any confusion there with 48bit VA's valid user addresses might look like:

ffff9bae0000-ffffa2680000 r--p 00000000 08:04 17225985                   /usr/lib/locale/locale-archive
ffffc8e10000-ffffc8e40000 rw-p 00000000 00:00 0                          [stack]


In /proc/pid/maps.

An invalid stack access that faults would then look like:

fault @ 7FFFC8E30000, because the real address should be FFFFC8E30000 but someone cleared the 48th bit.

I have opened an additional bug about the gnome-shell/llvmpipe crash.

https://bugzilla.redhat.com/show_bug.cgi?id=1429050

On 2017-May-16 we reached the "Change Checkpoint: 100% Code Complete Deadline" milestone for Fedora 26 release. At this point all the Changes not at least in "ON_QA" state should be brought to FESCo for review. Please update the state of this bug to "ON_QA" if it is already 100% completed. Please let me know in case you have any trouble with the implementation and the Change needs any help or review.

Thanks, Jan

This Change is going to be reviewed on a FESCo meeting: https://pagure.io/fesco/issue/1710

Sorry, sort of new to the whole process.

[root@mammon-juno-f26 ~]# uname -a
Linux mammon-juno-f26.localdomain 4.11.0-2.fc26.aarch64 #1 SMP Tue May 9 15:09:58 UTC 2017 aarch64 aarch64 aarch64 GNU/Linux
[root@mammon-juno-f26 ~]# cat /proc/1/maps |grep stack
fffffe24b000-fffffe26c000 rw-p 00000000 00:00 0                          [stack]


I'm going to mark it verified as well.

I have added release notes text for this change to the draft F26 Release Notes here: https://pagure.io/release-notes/c/f28baf7c9f5482fe31a40d200f44ee70284f0eee?branch=f26

Please would you take a look at the draft and let me know if anything should be added or changed?

Sorry about the delay (OoO without data for a week or so). 

Anyway, the description refrenced in the change looks good.

Thanks,