Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Thread Support #8

Closed
GoogleCodeExporter opened this issue Mar 29, 2015 · 3 comments
Closed

Thread Support #8

GoogleCodeExporter opened this issue Mar 29, 2015 · 3 comments

Comments

@GoogleCodeExporter
Copy link

EDB currently has no support for debugging multi-threaded applications. When
you attach to a process, it simple attaches to the primary thread.

@GoogleCodeExporter
Copy link
Author

There should be changes in the underlying functions to allow plugins and even
the debugger to get the state of a specific thread.
This is needed for example when setting hardware breakpoints.

@GoogleCodeExporter
Copy link
Author

What you suggest is actually implemented to a certain degree. Basically, the
debugging core has a concept of an "active" thread.

When you ask it to set/get the state, it will act upon the active thread. By
default, after any given event, this will be the thread which triggered the
event. However, plugins can choose to set it manually to another thread ID. So
for example, you could do the following:

State state;
edb::tid_t t = edb::v1::debugger_core->active_thread();
edb::v1::debugger_core->set_active_thread(1234);
edb::v1::debugger_core->get_state(state);     // get the state of thread 1234
state.eip = 0x41414141; 
edb::v1::debugger_core->set_state(state);
edb::v1::debugger_core->set_active_thread(t); // reset the active thread to what it was

that will set the EIP of thread 1234 to 0x41414141 without effecting the other
threads.

@eteran
Copy link
Owner

eteran commented Oct 15, 2015

With the new API in place, it is now trivial to access and modify the state of individual threads. And a fix has been applied the hardware BP plugin to utilize it

@eteran eteran closed this as completed Oct 15, 2015
sorokin added a commit to sorokin/edb-debugger that referenced this issue Feb 15, 2020
AddressSanitizer:DEADLYSIGNAL
=================================================================
==22728==ERROR: AddressSanitizer: SEGV on unknown address 0x7f362e1c03b8 (pc 0x7f3647a5faef bp 0x6070000b1470 sp 0x7ffc012e08f0 T0)
==22728==The signal is caused by a READ memory access.
    #0 0x7f3647a5faee  (/nix/store/rw5qmxlnfmgq72l028djxyknqr912i81-qtbase-5.12.3/lib/libQt5Network.so.5+0xc4aee)
    eteran#1 0x7f36479ec807  (/nix/store/rw5qmxlnfmgq72l028djxyknqr912i81-qtbase-5.12.3/lib/libQt5Network.so.5+0x51807)
    eteran#2 0x7f36479ec8e8  (/nix/store/rw5qmxlnfmgq72l028djxyknqr912i81-qtbase-5.12.3/lib/libQt5Network.so.5+0x518e8)
    eteran#3 0x7f3646aec19b in QObject::~QObject() (/nix/store/rw5qmxlnfmgq72l028djxyknqr912i81-qtbase-5.12.3/lib/libQt5Core.so.5+0x2bd19b)
    eteran#4 0x7f36479e77c7 in QNetworkAccessManager::~QNetworkAccessManager() (/nix/store/rw5qmxlnfmgq72l028djxyknqr912i81-qtbase-5.12.3/lib/libQt5Network.so.5+0x4c7c7)
    eteran#5 0x7f36479e7828 in QNetworkAccessManager::~QNetworkAccessManager() (/nix/store/rw5qmxlnfmgq72l028djxyknqr912i81-qtbase-5.12.3/lib/libQt5Network.so.5+0x4c828)
    eteran#6 0x7f3646ae3494 in QObjectPrivate::deleteChildren() (/nix/store/rw5qmxlnfmgq72l028djxyknqr912i81-qtbase-5.12.3/lib/libQt5Core.so.5+0x2b4494)
    eteran#7 0x7f3646aec153 in QObject::~QObject() (/nix/store/rw5qmxlnfmgq72l028djxyknqr912i81-qtbase-5.12.3/lib/libQt5Core.so.5+0x2bd153)
    eteran#8 0x7f3632f04dc4 in CheckVersionPlugin::CheckVersion::~CheckVersion() /home/ivan/d/edb-debugger/plugins/CheckVersion/CheckVersion_autogen/EWIEGA46WW/../../CheckVersion.h:40
    eteran#9 0x7f3632f04dc4 in CheckVersionPlugin::CheckVersion::~CheckVersion() /home/ivan/d/edb-debugger/plugins/CheckVersion/CheckVersion_autogen/EWIEGA46WW/../../CheckVersion.h:40
    eteran#10 0x7f3646ab1d76  (/nix/store/rw5qmxlnfmgq72l028djxyknqr912i81-qtbase-5.12.3/lib/libQt5Core.so.5+0x282d76)
    eteran#11 0x7f3646ab37aa  (/nix/store/rw5qmxlnfmgq72l028djxyknqr912i81-qtbase-5.12.3/lib/libQt5Core.so.5+0x2847aa)
    eteran#12 0x7f3645656846 in __cxa_finalize (/nix/store/wx1vk75bpdr65g6xwxbj4rw0pk04v5j3-glibc-2.27/lib/libc.so.6+0x38846)
    eteran#13 0x7f36468dbfb2  (/nix/store/rw5qmxlnfmgq72l028djxyknqr912i81-qtbase-5.12.3/lib/libQt5Core.so.5+0xacfb2)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV (/nix/store/rw5qmxlnfmgq72l028djxyknqr912i81-qtbase-5.12.3/lib/libQt5Network.so.5+0xc4aee)
