Thank you for tracking this down. Revision 1506 is a big commit, and a quite a few lines were changed in AARCH64. Perhaps I created an invalid instruction form.
Could you capture the crash, execute disassemble $pc-64,$pc+64 x/128xw $pc-64 in gdb and send me the output? Seeing the actual instruction might help for me to understand the issue. Regards, Zoltan Petr Pisar <[email protected]> írta: >On Thu, Feb 26, 2015 at 07:13:39PM +0100, Zoltán Herczeg wrote: >> I don't think these are related. The problem is in test2, not in test19 (the >> serialization test). Sparc64 JIT has not implemented yet. ARM 64 supports >> unaligned access, so a possible alignment issue is unusual. Perhaps the >> program counter is executing something from a wrong address. >> >> Petr, please run "gdb --args ./pcre2test -q -S 16 -8 -jit >> ./testdata/testinput2 testtry", and start the program with "r". When it >> crashes, please type "bt 10" and "disassemble $pc-128,$pc+128" and send me >> the output. I think it is enough to send me the dump privately. >> >PCRE-8.37-RC1 smashes the stack: > >$ libtool --mode=execute gdb --args ./pcretest -q -S 16 -8 -s+ >./testdata/testinput2 testtry >[...] >Reading symbols from /home/test/svn-git/.libs/lt-pcretest...done. >(gdb) run >Starting program: /home/test/svn-git/.libs/lt-pcretest -q -S 16 -8 -s+ >./testdata/testinput2 testtry >[Thread debugging using libthread_db enabled] >Using host libthread_db library "/lib64/libthread_db.so.1". > >Program received signal SIGBUS, Bus error. >0x000003ffb7cc0014 in ?? () >(gdb) bt >#0 0x000003ffb7cc0014 in ?? () >#1 0x000003ffffffc950 in ?? () >Backtrace stopped: previous frame inner to this frame (corrupt stack?) > >/proc/PID/maps shows the 0x000003ffb7cc0014 address is in an unnamed region >with rwxp permissions, and the 0x000003ffffffc950 address belongs to the >non-executable stack. > >-- Petr >-- >## List details at https://lists.exim.org/mailman/listinfo/pcre-dev -- ## List details at https://lists.exim.org/mailman/listinfo/pcre-dev
