Is it a bug on aarch64 platform

Raymond

unread,

Sep 17, 2021, 3:30:55 AM9/17/21

to DynamoRIO Users

Hello guys,

I am using DR to profile large applications on aarch64 platform and meet a failure.

As per GDB tracking, I think the 'relink_special_ibl_xfer' function maybe not correct.

https://github.com/DynamoRIO/dynamorio/blob/9357d87adb3b13740d682d2524cb70486628e775/core/arch/aarch64/emit_utils.c#L1012

Line 1035-1039 will override/relink the two instructions specified by 'write_pc' which points to the last instruction of the ibl routine, but for my understanding, the second instruction will override the other routine's head/first instruction next to the target ibl routine. It will cause that routine to run failed. Am I right?

Thanks.

John Galea

unread,

Sep 18, 2021, 10:57:42 AM9/18/21

to dynamor...@googlegroups.com

Hi,

Many thanks for this information.

What exactly is the failure, please?

If possible, can you raise an issue on GitHub explaining the bug in detail. Kindly check that no other similar issue has been posted already to avoid duplication.

Thank you,

--
You received this message because you are subscribed to the Google Groups "DynamoRIO Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dynamorio-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dynamorio-users/c946214b-8a04-41b8-9bd2-e395eb10e794n%40googlegroups.com.

assad.hashm...@gmail.com

unread,

Sep 20, 2021, 11:45:27 AM9/20/21

to DynamoRIO Users

Hi,

> the second instruction will override the other routine's head/first

> instruction next to the target ibl routine. It will cause that routine to run

> failed. Am I right?

Looking at relink_special_ibl_xfer() I can't see how the second instruction (br x1) will overwrite the first of the target IBL, for the following reasons:

pc = (uint *)(code->special_ibl_xfer[index] + code->special_ibl_unlink_offs[index]);

allocates 3 areas of memory large enough for the ldr and br instruction pair:

byte *special_ibl_xfer[NUM_SPECIAL_IBL_XFERS];

uint special_ibl_unlink_offs[NUM_SPECIAL_IBL_XFERS];

where NUM_SPECIAL_IBL_XFERS=3

The index input to relink_special_ibl_xfer() selects which of these 3 to use (CLIENT_IBL_IDX=0, NATIVE_PLT_IBL_IDX=1 and NATIVE_RET_IBL_IDX=2) and in each case both ldr and br instructions are written correctly to the pc buffer, according to:

write_pc[0] = (0xf9400000 | 1 | (dr_reg_stolen - DR_REG_X0) << 5 |

get_ibl_entry_tls_offs(dcontext, ibl_tgt) >> 3 << 10);

write_pc[1] = 0xd61f0000 | 1 << 5;

machine_cache_sync(pc, pc + 2, true);

However, if you can provide further information of what actually happens when your application fails, especially if it's related to relink_special_ibl_xfer(), we will look further into this.

Does your GDB run show the br instruction overwriting anything?

Have you run with debug and logging? Do any warning messages provide a clue?

Is there anything in the log file which indicates an IBL link failure? Emitted code like this is dumped to the log.

Derek Bruening

unread,

Sep 21, 2021, 11:29:56 AM9/21/21

to dynamor...@googlegroups.com

I think Raymond is saying that the special_ibl_unlink_offs marker points to the last instruction of that code sequence (the jump), yet AArch64 patches it as though it points to the next-to-last instruction before that jump by writing two instructions, thus clobbering whatever is after that final instruction?

--
You received this message because you are subscribed to the Google Groups "DynamoRIO Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dynamorio-use...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/dynamorio-users/1918631c-a00e-49be-8c7c-ca462d9fe9e0n%40googlegroups.com.

Raymond

unread,

Sep 21, 2021, 9:23:04 PM9/21/21

to DynamoRIO Users

Yes, Derek.

I've checked the ARM version of ‘relink_special_ibl_xfer’.

It relinks the ibl only by one instruction. I think in the AARCH64 mode, it needs two instrucitons to the same thing as AARCH64 cant' load PC directly.

following is the ARM version of the relink.

insert_ldr_tls_to_pc(pc, FRAG_THUMB, get_ibl_entry_tls_offs(dcontext, ibl_tgt));

Sorry for the delay, I'll attach the error log and the gdb on-site error later.