sorokin added a commit to sorokin/edb-debugger that referenced this issue Feb 22, 2020
Before this commit running

   edb --run /home/ivan/Документы/a.out (Документы means "Documents" in Russian)

would cause heap-buffer-overflow in edb:

=================================================================
==26208==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6030004bd19b at pc 0x7f933a072274 bp 0x7ffd5dc26860 sp 0x7ffd5dc26010
WRITE of size 36 at 0x6030004bd19b thread T0
    #0 0x7f933a072273
    eteran#1 0x7f93242f2796 in strcpy bits/string_fortified.h:90
    eteran#2 0x7f93242f2796 in DebuggerCorePlugin::Unix::execute_process(QString const&, QString const&, QList<QByteArray> const&) plugins/DebuggerCore/unix/Unix.cpp:179
    eteran#3 0x7f93241d6dc5 in DebuggerCorePlugin::DebuggerCore::open(QString const&, QString const&, QList<QByteArray> const&, QString const&) plugins/DebuggerCore/unix/linux/DebuggerCore.cpp:925
    eteran#4 0x62b26a in Debugger::commonOpen(QString const&, QList<QByteArray> const&) src/Debugger.cpp:3013
    eteran#5 0x62cdde in Debugger::execute(QString const&, QList<QByteArray> const&) src/Debugger.cpp:3033
    eteran#6 0xc5fa4d in start_debugger src/main.cpp:122
    eteran#7 0xc634c8 in main src/main.cpp:255
    eteran#8 0x7f93371b9b8d in __libc_start_main
    eteran#9 0x4b7879 in _start

0x6030004bd19b is located 0 bytes to the right of 27-byte region [0x6030004bd180,0x6030004bd19b)
allocated by thread T0 here:
    #0 0x7f933a10df40 in operator new[](unsigned long)
    eteran#1 0x7f93242f2239 in DebuggerCorePlugin::Unix::execute_process(QString const&, QString const&, QList<QByteArray> const&) plugins/DebuggerCore/unix/Unix.cpp:178

