Source: ruby-ferret Version: 0.11.8.6-2 Severity: important User: debian-...@lists.debian.org Usertags: alignment
Hi! I've been doing a full rebuild of the Debian archive, building all source packages targeting armel and armhf using arm64 hardware. We are planning in future to move all of our 32-bit armel/armhf builds to using arm64 machines, so this rebuild is to identify packages that might have problems with this configuration. A feature of the arm64 kernel is that it does *not* support fixing up code with broken alignment, so code that might have built and run OK on our older armel/armhf build machines due to kernel fixups will now fail. When building your package, I've found a bus error (aka alignment fault) on both armel and armhf. The full logs are online at https://www.einval.com/debian/arm/rebuild-logs/armel/FAIL/ruby-ferret_0.11.8.6-2_armel.log https://www.einval.com/debian/arm/rebuild-logs/armhf/FAIL/ruby-ferret_0.11.8.6-2_armhf.log for reference I've done a quick bit of debugging to find the source of the bug. Here's a gdb stacktrace and variable printout to demonstrate the problem. (sid-armhf)steve@mjolnir:~/debian/build/ruby-ferret/ruby-ferret-0.11.8.6$ file core core: ELF 32-bit LSB core file, ARM, version 1 (SYSV), SVR4-style, from 'ruby2.5 debian/ruby-tests.rb', real uid: 1000, effective uid: 1000, real gid: 1000, effective gid: 1000, execfn: '/usr/bin/ruby2.5', platform: 'v8l' (sid-armhf)steve@mjolnir:~/debian/build/ruby-ferret/ruby-ferret-0.11.8.6$ gdb /usr/bin/ruby2.5 core ... Reading symbols from /usr/bin/ruby2.5...(no debugging symbols found)...done. [New LWP 15636] [New LWP 15639] [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1". Core was generated by `ruby2.5 debian/ruby-tests.rb'. Program terminated with signal SIGBUS, Bus error. #0 0xf7975e8e in frt_p_new (mp=mp@entry=0x10c7a98, doc_num=doc_num@entry=0, pos=pos@entry=0) at index.c:5180 5180 return occ; [Current thread is 1 (Thread 0xf7b5c210 (LWP 15636))] (gdb) bt #0 0xf7975e8e in frt_p_new (mp=mp@entry=0x10c7a98, doc_num=doc_num@entry=0, pos=pos@entry=0) at index.c:5180 #1 0xf7975f1c in dw_add_posting (mp=mp@entry=0x10c7a98, curr_plists=curr_plists@entry=0x1121438, fld_plists=fld_plists@entry=0x11a6eb8, doc_num=doc_num@entry=0, text=text@entry=0x11c0c68 "20040601", len=len@entry=8, pos=pos@entry=0) at index.c:5523 #2 0xf797628c in frt_dw_invert_field (dw=dw@entry=0xd22bc0, fld_inv=fld_inv@entry=0xf740075a, df=df@entry=0xf6ece8) at index.c:5587 #3 0xf79763f0 in frt_dw_add_doc (dw=dw@entry=0xd22bc0, doc=doc@entry=0xc80b18) at index.c:5662 #4 0xf79764da in frt_iw_add_doc (iw=iw@entry=0xffc218, doc=doc@entry=0xc80b18) at index.c:6337 #5 0xf7987ff0 in frb_iw_add_doc (self=18250200, rdoc=<optimized out>) at r_index.c:1530 #6 0xf7ec4dfa in ?? () from /usr/lib/arm-linux-gnueabihf/libruby-2.5.so.2.5 Backtrace stopped: previous frame identical to this frame (corrupt stack?) (gdb) p mp $1 = (FrtMemoryPool *) 0x10c7a98 (gdb) p p $2 = (FrtPosting *) 0xf7402e7e (gdb) p *p $3 = {freq = 0, doc_num = 0, first_occ = 0x0, next = 0x0} (gdb) p &p->doc_num $4 = (int *) 0xf7402e82 (gdb) p &p->first_occ $5 = (FrtOccurence **) 0xf7402e86 Ignore the line number 5180 - it looks like gdb is getting the exact line number wrong. The fault is in the function p_new(): Posting *p_new(MemoryPool *mp, int doc_num, int pos) { Posting *p = MP_ALLOC(mp, Posting); p->doc_num = doc_num; p->first_occ = occ_new(mp, pos); p->freq = 1; p->next = NULL; return p; } MP_ALLOC() has returned a misaligned pointer, and the code following here therefore is trying to fill things in misaligned too. p->doc_num is an int, but is not aligned appropriately... -- System Information: Debian Release: 9.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-debug'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-8-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