BTW, I'm reading the code of DR workflow, under what scenario it will call 'relink_special_ibl_xfer'.

Raymond

unread,

Sep 25, 2021, 10:47:00 PM9/25/21

to DynamoRIO Users

Hello, sorry for the delay.

Here is the GDB on-site debug flow text:

gdb --args /home/raymond/git/dynamorio/build.debug/bin64/drrun -debug -loglevel 4 -logdir drlog -c /home/raymond/git/dynamorio/build.debug/api/bin/libbbcount.so -- /data/cci/aarch64/libs/gcc9.3.0/hmpi/1.1.0/bin/mpirun --allow-run-as-root --hostfile /home/raymond/wrf/1host_179 -x PATH -x WRFIO_NCD_LARGE_FILE_SUPPORT=1 -x PNETCDF_QUILT=1 -x LD_LIBRARY_PATH -x OMP_NUM_THREADS=4 -x OMP_PLACES=cores -x OMP_PROC_BIND=close -x OMP_DISPLAY_ENV -x OMP_SCHEDULE=static -x OMP_STACKSIZE=1G -x OMP_WAIT_POLICY=active -map-by ppr:32:node:pe=4 -report-bindings -mca pml ucx -mca btl ^vader,tcp,openib,uct -mca io romio321 -x UCX_TLS=self,sm,rc -x UCX_NET_DEVICES=mlx5_0:1 ./wrf.exe

GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-120.el7

License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

This is free software: you are free to change and redistribute it.

There is NO WARRANTY, to the extent permitted by law. Type "show copying"

and "show warranty" for details.

This GDB was configured as "aarch64-redhat-linux-gnu".

For bug reporting instructions, please see:

<http://www.gnu.org/software/gdb/bugs/>...

Reading symbols from /home/raymond/git/dynamorio/build.debug/bin64/drrun...Reading symbols from /home/raymond/git/dynamorio/build.debug/bin64/drrun.debug...done.

done.

(gdb) r

Starting program: /home/raymond/git/dynamorio/build.debug/bin64/drrun -debug -loglevel 4 -logdir drlog -c /home/raymond/git/dynamorio/build.debug/api/bin/libbbcount.so -- /data/cci/aarch64/libs/gcc9.3.0/hmpi/1.1.0/bin/mpirun --allow-run-as-root --hostfile /home/raymond/wrf/1host_179 -x PATH -x WRFIO_NCD_LARGE_FILE_SUPPORT=1 -x PNETCDF_QUILT=1 -x LD_LIBRARY_PATH -x OMP_NUM_THREADS=4 -x OMP_PLACES=cores -x OMP_PROC_BIND=close -x OMP_DISPLAY_ENV -x OMP_SCHEDULE=static -x OMP_STACKSIZE=1G -x OMP_WAIT_POLICY=active -map-by ppr:32:node:pe=4 -report-bindings -mca pml ucx -mca btl \^vader,tcp,openib,uct -mca io romio321 -x UCX_TLS=self,sm,rc -x UCX_NET_DEVICES=mlx5_0:1 ./wrf.exe

process 974 is executing new program: /home/raymond/git/dynamorio/build.debug/lib64/debug/libdynamorio.so

Missing separate debuginfos, use: debuginfo-install glibc-2.17-324.el7_9.aarch64

<log dir=drlog/mpirun.974.00000000>

<Starting application /data/cci/aarch64/libs/gcc9.3.0/hmpi/1.1.0/bin/mpirun (974)>

<Paste into GDB to debug DynamoRIO clients:

set confirm off

add-symbol-file '/home/raymond/git/dynamorio/build.debug/api/bin/libbbcount.so' 0x0000000072001280

add-symbol-file '/home/raymond/git/dynamorio/build.debug/lib64/debug/libdynamorio.so' 0x0000400000015020

add-symbol-file '/home/raymond/git/dynamorio/build.debug/ext/lib64/debug/libdrx.so' 0x0000000077003350

add-symbol-file '/home/raymond/git/dynamorio/build.debug/ext/lib64/debug/libdrreg.so' 0x0000000078002f30

add-symbol-file '/home/raymond/git/dynamorio/build.debug/ext/lib64/debug/libdrmgr.so' 0x0000000073004190