SUMMARY: AddressSanitizer: heap-buffer-overflow (libasan.so.5+0x52273)
Shadow bytes around the buggy address:
  0x0c068008f9e0: fa fa fd fd fd fd fa fa fd fd fd fd fa fa fd fd
  0x0c068008f9f0: fd fd fa fa fd fd fd fa fa fa fd fd fd fa fa fa
  0x0c068008fa00: 00 00 00 00 fa fa 00 00 00 fa fa fa fd fd fd fa
  0x0c068008fa10: fa fa 00 00 00 fa fa fa fd fd fd fa fa fa 00 00
  0x0c068008fa20: 00 fa fa fa fd fd fd fd fa fa 00 00 00 fa fa fa
=>0x0c068008fa30: 00 00 00[03]fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c068008fa40: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c068008fa50: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c068008fa60: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c068008fa70: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c068008fa80: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb

The problem was caused by the fact that the buffer size is computed as
a string length in UTF-16 codeunits, but is written with UTF-8 (technically
currect system encoding) codeunits, so its length should equal to
the length of string in UTF-8 codeunits.
sorokin added a commit to sorokin/edb-debugger that referenced this issue Feb 22, 2020
Before this commit running

   edb --run /home/ivan/Документы/a.out (Документы means "Documents" in Russian)

would cause heap-buffer-overflow in edb:

=================================================================
==26208==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6030004bd19b at pc 0x7f933a072274 bp 0x7ffd5dc26860 sp 0x7ffd5dc26010
WRITE of size 36 at 0x6030004bd19b thread T0
    #0 0x7f933a072273
    eteran#1 0x7f93242f2796 in strcpy bits/string_fortified.h:90
    eteran#2 0x7f93242f2796 in DebuggerCorePlugin::Unix::execute_process(QString const&, QString const&, QList<QByteArray> const&) plugins/DebuggerCore/unix/Unix.cpp:179
    eteran#3 0x7f93241d6dc5 in DebuggerCorePlugin::DebuggerCore::open(QString const&, QString const&, QList<QByteArray> const&, QString const&) plugins/DebuggerCore/unix/linux/DebuggerCore.cpp:925
    eteran#4 0x62b26a in Debugger::commonOpen(QString const&, QList<QByteArray> const&) src/Debugger.cpp:3013
    eteran#5 0x62cdde in Debugger::execute(QString const&, QList<QByteArray> const&) src/Debugger.cpp:3033
    eteran#6 0xc5fa4d in start_debugger src/main.cpp:122
    eteran#7 0xc634c8 in main src/main.cpp:255
    eteran#8 0x7f93371b9b8d in __libc_start_main
    eteran#9 0x4b7879 in _start

0x6030004bd19b is located 0 bytes to the right of 27-byte region [0x6030004bd180,0x6030004bd19b)
allocated by thread T0 here:
    #0 0x7f933a10df40 in operator new[](unsigned long)
    eteran#1 0x7f93242f2239 in DebuggerCorePlugin::Unix::execute_process(QString const&, QString const&, QList<QByteArray> const&) plugins/DebuggerCore/unix/Unix.cpp:178

SUMMARY: AddressSanitizer: heap-buffer-overflow (libasan.so.5+0x52273)
Shadow bytes around the buggy address:
  0x0c068008f9e0: fa fa fd fd fd fd fa fa fd fd fd fd fa fa fd fd
  0x0c068008f9f0: fd fd fa fa fd fd fd fa fa fa fd fd fd fa fa fa
  0x0c068008fa00: 00 00 00 00 fa fa 00 00 00 fa fa fa fd fd fd fa
  0x0c068008fa10: fa fa 00 00 00 fa fa fa fd fd fd fa fa fa 00 00
  0x0c068008fa20: 00 fa fa fa fd fd fd fd fa fa 00 00 00 fa fa fa
=>0x0c068008fa30: 00 00 00[03]fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c068008fa40: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c068008fa50: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c068008fa60: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c068008fa70: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c068008fa80: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb

The problem was caused by the fact that the buffer size is computed as
a string length in UTF-16 codeunits, but is written with UTF-8 (technically
current system encoding) codeunits, so its length should equal to
the length of string in UTF-8 codeunits.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants