GNU bug report logs -
#46111
Reverting fns.c hash function due to OpenBSD/SPARC64 compile breaking
Previous Next
Reported by: Ahmed Khanzada <me <at> enzu.ru>
Date: Tue, 26 Jan 2021 09:07:01 UTC
Severity: normal
Done: Stefan Monnier <monnier <at> iro.umontreal.ca>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 46111 in the body.
You can then email your comments to 46111 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46111; Package
emacs.
(Tue, 26 Jan 2021 09:07:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Ahmed Khanzada <me <at> enzu.ru>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Tue, 26 Jan 2021 09:07:01 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
I'm not an expert on C, OpenBSD, or SPARC64, but I did notice
emacs-current was not compiling.
During a gmake, bootstrap-emacs would get a SIGBUS and fail. Running
gdb led me to the hash_string function where it seemed to be failing.
Reverting the hash_string function to a previous version seems to have
fixed the issue.
If I had to guess, it may have something to do with SPARC64 alignment.
I don't have an updated AMD64 OpenBSD box running at the moment, but if you
would like me to test there, I could find a way.
I understand that reverting this function might not be the best way
forward, but wrote a patch just in case that reverts hash_string to an
earlier version that compiles on OpenBSD/SPARC64.
I am already signed all my GNU contributor docs.
--[[text/plain; type=patch; name="0001-Reverting-hash_string-function-due-to-problem-on-Ope.patch"
Content-Disposition: attachment; filename="0001-Reverting-hasattach filh_string-function-due-to-problem-on-Ope.patch"][base64]]
RnJvbSBkOTM4NzQ1Y2U1NjA1OGJlMjQwNzhlYzUyZDk3Mzk4Njk3ZGI0Yjc2IE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBBaG1lZCBLaGFuemFkYSA8bWVAZW56dS5ydT4KRGF0ZTogTW9u
LCAyNSBKYW4gMjAyMSAyMToxNjo0OCAtMDgwMApTdWJqZWN0OiBbUEFUQ0hdIFJldmVydGluZyBo
YXNoX3N0cmluZyBmdW5jdGlvbiBkdWUgdG8gcHJvYmxlbSBvbgogT3BlbkJTRC9TUEFSQzY0Cgot
LS0KIHNyYy9mbnMuYyB8IDMyICsrKysrKystLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCiAxIGZp
bGUgY2hhbmdlZCwgNyBpbnNlcnRpb25zKCspLCAyNSBkZWxldGlvbnMoLSkKCmRpZmYgLS1naXQg
YS9zcmMvZm5zLmMgYi9zcmMvZm5zLmMKaW5kZXggN2FiMmU4ZjFhMC4uMDEyN2ZlM2Y0OCAxMDA2
NDQKLS0tIGEvc3JjL2Zucy5jCisrKyBiL3NyYy9mbnMuYwpAQCAtNDU5OSwzNCArNDU5OSwxNiBA
QCAjZGVmaW5lIFNYSEFTSF9NQVhfTEVOICAgNwogRU1BQ1NfVUlOVAogaGFzaF9zdHJpbmcgKGNo
YXIgY29uc3QgKnB0ciwgcHRyZGlmZl90IGxlbikKIHsKLSAgRU1BQ1NfVUlOVCBjb25zdCAqcCAg
ID0gKEVNQUNTX1VJTlQgY29uc3QgKikgcHRyOwotICBFTUFDU19VSU5UIGNvbnN0ICplbmQgPSAo
RU1BQ1NfVUlOVCBjb25zdCAqKSAocHRyICsgbGVuKTsKLSAgRU1BQ1NfVUlOVCBoYXNoID0gbGVu
OwotICAvKiBBdCBtb3N0IDggc3RlcHMuICBXZSBjb3VsZCByZXVzZSBTWEhBU0hfTUFYX0xFTiwg
b2YgY291cnNlLAotICAgKiBidXQgZGl2aWRpbmcgYnkgOCBpcyBjaGVhcGVyLiAgKi8KLSAgcHRy
ZGlmZl90IHN0ZXAgPSAxICsgKChlbmQgLSBwKSA+PiAzKTsKLQotICAvKiBCZXdhcmU6IGBlbmRg
IG1pZ2h0IGJlIHVuYWxpZ25lZCwgc28gYHAgPCBlbmRgIGlzIG5vdCBhbHdheXMgdGhlIHNhbWUK
LSAgICogYXMgYHAgPD0gZW5kIC0gMWAuICAqLwotICB3aGlsZSAocCA8PSBlbmQgLSAxKQorICBj
aGFyIGNvbnN0ICpwID0gcHRyOworICBjaGFyIGNvbnN0ICplbmQgPSBwICsgbGVuOworICB1bnNp
Z25lZCBjaGFyIGM7CisgIEVNQUNTX1VJTlQgaGFzaCA9IDA7CisKKyAgd2hpbGUgKHAgIT0gZW5k
KQogICAgIHsKLSAgICAgIEVNQUNTX1VJTlQgYyA9ICpwOwotICAgICAgcCArPSBzdGVwOworICAg
ICAgYyA9ICpwKys7CiAgICAgICBoYXNoID0gc3hoYXNoX2NvbWJpbmUgKGhhc2gsIGMpOwogICAg
IH0KLSAgaWYgKHAgPCBlbmQpCi0gICAgeyAvKiBBIGZldyBsYXN0IGJ5dGVzIHJlbWFpbiAoc21h
bGxlciB0aGFuIGFuIEVNQUNTX1VJTlQpLiAgKi8KLSAgICAgIC8qIEZJWE1FOiBXZSBjb3VsZCBk
byB0aGlzIHdpdGhvdXQgYSBsb29wLCBidXQgaXQnZCByZXF1aXJlCi0gICAgICAgICBlbmRpYW4t
ZGVwZW5kZW50IGNvZGUgOi0oICAqLwotICAgICAgY2hhciBjb25zdCAqcDEgPSAoY2hhciBjb25z
dCAqKXA7Ci0gICAgICBjaGFyIGNvbnN0ICplbmQxID0gKGNoYXIgY29uc3QgKillbmQ7Ci0gICAg
ICBkbwotICAgICAgICB7Ci0gICAgICAgICAgdW5zaWduZWQgY2hhciBjID0gKnAxKys7Ci0gICAg
ICAgICAgaGFzaCA9IHN4aGFzaF9jb21iaW5lIChoYXNoLCBjKTsKLSAgICAgICAgfQotICAgICAg
d2hpbGUgKHAxIDwgZW5kMSk7Ci0gICAgfQogCiAgIHJldHVybiBoYXNoOwogfQotLSAKMi4yOC4w
Cgo=
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46111; Package
emacs.
(Tue, 26 Jan 2021 09:25:01 GMT)
Full text and
rfc822 format available.
Message #8 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Not sure if the patch attached correctly. Trying again.
On Mon, Jan 25, 2021 at 10:37 PM Ahmed Khanzada <me <at> enzu.ru> wrote:
>
> I'm not an expert on C, OpenBSD, or SPARC64, but I did notice
> emacs-current was not compiling.
>
> During a gmake, bootstrap-emacs would get a SIGBUS and fail. Running
> gdb led me to the hash_string function where it seemed to be failing.
>
> Reverting the hash_string function to a previous version seems to have
> fixed the issue.
>
> If I had to guess, it may have something to do with SPARC64 alignment.
>
> I don't have an updated AMD64 OpenBSD box running at the moment, but if you
> would like me to test there, I could find a way.
>
> I understand that reverting this function might not be the best way
> forward, but wrote a patch just in case that reverts hash_string to an
> earlier version that compiles on OpenBSD/SPARC64.
>
> I am already signed all my GNU contributor docs.
>
> --[[text/plain; type=patch; name="0001-Reverting-hash_string-function-due-to-problem-on-Ope.patch"
> Content-Disposition: attachment; filename="0001-Reverting-hasattach filh_string-function-due-to-problem-on-Ope.patch"][base64]]
> RnJvbSBkOTM4NzQ1Y2U1NjA1OGJlMjQwNzhlYzUyZDk3Mzk4Njk3ZGI0Yjc2IE1vbiBTZXAgMTcg
> MDA6MDA6MDAgMjAwMQpGcm9tOiBBaG1lZCBLaGFuemFkYSA8bWVAZW56dS5ydT4KRGF0ZTogTW9u
> LCAyNSBKYW4gMjAyMSAyMToxNjo0OCAtMDgwMApTdWJqZWN0OiBbUEFUQ0hdIFJldmVydGluZyBo
> YXNoX3N0cmluZyBmdW5jdGlvbiBkdWUgdG8gcHJvYmxlbSBvbgogT3BlbkJTRC9TUEFSQzY0Cgot
> LS0KIHNyYy9mbnMuYyB8IDMyICsrKysrKystLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCiAxIGZp
> bGUgY2hhbmdlZCwgNyBpbnNlcnRpb25zKCspLCAyNSBkZWxldGlvbnMoLSkKCmRpZmYgLS1naXQg
> YS9zcmMvZm5zLmMgYi9zcmMvZm5zLmMKaW5kZXggN2FiMmU4ZjFhMC4uMDEyN2ZlM2Y0OCAxMDA2
> NDQKLS0tIGEvc3JjL2Zucy5jCisrKyBiL3NyYy9mbnMuYwpAQCAtNDU5OSwzNCArNDU5OSwxNiBA
> QCAjZGVmaW5lIFNYSEFTSF9NQVhfTEVOICAgNwogRU1BQ1NfVUlOVAogaGFzaF9zdHJpbmcgKGNo
> YXIgY29uc3QgKnB0ciwgcHRyZGlmZl90IGxlbikKIHsKLSAgRU1BQ1NfVUlOVCBjb25zdCAqcCAg
> ID0gKEVNQUNTX1VJTlQgY29uc3QgKikgcHRyOwotICBFTUFDU19VSU5UIGNvbnN0ICplbmQgPSAo
> RU1BQ1NfVUlOVCBjb25zdCAqKSAocHRyICsgbGVuKTsKLSAgRU1BQ1NfVUlOVCBoYXNoID0gbGVu
> OwotICAvKiBBdCBtb3N0IDggc3RlcHMuICBXZSBjb3VsZCByZXVzZSBTWEhBU0hfTUFYX0xFTiwg
> b2YgY291cnNlLAotICAgKiBidXQgZGl2aWRpbmcgYnkgOCBpcyBjaGVhcGVyLiAgKi8KLSAgcHRy
> ZGlmZl90IHN0ZXAgPSAxICsgKChlbmQgLSBwKSA+PiAzKTsKLQotICAvKiBCZXdhcmU6IGBlbmRg
> IG1pZ2h0IGJlIHVuYWxpZ25lZCwgc28gYHAgPCBlbmRgIGlzIG5vdCBhbHdheXMgdGhlIHNhbWUK
> LSAgICogYXMgYHAgPD0gZW5kIC0gMWAuICAqLwotICB3aGlsZSAocCA8PSBlbmQgLSAxKQorICBj
> aGFyIGNvbnN0ICpwID0gcHRyOworICBjaGFyIGNvbnN0ICplbmQgPSBwICsgbGVuOworICB1bnNp
> Z25lZCBjaGFyIGM7CisgIEVNQUNTX1VJTlQgaGFzaCA9IDA7CisKKyAgd2hpbGUgKHAgIT0gZW5k
> KQogICAgIHsKLSAgICAgIEVNQUNTX1VJTlQgYyA9ICpwOwotICAgICAgcCArPSBzdGVwOworICAg
> ICAgYyA9ICpwKys7CiAgICAgICBoYXNoID0gc3hoYXNoX2NvbWJpbmUgKGhhc2gsIGMpOwogICAg
> IH0KLSAgaWYgKHAgPCBlbmQpCi0gICAgeyAvKiBBIGZldyBsYXN0IGJ5dGVzIHJlbWFpbiAoc21h
> bGxlciB0aGFuIGFuIEVNQUNTX1VJTlQpLiAgKi8KLSAgICAgIC8qIEZJWE1FOiBXZSBjb3VsZCBk
> byB0aGlzIHdpdGhvdXQgYSBsb29wLCBidXQgaXQnZCByZXF1aXJlCi0gICAgICAgICBlbmRpYW4t
> ZGVwZW5kZW50IGNvZGUgOi0oICAqLwotICAgICAgY2hhciBjb25zdCAqcDEgPSAoY2hhciBjb25z
> dCAqKXA7Ci0gICAgICBjaGFyIGNvbnN0ICplbmQxID0gKGNoYXIgY29uc3QgKillbmQ7Ci0gICAg
> ICBkbwotICAgICAgICB7Ci0gICAgICAgICAgdW5zaWduZWQgY2hhciBjID0gKnAxKys7Ci0gICAg
> ICAgICAgaGFzaCA9IHN4aGFzaF9jb21iaW5lIChoYXNoLCBjKTsKLSAgICAgICAgfQotICAgICAg
> d2hpbGUgKHAxIDwgZW5kMSk7Ci0gICAgfQogCiAgIHJldHVybiBoYXNoOwogfQotLSAKMi4yOC4w
> Cgo=
[0001-Reverting-hash_string-function-due-to-problem-on-Ope.patch (application/octet-stream, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46111; Package
emacs.
(Tue, 26 Jan 2021 09:37:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 46111 <at> debbugs.gnu.org (full text, mbox):
Am Di., 26. Jan. 2021 um 10:07 Uhr schrieb Ahmed Khanzada <me <at> enzu.ru>:
>
> I'm not an expert on C, OpenBSD, or SPARC64, but I did notice
> emacs-current was not compiling.
>
> During a gmake, bootstrap-emacs would get a SIGBUS and fail. Running
> gdb led me to the hash_string function where it seemed to be failing.
The culprit might be commit be0f2de179235980b5409d5e77577207b93a4f12.
I don't think that something like
EMACS_UINT const *p = (EMACS_UINT const *) ptr;
is legal on any platform; it just happens to work on forgiving
platforms such as x86-64.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46111; Package
emacs.
(Tue, 26 Jan 2021 11:13:01 GMT)
Full text and
rfc822 format available.
Message #14 received at submit <at> debbugs.gnu.org (full text, mbox):
On January 26, 2021 11:36:25 AM GMT+02:00, Philipp Stephani <p.stephani2 <at> gmail.com> wrote:
> Am Di., 26. Jan. 2021 um 10:07 Uhr schrieb Ahmed Khanzada
> <me <at> enzu.ru>:
> >
> > I'm not an expert on C, OpenBSD, or SPARC64, but I did notice
> > emacs-current was not compiling.
> >
> > During a gmake, bootstrap-emacs would get a SIGBUS and fail. Running
> > gdb led me to the hash_string function where it seemed to be
> failing.
>
>
> The culprit might be commit be0f2de179235980b5409d5e77577207b93a4f12.
> I don't think that something like
> EMACS_UINT const *p = (EMACS_UINT const *) ptr;
> is legal on any platform; it just happens to work on forgiving
> platforms such as x86-64.
It's definitely legal, as it doesn't violate any laws...
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46111; Package
emacs.
(Tue, 26 Jan 2021 11:13:01 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46111; Package
emacs.
(Tue, 26 Jan 2021 11:16:02 GMT)
Full text and
rfc822 format available.
Message #20 received at submit <at> debbugs.gnu.org (full text, mbox):
On January 26, 2021 8:57:18 AM GMT+02:00, Ahmed Khanzada <me <at> enzu.ru> wrote:
> Not sure if the patch attached correctly. Trying again.
Thanks. However, could you please show the C-level backtrace from the SIGBUS crash, as displayed by GDB? I think we'd like to know which string has its data unaligned to cause this.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46111; Package
emacs.
(Tue, 26 Jan 2021 11:16:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46111; Package
emacs.
(Tue, 26 Jan 2021 11:18:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 46111 <at> debbugs.gnu.org (full text, mbox):
On Jan 26 2021, Eli Zaretskii wrote:
> It's definitely legal, as it doesn't violate any laws...
It violates the laws of C.
Andreas.
--
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46111; Package
emacs.
(Tue, 26 Jan 2021 11:45:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 46111 <at> debbugs.gnu.org (full text, mbox):
On January 26, 2021 1:17:06 PM GMT+02:00, Andreas Schwab <schwab <at> linux-m68k.org> wrote:
> On Jan 26 2021, Eli Zaretskii wrote:
>
> > It's definitely legal, as it doesn't violate any laws...
>
> It violates the laws of C.
We call that "invalid" not "illegal".
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46111; Package
emacs.
(Tue, 26 Jan 2021 11:50:02 GMT)
Full text and
rfc822 format available.
Message #32 received at 46111 <at> debbugs.gnu.org (full text, mbox):
On Jan 26 2021, Eli Zaretskii wrote:
> On January 26, 2021 1:17:06 PM GMT+02:00, Andreas Schwab <schwab <at> linux-m68k.org> wrote:
>> On Jan 26 2021, Eli Zaretskii wrote:
>>
>> > It's definitely legal, as it doesn't violate any laws...
>>
>> It violates the laws of C.
>
> We call that "invalid" not "illegal".
It's still a bug.
Andreas.
--
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46111; Package
emacs.
(Tue, 26 Jan 2021 15:37:01 GMT)
Full text and
rfc822 format available.
Message #35 received at 46111 <at> debbugs.gnu.org (full text, mbox):
> From: Andreas Schwab <schwab <at> linux-m68k.org>
> Cc: 46111 <at> debbugs.gnu.org, p.stephani2 <at> gmail.com, me <at> enzu.ru
> Date: Tue, 26 Jan 2021 12:49:44 +0100
>
> On Jan 26 2021, Eli Zaretskii wrote:
>
> > On January 26, 2021 1:17:06 PM GMT+02:00, Andreas Schwab <schwab <at> linux-m68k.org> wrote:
> >> On Jan 26 2021, Eli Zaretskii wrote:
> >>
> >> > It's definitely legal, as it doesn't violate any laws...
> >>
> >> It violates the laws of C.
> >
> > We call that "invalid" not "illegal".
>
> It's still a bug.
That goes without saying: a crash is always a bug.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46111; Package
emacs.
(Wed, 27 Jan 2021 07:43:02 GMT)
Full text and
rfc822 format available.
Message #38 received at 46111 <at> debbugs.gnu.org (full text, mbox):
[[[ To any NSA and FBI agents reading my email: please consider ]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> It violates the laws of C.
C is not a government, and neither is the ISO C Committee.
Breaking the rules of C is not illegal.
Indeed, GNU C goes against the standard in some simple ways
unless you specify options such as --pedantic.
--
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46111; Package
emacs.
(Wed, 27 Jan 2021 08:25:02 GMT)
Full text and
rfc822 format available.
Message #41 received at 46111 <at> debbugs.gnu.org (full text, mbox):
On Jan 27 2021, Richard Stallman wrote:
> Breaking the rules of C is not illegal.
If it breaks, you get to keep both pieces.
Andreas.
--
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46111; Package
emacs.
(Thu, 28 Jan 2021 04:07:01 GMT)
Full text and
rfc822 format available.
Message #44 received at submit <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> On January 26, 2021 8:57:18 AM GMT+02:00, Ahmed Khanzada <me <at> enzu.ru> wrote:
>> Not sure if the patch attached correctly. Trying again.
>
>
> Thanks. However, could you please show the C-level backtrace from the SIGBUS crash, as displayed by GDB? I think we'd like to know which string has its data unaligned to cause this.
Is the log below the information that you are looking for?
Starting program: /home/enzuru/src/emacs/src/bootstrap-emacs
Breakpoint 1, hash_string (ptr=0x47fa34d596 "DndProtocol", len=11) at
fns.c:4602
4602 EMACS_UINT const *p = (EMACS_UINT const *) ptr;
(gdb) info args
ptr = 0x47fa34d596 "DndProtocol"
len = 11
(gdb) next
4603 EMACS_UINT const *end = (EMACS_UINT const *) (ptr + len);
(gdb) next
4604 EMACS_UINT hash = len;
(gdb) next
4607 ptrdiff_t step = 1 + ((end - p) >> 3);
(gdb) next
4611 while (p <= end - 1)
(gdb) next
4613 EMACS_UINT c = *p;
(gdb) next
Program received signal SIGBUS, Bus error.
0x000000455fe1dc6c in hash_string (ptr=0x47fa34d596 "DndProtocol",
len=11) at fns.c:4613
4613 EMACS_UINT c = *p;
(gdb) backtrace
#0 0x000000455fe1dc6c in hash_string (ptr=0x47fa34d596 "DndProtocol",
len=11) at fns.c:4613
#1 0x000000455fe1dd48 in sxhash_string (ptr=0x47fa34d596 "DndProtocol",
len=11) at fns.c:4640
#2 0x000000455fe1e36c in sxhash_obj (obj=0x47fa02f0bc, depth=0) at
fns.c:4759
#3 0x000000455fe1e270 in sxhash (obj=0x47fa02f0bc) at fns.c:4741
#4 0x000000455fe1c52c in hashfn_equal (key=0x47fa02f0bc,
h=0x47fa02eff0) at fns.c:4096
#5 0x000000455fe1cf44 in hash_table_rehash (hash=0x47fa02eff5) at
fns.c:4342
#6 0x000000455fdc5264 in hash_table_thaw (hash=0x47fa02eff5) at
pdumper.c:2652
#7 0x000000455fdcd184 in thaw_hash_tables () at pdumper.c:5477
#8 0x000000455fdcccf0 in pdumper_load (dump_filename=0x4832495d00
"/home/enzuru/src/emacs/src/bootstrap-emacs.pdmp") at pdumper.c:5405
#9 0x000000455fcea4ac in load_pdump (argc=1, argv=0xffffffffffff2968)
at emacs.c:859
#10 0x000000455fceabec in main (argc=1, argv=0xffffffffffff2968) at
emacs.c:1067
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46111; Package
emacs.
(Thu, 28 Jan 2021 04:07:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46111; Package
emacs.
(Thu, 28 Jan 2021 13:59:01 GMT)
Full text and
rfc822 format available.
Message #50 received at 46111 <at> debbugs.gnu.org (full text, mbox):
> From: Ahmed Khanzada <me <at> enzu.ru>
> Cc:
> Date: Wed, 27 Jan 2021 20:06:01 -0800
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > Thanks. However, could you please show the C-level backtrace from the SIGBUS crash, as displayed by GDB? I think we'd like to know which string has its data unaligned to cause this.
>
> Is the log below the information that you are looking for?
Yes, thanks.
> 4613 EMACS_UINT c = *p;
> (gdb) next
>
> Program received signal SIGBUS, Bus error.
> 0x000000455fe1dc6c in hash_string (ptr=0x47fa34d596 "DndProtocol",
> len=11) at fns.c:4613
> 4613 EMACS_UINT c = *p;
> (gdb) backtrace
> #0 0x000000455fe1dc6c in hash_string (ptr=0x47fa34d596 "DndProtocol",
> len=11) at fns.c:4613
> #1 0x000000455fe1dd48 in sxhash_string (ptr=0x47fa34d596 "DndProtocol",
> len=11) at fns.c:4640
> #2 0x000000455fe1e36c in sxhash_obj (obj=0x47fa02f0bc, depth=0) at
> fns.c:4759
> #3 0x000000455fe1e270 in sxhash (obj=0x47fa02f0bc) at fns.c:4741
> #4 0x000000455fe1c52c in hashfn_equal (key=0x47fa02f0bc,
> h=0x47fa02eff0) at fns.c:4096
> #5 0x000000455fe1cf44 in hash_table_rehash (hash=0x47fa02eff5) at
> fns.c:4342
> #6 0x000000455fdc5264 in hash_table_thaw (hash=0x47fa02eff5) at
> pdumper.c:2652
> #7 0x000000455fdcd184 in thaw_hash_tables () at pdumper.c:5477
Stefan, any ideas?
One possibility is to use memcpy instead of dereferencing a pointer.
We could do that either unconditionally or when the original pointer
is not aligned on 4/8-byte boundary.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46111; Package
emacs.
(Thu, 28 Jan 2021 15:10:01 GMT)
Full text and
rfc822 format available.
Message #53 received at 46111 <at> debbugs.gnu.org (full text, mbox):
> Starting program: /home/enzuru/src/emacs/src/bootstrap-emacs
>
> Breakpoint 1, hash_string (ptr=0x47fa34d596 "DndProtocol", len=11) at
> fns.c:4602
> 4602 EMACS_UINT const *p = (EMACS_UINT const *) ptr;
> (gdb) info args
> ptr = 0x47fa34d596 "DndProtocol"
> len = 11
> (gdb) next
> 4603 EMACS_UINT const *end = (EMACS_UINT const *) (ptr + len);
> (gdb) next
> 4604 EMACS_UINT hash = len;
> (gdb) next
> 4607 ptrdiff_t step = 1 + ((end - p) >> 3);
> (gdb) next
> 4611 while (p <= end - 1)
> (gdb) next
> 4613 EMACS_UINT c = *p;
> (gdb) next
>
> Program received signal SIGBUS, Bus error.
Hmm... so it's doing a dereference at address 0x47fa34d596 and getting
a bus error?
I have two questions here:
- I'd guess that the bus error is due to alignment restrictions.
What hardware is this running on? Last I checked, the computer
architecture community had agreed (many years ago already) that
(except for very small CPUs maybe, those not able to run Emacs) it's
better to have the hardware support unaligned memory accesses (it took
more time to get there than the consensus on branch delay slots,
admittedly), so I'd be curious if there is still moderately recent
hardware that insists on signaling an error.
- AFAICT from the backtrace, `ptr` points to a plain normal ELisp
string's content, yet these are supposed to be aligned, so what's
going on here (this question is not directed at you ;-)
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46111; Package
emacs.
(Thu, 28 Jan 2021 15:20:02 GMT)
Full text and
rfc822 format available.
Message #56 received at 46111 <at> debbugs.gnu.org (full text, mbox):
> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: eliz <at> gnu.org, 46111 <at> debbugs.gnu.org
> Date: Thu, 28 Jan 2021 10:09:21 -0500
>
> Hmm... so it's doing a dereference at address 0x47fa34d596 and getting
> a bus error?
Yes.
> I have two questions here:
>
> - I'd guess that the bus error is due to alignment restrictions.
> What hardware is this running on?
See the Subject: it's SPARC64.
> - AFAICT from the backtrace, `ptr` points to a plain normal ELisp
> string's content, yet these are supposed to be aligned, so what's
> going on here
I wondered that myself.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46111; Package
emacs.
(Thu, 28 Jan 2021 15:45:02 GMT)
Full text and
rfc822 format available.
Message #59 received at 46111 <at> debbugs.gnu.org (full text, mbox):
>> - I'd guess that the bus error is due to alignment restrictions.
>> What hardware is this running on?
> See the Subject: it's SPARC64.
I mean the actual hardware, not the architecture.
[ I know most RISC processors started with a restriction that they only
allowed aligned memory accesses, but AFAIK they've changed stance
since (IIUC the extra hardware can be very little, sometimes even less
than the hardware that would be needed to implement the ad-hoc
"support instructions" used to do the unaligned access as a sequence
of instructions).
It's one of the RISC simplifications that just didn't pan out. ]
>> - AFAICT from the backtrace, `ptr` points to a plain normal ELisp
>> string's content, yet these are supposed to be aligned, so what's
>> going on here
> I wondered that myself.
And what did you conclude? ;-)
Stef
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46111; Package
emacs.
(Thu, 28 Jan 2021 15:53:02 GMT)
Full text and
rfc822 format available.
Message #62 received at 46111 <at> debbugs.gnu.org (full text, mbox):
>>> - AFAICT from the backtrace, `ptr` points to a plain normal ELisp
>>> string's content, yet these are supposed to be aligned, so what's
>>> going on here
>> I wondered that myself.
> And what did you conclude? ;-)
Hmm... now that I think about it, I think `make_pure_string` may get us
there, because the string's content is allocated from the end without
any alignment!
And the backtrace shows we're hashing the string `DndProtocol` which
comes from `lisp/x-dnd.el` which is indeed preloaded, so I think that's
what's going on.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46111; Package
emacs.
(Thu, 28 Jan 2021 16:05:02 GMT)
Full text and
rfc822 format available.
Message #65 received at 46111 <at> debbugs.gnu.org (full text, mbox):
On Jan 28 2021, Stefan Monnier wrote:
>>> - I'd guess that the bus error is due to alignment restrictions.
>>> What hardware is this running on?
>> See the Subject: it's SPARC64.
>
> I mean the actual hardware, not the architecture.
Strict alignment is a property of the architecture, not the hardware.
Andreas.
--
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46111; Package
emacs.
(Thu, 28 Jan 2021 16:15:02 GMT)
Full text and
rfc822 format available.
Message #68 received at 46111 <at> debbugs.gnu.org (full text, mbox):
Andreas Schwab [2021-01-28 17:04:19] wrote:
> On Jan 28 2021, Stefan Monnier wrote:
>
>>>> - I'd guess that the bus error is due to alignment restrictions.
>>>> What hardware is this running on?
>>> See the Subject: it's SPARC64.
>>
>> I mean the actual hardware, not the architecture.
>
> Strict alignment is a property of the architecture, not the hardware.
IIRC some RISC architectures *allowed* errors on unaligned memory
accesses without requiring it, making it a property of the hardware.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46111; Package
emacs.
(Thu, 28 Jan 2021 16:18:01 GMT)
Full text and
rfc822 format available.
Message #71 received at 46111 <at> debbugs.gnu.org (full text, mbox):
> And the backtrace shows we're hashing the string `DndProtocol` which
> comes from `lisp/x-dnd.el` which is indeed preloaded, so I think that's
> what's going on.
Could you try the patch below?
Stefan
diff --git a/src/fns.c b/src/fns.c
index 7ab2e8f1a0..0c6bb770ef 100644
--- a/src/fns.c
+++ b/src/fns.c
@@ -4610,7 +4610,20 @@ hash_string (char const *ptr, ptrdiff_t len)
* as `p <= end - 1`. */
while (p <= end - 1)
{
+ /* Here `p` is *almost* always be properly aligned, so we want to
+ optimize for the aligned case, but we still need to support the
+ non-aligned case. */
+ /* FIXME: Could we just always use `memcpy` and rely on GCC optimizing
+ it to a single word-sized memory access on all-but-sparc64? */
+#ifdef __sparc64__ /* Arch that still insists on aligned memory accesses. */
+ EMACS_UINT c;
+ if (!((unsigned long)p) % sizeof (c))
+ c = *p;
+ else
+ memcpy (&c, (char const *)p, sizeof (c)); /* `p` is unaligned! */
+#else
EMACS_UINT c = *p;
+#fi
p += step;
hash = sxhash_combine (hash, c);
}
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46111; Package
emacs.
(Thu, 28 Jan 2021 16:23:01 GMT)
Full text and
rfc822 format available.
Message #74 received at 46111 <at> debbugs.gnu.org (full text, mbox):
On Jan 28 2021, Stefan Monnier wrote:
> +#ifdef __sparc64__ /* Arch that still insists on aligned memory accesses. */
$ git grep -E '#define +STRICT_ALIGNMENT +1' -- gcc/config | wc -l
35
Andreas.
--
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46111; Package
emacs.
(Thu, 28 Jan 2021 17:23:02 GMT)
Full text and
rfc822 format available.
Message #77 received at 46111 <at> debbugs.gnu.org (full text, mbox):
> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Date: Thu, 28 Jan 2021 11:17:31 -0500
> Cc: 46111 <at> debbugs.gnu.org
>
> + /* Here `p` is *almost* always be properly aligned, so we want to
> + optimize for the aligned case, but we still need to support the
> + non-aligned case. */
> + /* FIXME: Could we just always use `memcpy` and rely on GCC optimizing
> + it to a single word-sized memory access on all-but-sparc64? */
> +#ifdef __sparc64__ /* Arch that still insists on aligned memory accesses. */
> + EMACS_UINT c;
> + if (!((unsigned long)p) % sizeof (c))
> + c = *p;
> + else
> + memcpy (&c, (char const *)p, sizeof (c)); /* `p` is unaligned! */
> +#else
> EMACS_UINT c = *p;
> +#fi
AFAIK, memcpy itself optimizes: once it gets to aligned address, it
starts copying words instead of bytes. So I'm not sure we need either
#ifdef or the run-time condition. I suggest to time both variants on
x86 architecture, to see whether there's any performance hit due to
use of memcpy, and if not, use memcpy always -- it will let us have
the cake and eat it, too.
Reply sent
to
Stefan Monnier <monnier <at> iro.umontreal.ca>:
You have taken responsibility.
(Thu, 28 Jan 2021 17:31:01 GMT)
Full text and
rfc822 format available.
Notification sent
to
Ahmed Khanzada <me <at> enzu.ru>:
bug acknowledged by developer.
(Thu, 28 Jan 2021 17:31:02 GMT)
Full text and
rfc822 format available.
Message #82 received at 46111-done <at> debbugs.gnu.org (full text, mbox):
> AFAIK, memcpy itself optimizes: once it gets to aligned address, it
> starts copying words instead of bytes.
I don't know what this `memcpy` code expands to on sparc64, but since it
turns into a plain `mov` on x86, I simplified the code to always use
`memcpy`.
Stefan
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Fri, 26 Feb 2021 12:24:05 GMT)
Full text and
rfc822 format available.
This bug report was last modified 3 years and 57 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.