add-symbol-file '/usr/lib64/libc.so.6' 0x000040020054ee10

add-symbol-file '/usr/lib/ld-linux-aarch64.so.1' 0x00004002006d0b60

>

Client bbcount is running

^C

Program received signal SIGINT, Interrupt.

dynamorio_syscall () at /home/raymond/git/dynamorio/core/drlibc/drlibc_aarch64.asm:67

67 DECLARE_FUNC(FUNCNAME)

(gdb) set confirm off

(gdb) add-symbol-file '/home/raymond/git/dynamorio/build.debug/api/bin/libbbcount.so' 0x0000000072001280

add symbol table from file "/home/raymond/git/dynamorio/build.debug/api/bin/libbbcount.so" at

.text_addr = 0x72001280

Reading symbols from /home/raymond/git/dynamorio/build.debug/api/bin/libbbcount.so...Reading symbols from /home/raymond/git/dynamorio/build.debug/api/bin/libbbcount.so.debug...done.

done.

(gdb) add-symbol-file '/home/raymond/git/dynamorio/build.debug/lib64/debug/libdynamorio.so' 0x0000400000015020

add symbol table from file "/home/raymond/git/dynamorio/build.debug/lib64/debug/libdynamorio.so" at

.text_addr = 0x400000015020

Reading symbols from /home/raymond/git/dynamorio/build.debug/lib64/debug/libdynamorio.so...Reading symbols from /home/raymond/git/dynamorio/build.debug/lib64/debug/libdynamorio.so.debug...add-symbol-file '/home/raymond/git/dynamorio/build.debug/ext/lib64/debug/libdrx.so' 0x0000000077003350

add-symbol-file '/home/raymond/git/dynamorio/build.debug/ext/lib64/debug/libdrreg.so' 0x0000000078002f30

add-symbol-file '/home/raymond/git/dynamorio/build.debug/ext/lib64/debug/libdrmgr.so' 0x0000000073004190

add-symbol-file '/usr/lib64/libc.so.6' 0x000040020054ee10

add-symbol-file '/usr/lib/ld-linux-aarch64.so.1' 0x00004002006d0b60done.

done.

(gdb) add-symbol-file '/home/raymond/git/dynamorio/build.debug/ext/lib64/debug/libdrx.so' 0x0000000077003350

add symbol table from file "/home/raymond/git/dynamorio/build.debug/ext/lib64/debug/libdrx.so" at

.text_addr = 0x77003350

Reading symbols from /home/raymond/git/dynamorio/build.debug/ext/lib64/debug/libdrx.so...Reading symbols from /home/raymond/git/dynamorio/build.debug/ext/lib64/debug/libdrx.so.debug...done.

done.

(gdb) add-symbol-file '/home/raymond/git/dynamorio/build.debug/ext/lib64/debug/libdrreg.so' 0x0000000078002f30

add symbol table from file "/home/raymond/git/dynamorio/build.debug/ext/lib64/debug/libdrreg.so" at

.text_addr = 0x78002f30

Reading symbols from /home/raymond/git/dynamorio/build.debug/ext/lib64/debug/libdrreg.so...Reading symbols from /home/raymond/git/dynamorio/build.debug/ext/lib64/debug/libdrreg.so.debug...done.

done.

(gdb) add-symbol-file '/home/raymond/git/dynamorio/build.debug/ext/lib64/debug/libdrmgr.so' 0x0000000073004190

add symbol table from file "/home/raymond/git/dynamorio/build.debug/ext/lib64/debug/libdrmgr.so" at

.text_addr = 0x73004190

Reading symbols from /home/raymond/git/dynamorio/build.debug/ext/lib64/debug/libdrmgr.so...Reading symbols from /home/raymond/git/dynamorio/build.debug/ext/lib64/debug/libdrmgr.so.debug...done.

done.

(gdb) add-symbol-file '/usr/lib64/libc.so.6' 0x000040020054ee10

add symbol table from file "/usr/lib64/libc.so.6" at

.text_addr = 0x40020054ee10

Reading symbols from /usr/lib64/libc-2.17.so...(no debugging symbols found)...done.

Missing separate debuginfos, use: debuginfo-install glibc-2.17-324.el7_9.aarch64

(gdb) add-symbol-file '/usr/lib/ld-linux-aarch64.so.1' 0x00004002006d0b60

add symbol table from file "/usr/lib/ld-linux-aarch64.so.1" at

.text_addr = 0x4002006d0b60

Reading symbols from /usr/lib64/ld-2.17.so...(no debugging symbols found)...done.

(gdb) watch *0x0000000041e424c0

Hardware watchpoint 1: *0x0000000041e424c0

(gdb) c

Continuing.

Hardware watchpoint 1: *0x0000000041e424c0

Old value = -1459615776

New value = -702611424

relink_special_ibl_xfer (dcontext=0xffffffffffffffff, index=0, entry_type=IBL_UNLINKED, ibl_type=IBL_RETURN) at /home/raymond/git/dynamorio/core/arch/aarch64/emit_utils.c:1038

1038 machine_cache_sync(pc, pc + 2, true);

(gdb) i s

#0 relink_special_ibl_xfer (dcontext=0xffffffffffffffff, index=0, entry_type=IBL_UNLINKED, ibl_type=IBL_RETURN) at /home/raymond/git/dynamorio/core/arch/aarch64/emit_utils.c:1038

#1 0x00004000002015e8 in unlink_special_ibl_xfer (dcontext=0xffffffffffffffff) at /home/raymond/git/dynamorio/core/arch/emit_utils_shared.c:5658

#2 0x0000400000056e20 in flush_fragments_synch_priv (dcontext=0x400000575780, base=0x400200f50000 "\177ELF\002\001\001", size=131560, own_initexit_lock=false, thread_synch_callback=0x400000056534 <flush_fragments_thread_unlink>)

at /home/raymond/git/dynamorio/core/fragment.c:6324

#3 0x0000400000057764 in flush_fragments_synch_unlink_priv (dcontext=0x400000575780, base=0x400200f50000 "\177ELF\002\001\001", size=131560, own_initexit_lock=false, exec_invalid=true, force_synchall=false)

at /home/raymond/git/dynamorio/core/fragment.c:6479

#4 0x0000400000058a94 in flush_fragments_in_region_start (dcontext=0x400000575780, base=0x400200f50000 "\177ELF\002\001\001", size=131560, own_initexit_lock=false, free_futures=true, exec_invalid=true, force_synchall=false)

at /home/raymond/git/dynamorio/core/fragment.c:6776

#5 0x0000400000059134 in flush_fragments_and_remove_region (dcontext=0x400000575780, base=0x400200f50000 "\177ELF\002\001\001", size=131560, own_initexit_lock=false, free_futures=true)

at /home/raymond/git/dynamorio/core/fragment.c:6823

#6 0x000040000018174c in app_memory_deallocation (dcontext=0x400000575780, base=0x400200f50000 "\177ELF\002\001\001", size=131560, own_initexit_lock=false, image=true) at /home/raymond/git/dynamorio/core/vmareas.c:6217

#7 0x0000400000340090 in pre_system_call (dcontext=0x400000575780) at /home/raymond/git/dynamorio/core/unix/os.c:6745

#8 0x00004000000b193c in handle_system_call (dcontext=0x400000575780) at /home/raymond/git/dynamorio/core/dispatch.c:2019

#9 0x00004000000a9b7c in dispatch_enter_dynamorio (dcontext=0x400000575780) at /home/raymond/git/dynamorio/core/dispatch.c:917

#10 0x00004000000a5224 in d_r_dispatch (dcontext=0x400000575780) at /home/raymond/git/dynamorio/core/dispatch.c:160

#11 0x00004000004e3ae4 in ?? ()

#12 0x0000400000500988 in ?? ()

Backtrace stopped: previous frame inner to this frame (corrupt stack?)

I add a watch point with the addres 0x0000000041e424c0 which is the 'clean_call_save' routine address from the main log as below.

client_ibl_xfer:

0x0000000041e42480 f9000380 str %x0 -> (%x28)[8byte]

0x0000000041e42484 d28abf00 movz $0x55f8 lsl $0x00 -> %x0

0x0000000041e42488 f2a00740 movk %x0 $0x003a lsl $0x10 -> %x0

0x0000000041e4248c f2c80000 movk %x0 $0x4000 lsl $0x20 -> %x0

0x0000000041e42490 f9000b82 str %x2 -> +0x10(%x28)[8byte]

0x0000000041e42494 f9400f82 ldr +0x18(%x28)[8byte] -> %x2

0x0000000041e42498 f9001785 str %x5 -> +0x28(%x28)[8byte]

0x0000000041e4249c f9401f85 ldr +0x38(%x28)[8byte] -> %x5

0x0000000041e424a0 398e10a5 ldrsb +0x0384(%x5)[1byte] -> %x5

0x0000000041e424a4 b4000085 cbz $0x0000000041e424b4 %x5

0x0000000041e424a8 f9401785 ldr +0x28(%x28)[8byte] -> %x5

0x0000000041e424ac f9404381 ldr +0x80(%x28)[8byte] -> %x1

0x0000000041e424b0 d61f0020 br %x1

0x0000000041e424b4 f9401785 ldr +0x28(%x28)[8byte] -> %x5

0x0000000041e424b8 f9403f81 ldr +0x78(%x28)[8byte] -> %x1

0x0000000041e424bc d61f0020 br %x1

clean_call_save:

0x0000000041e424c0 a90007e0 stp %x0 %x1 -> (%sp)[16byte]

0x0000000041e424c4 a9010fe2 stp %x2 %x3 -> +0x10(%sp)[16byte]

0x0000000041e424c8 a90217e4 stp %x4 %x5 -> +0x20(%sp)[16byte]

0x0000000041e424cc a9031fe6 stp %x6 %x7 -> +0x30(%sp)[16byte]

0x0000000041e424d0 a90427e8 stp %x8 %x9 -> +0x40(%sp)[16byte]

0x0000000041e424d4 a9052fea stp %x10 %x11 -> +0x50(%sp)[16byte]

0x0000000041e424d8 a90637ec stp %x12 %x13 -> +0x60(%sp)[16byte]

0x0000000041e424dc a9073fee stp %x14 %x15 -> +0x70(%sp)[16byte]

0x0000000041e424e0 a90847f0 stp %x16 %x17 -> +0x80(%sp)[16byte]

0x0000000041e424e4 a9094ff2 stp %x18 %x19 -> +0x90(%sp)[16byte]

0x0000000041e424e8 a90a57f4 stp %x20 %x21 -> +0xa0(%sp)[16byte]

0x0000000041e424ec a90b5ff6 stp %x22 %x23 -> +0xb0(%sp)[16byte]

0x0000000041e424f0 a90c67f8 stp %x24 %x25 -> +0xc0(%sp)[16byte]

0x0000000041e424f4 a90d6ffa stp %x26 %x27 -> +0xd0(%sp)[16byte]

0x0000000041e424f8 a90e77fc stp %x28 %x29 -> +0xe0(%sp)[16byte]

0x0000000041e424fc 910003e0 add %sp $0x0000 lsl $0x00 -> %x0

0x0000000041e42500 91040000 add %x0 $0x0100 lsl $0x00 -> %x0

0x0000000041e42504 d2800001 movz $0x0000 lsl $0x00 -> %x1

0x0000000041e42508 f90083e1 str %x1 -> +0x0100(%sp)[8byte]

0x0000000041e4250c d53b4201 mrs %nzcv -> %x1

0x0000000041e42510 d53b4402 mrs %fpcr -> %x2

0x0000000041e42514 29010801 stp %w1 %w2 -> +0x08(%x0)[8byte]

0x0000000041e42518 d53b4421 mrs %fpsr -> %x1

0x0000000041e4251c b9001001 str %w1 -> +0x10(%x0)[4byte]

0x0000000041e42520 91008000 add %x0 $0x0020 lsl $0x00 -> %x0

0x0000000041e42524 ad000400 stp %q0 %q1 -> (%x0)[32byte]

0x0000000041e42528 ad010c02 stp %q2 %q3 -> +0x20(%x0)[32byte]

0x0000000041e4252c ad021404 stp %q4 %q5 -> +0x40(%x0)[32byte]

0x0000000041e42530 ad031c06 stp %q6 %q7 -> +0x60(%x0)[32byte]

0x0000000041e42534 ad042408 stp %q8 %q9 -> +0x80(%x0)[32byte]

0x0000000041e42538 ad052c0a stp %q10 %q11 -> +0xa0(%x0)[32byte]

0x0000000041e4253c ad06340c stp %q12 %q13 -> +0xc0(%x0)[32byte]

