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 <ppisar@???> í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
