Hello, I found the bug in the 0.9.28 version of the debugger that causes debugger to crash on the memory view. I also tested it on the last commit [9efcc6b] and it does happen there too.
I didn't manage to reproduce it outside of my codebase but it happens every time I do it and I narrowed it down. It happens only when I step in the debugger and if size parameter is set up in the memory view. But besides that I can't figure out what is happening, I only noticed that range which is used in rd_eval_space_read to get slice (memcpy error is because slice is zeroed), has very big min value with top 32 bits being 0xccccccc3:
Which is possibly evaluated like this back from rd_view_ui__memory() from the callstack below.
[Content]
A fatal exception (code 0xc0000005) occurred. The process is terminating.
Call stack:
1. [0x7ff7e54a89e0] memcpy +112, memcpy.asm line 147
2. [0x7ff7e52e7c00] rd_eval_space_read +720, raddbg_core.c line 800
3. [0x7ff7e5273c53] e_space_read +3075, eval_interpret.c line 183
4. [0x7ff7e5418ce7] rd_view_ui__memory +13367, raddbg_views.c line 3550
5. [0x7ff7e5321e04] rd_view_ui +213908, raddbg_core.c line 5195
6. [0x7ff7e534bfad] rd_window_frame +158125, raddbg_core.c line 8860
7. [0x7ff7e53c43bf] rd_frame +380543, raddbg_core.c line 18495
8. [0x7ff7e51a6c09] frame +9, raddbg_main.c line 589
9. [0x7ff7e513a7b9] update +25, base_entry_point.c line 185
10. [0x7ff7e54529cc] entry_point +7644, raddbg_main.c line 810
11. [0x7ff7e513a687] main_thread_base_entry_point +1095, base_entry_point.c line 142
12. [0x7ff7e5456629] w32_entry_point_caller +3593, win32_base.c line 1965
13. [0x7ff7e513a9f3] wWinMain +67, win32_base.c line 1978
14. [0x7ff7e548a75a] __scrt_common_main_seh +262, exe_common.inl line 288
15. [0x7ffd6bf97374] KERNEL32
16. [0x7ffd6c3bcc91] ntdll
Version: 0.9.29 [9efcc6b2]
raddbg_crash_dump.dmp
Also there is a slight bug when you expand tab (Memory in my case) that was defined through rows(). For example I have this type:
typedef struct Memory {
char *mem;
long long int cap;
long long int count;
} Memory;
And watch expression:
rows(m, memory(mem, size=cap), count, cap)
It works fine from watch window, showing the memory correctly, but when I expand the memory() into it's own tab, it does so without evaluating rows() and appending m. in front of mem and cap which basically produces memory window with something like: memory(mem, size=cap) expression, instead of expected: memory(m.mem, size=m.cap).
And there is another slight bug when you start the debugger from terminal with specifying the target. When I don't prefix the path with drive letter it will treat it as a relative path, instead of absolute:
:: At path W:\insert\raddebugger
build\raddbg.exe \xcc\bin\xcc.exe
:: It will open raddebugger, but this will be the executable path:
W:/insert/raddebugger/xcc/bin/xcc.exe
:: Instead of expected:
W:/xcc/bin/xcc.exe
Hope this issue will help fixing these bugs.
Hello, I found the bug in the 0.9.28 version of the debugger that causes debugger to crash on the memory view. I also tested it on the last commit [9efcc6b] and it does happen there too.
I didn't manage to reproduce it outside of my codebase but it happens every time I do it and I narrowed it down. It happens only when I step in the debugger and if
sizeparameter is set up in the memory view. But besides that I can't figure out what is happening, I only noticed thatrangewhich is used inrd_eval_space_readto getslice(memcpy error is because slice is zeroed), has very bigminvalue with top 32 bits being 0xccccccc3:Which is possibly evaluated like this back from
rd_view_ui__memory()from the callstack below.raddbg_crash_dump.dmp
Also there is a slight bug when you expand tab (Memory in my case) that was defined through
rows(). For example I have this type:And watch expression:
It works fine from watch window, showing the memory correctly, but when I expand the
memory()into it's own tab, it does so without evaluating rows() and appendingm.in front ofmemandcapwhich basically produces memory window with something like:memory(mem, size=cap)expression, instead of expected:memory(m.mem, size=m.cap).And there is another slight bug when you start the debugger from terminal with specifying the target. When I don't prefix the path with drive letter it will treat it as a relative path, instead of absolute:
Hope this issue will help fixing these bugs.