Quuxplusone / LLVMBugzillaTest

0 stars 0 forks source link

LLDB not clearing EXC_BAD_ACCESS exception after `thread return` (on MacOS)? #49917

Open Quuxplusone opened 3 years ago

Quuxplusone commented 3 years ago
Bugzilla Link PR50948
Status NEW
Importance P normal
Reported by Vy Nguyen (vyng@google.com)
Reported on 2021-06-30 10:30:26 -0700
Last modified on 2021-06-30 11:15:40 -0700
Version unspecified
Hardware PC MacOS X
CC jdevlieghere@apple.com, jingham@apple.com, llvm-bugs@lists.llvm.org, vyng@google.com
Fixed by commit(s)
Attachments
Blocks
Blocked by
See also

Repro:

Using the following test code:

// bad_access.cc 1 // bad_access.cc 2 #include 3 #include 4
5 int bad_acc(void){ 6 printf("in bad_acc()\n"); 7
8 // cause bad mem access here 9 return (int)(123); 10 } 11
12 int main () { 13 printf( "hello world\n"); 14 // bad access here 15 bad_acc(); 16 printf("bye world\n"); 17 return 0; 18 } vyng-macbookpro2% // Compile and run with lldb:

% clang -g -o bad_acc bad_access.cc % lldb (lldb) target create "bad_acc" Current executable set to '/bad_acc' (x86_64). (lldb) Current executable set to '/bad_acc' (x86_64). (lldb) run Process 97548 launched: '/bad_acc' (x86_64) hello world in bad_acc() Process 97548 stopped


Details:

After the processed stopped on bad_access.cc:9, I used thread return and two register write pc$pc-8`` hoping to get back to bad_access.cc:13 to restart the exececution.

Quuxplusone commented 3 years ago

I don't think that's quite what is going on. "thread return" doesn't change the stop reason for the thread (because it doesn't actually cause the thread to run it just changes the pc & sp). So until you run again the stop reason is going to be the same.

When you do run again, the process crashes with an EXC_BAD_ACCESS on a different address. The first one was "address=0x7b", the last one was "address=0x27e80d". In this case it looks like we did proceed correctly from the "thread return" but your attempt to repair the session was unsuccessful, and lead to us crashing somewhere else.

This seems correct behavior to me.