0x0000000041e42540 ad073c0e stp %q14 %q15 -> +0xe0(%x0)[32byte]

0x0000000041e42544 ad084410 stp %q16 %q17 -> +0x0100(%x0)[32byte]

0x0000000041e42548 ad094c12 stp %q18 %q19 -> +0x0120(%x0)[32byte]

0x0000000041e4254c ad0a5414 stp %q20 %q21 -> +0x0140(%x0)[32byte]

0x0000000041e42550 ad0b5c16 stp %q22 %q23 -> +0x0160(%x0)[32byte]

0x0000000041e42554 ad0c6418 stp %q24 %q25 -> +0x0180(%x0)[32byte]

0x0000000041e42558 ad0d6c1a stp %q26 %q27 -> +0x01a0(%x0)[32byte]

0x0000000041e4255c ad0e741c stp %q28 %q29 -> +0x01c0(%x0)[32byte]

0x0000000041e42560 ad0f7c1e stp %q30 %q31 -> +0x01e0(%x0)[32byte]

0x0000000041e42564 a94007e0 ldp (%sp)[16byte] -> %x0 %x1

0x0000000041e42568 f9400be2 ldr +0x10(%sp)[8byte] -> %x2

0x0000000041e4256c d61f03c0 br %x30

0x0000000041e42570 d503201f nop

0x0000000041e42574 d503201f nop

0x0000000041e42578 d503201f nop

0x0000000041e4257c d503201f nop

You can see the relink_special_ibl_xfer source code on aarch64 platform, it changes the second instruction of the next routine which I think it's not expected.

Finally the program will cause SEGV fault as below GDB procedure.

(gdb) c

Continuing.

Program received signal SIGSEGV, Segmentation fault.

0x00000000000201e8 in ?? ()

(gdb) i r

x0 0x0 0

x1 0x201e8 131560

x2 0x0 0

x3 0x0 0

x4 0x4000005098b0 70368749459632

x5 0x400000500000 70368749420544

x6 0x400000501420 70368749425696

x7 0x0 0

x8 0xd7 215

x9 0x0 0

x10 0x1 1

x11 0x90000000 2415919104

x12 0x43 67

x13 0x10000 65536

x14 0x400200fcffe0 70377350692832

x15 0x3024f 197199

x16 0x400200b78bd0 70377346141136

x17 0x400200f70010 70377350299664

x18 0xffffffffa340 281474976686912

x19 0xffffffffa690 281474976687760

x20 0x18 24

x21 0x400000501138 70368749424952

x22 0x1b 27

x23 0xffffffffa590 281474976687504

x24 0x0 0

x25 0x400200f6fd40 70377350298944

x26 0x400000500000 70368749420544

x27 0x493e60 4800096

x28 0x400000730000 70368751714304

x29 0xffffffffa6b0 281474976687792

x30 0x41f00ad4 1106250452

sp 0x40000076fce0 0x40000076fce0

pc 0x201e8 0x201e8

cpsr 0x20000000 536870912

fpsr 0x0 0

fpcr 0x0 0

The fault instruction is the modifed instruction by relink_special_ibl_xfer call

br x1 (#0x201e8)

Expect feedbacks.

Derek Bruening

unread,

Sep 26, 2021, 10:47:50 AM9/26/21

to dynamor...@googlegroups.com

Please file a bug in the tracker with this information.

Note that whether this causes a crash or else has no ultimate bad effect may depend on the machine or runtime ops (cache line size and other factors) since on the aarch64 machine I have access to it overwrites nops padding the start of the next function so there is no visible problem, probably why nobody had noticed.

To view this discussion on the web visit https://groups.google.com/d/msgid/dynamorio-users/9edb0920-ec33-4532-9719-290c1caa970bn%40googlegroups.com.

assad.hashm...@gmail.com

unread,

Sep 27, 2021, 1:54:40 PM9/27/21

to DynamoRIO Users

Thanks for spotting the bug and providing details of the failure mode.

A defect has been raised to track the fix https://github.com/DynamoRIO/dynamorio/issues/5129

Raymond

unread,

Sep 28, 2021, 2:44:12 AM9/28/21

to DynamoRIO Users

Great.

Expect to fix it.

Reply all

Reply to author

Forward