Set breakpoint for multi-thread application will cause crash

[GoogleCodeExporter]

Hi,

I'm trying to use EDB to debug my multi-thread shared library (loaded in a test 
application).
But I found if I set a breakpoint which should be reached in child thread 
(LWP), a crash will be happen after resume the application.

Here're my steps:

1) 'Open' my test application in EDB
2) set an breakpoint in some place where the multi-thread shared library has 
been loaded
3) 'Run' the test application to reach the breakpoint
4) check '/proc/<PID>/maps' to find the start address for my shared library
5) find the code address which will be reached in child LWP (using objdump)
6) set an new breakpoint at memory address (start address + code address)
7) resume the test application

Expect result:
    the test application should be stopped at the break point

Actural result:
    the test application crashed, and nothing left in EDB, no warning and no content.

Please help me to check this problem, is there any limitation for setting 
breakpoint in multi-LWP application?

Please tell me if you need some more informations.

Thanks.

Original issue reported on code.google.com by evan.teran on 3 Oct 2012 at 3:21

[GoogleCodeExporter]

Unfortunately, thread support is pretty much in its infancy at the moment for 
EDB.

Here's the main problem. Linux (and other OSes with a ptrace style API) don't 
debug "processes" they debug threads. So if an application is multi-threaded, 
the debugger has to manually attach to all threads, handle the events of all of 
these and jump through lots of hoops to get things to work as expected :-(. The 
biggest annoyance is that when an event occurs, the debugger needs to send a 
stop signal to every other thread and wait for them to stop (what if one of 
them crashes or doesn't stop for some reason).

Currently when you attach to a process with EDB, it simply attaches the PID of 
the application (the main thread). It does not (yet) attach to any child 
threads.

So if you put a breakpoint that gets hit by any thread except for the main 
thread, that thread will receive a trap event which will go unhanded (no 
debugger attached!) which will end the process.

Eventually EDB will handle this correctly (this is considered a blocker for 
1.0) but currently it doesn't.

Original comment by evan.teran on 3 Oct 2012 at 4:54

[GoogleCodeExporter]

Issue 78 has been merged into this issue.

Original comment by evan.teran on 3 Oct 2012 at 4:55

[GoogleCodeExporter]

This is handled much better in the current code and works mostly correctly.

Original comment by evan.teran on 3 Oct 2012 at 4:56

• Changed state: Started

[GoogleCodeExporter]

While I'm sure that there is room for improvement, multi-threaded applications 
are much better supported than they were when this was originally reported.

Original comment by evan.teran on 18 Jan 2014 at 4:34

• Changed state: Done

[GoogleCodeExporter]

While I'm sure that there is room for improvement, multi-threaded applications 
are much better supported than they were when this was originally reported.

Original comment by evan.teran on 18 Jan 2014 at 4:35