> On 6 Nov 2018, at 14:37, Maximilian Hartig via petsc-users 
> <[email protected]> wrote:
> 
> lldb returns the following:
> 
> (lldb) process attach --pid 1082
> Process 1082 stopped
> * thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
>     frame #0: 0x00007fff5aa5c876 libsystem_kernel.dylib`__semwait_signal + 10
> libsystem_kernel.dylib`__semwait_signal:
> ->  0x7fff5aa5c876 <+10>: jae    0x7fff5aa5c880            ; <+20>
>     0x7fff5aa5c878 <+12>: movq   %rax, %rdi
>     0x7fff5aa5c87b <+15>: jmp    0x7fff5aa58e31            ; cerror
>     0x7fff5aa5c880 <+20>: retq   
> Target 0: (meshTest) stopped.
> 
> Executable module set to 
> "/Users/maximilianhartig/cimply_playground/./meshTest".
> Architecture set to: x86_64h-apple-macosx.
> 
> I do unfortunately not know what to make of this. Do I have a memory jump 
> that’s causing an error here? Google did not provide any useful results (at 
> least to my untrained eye). Using gdb I usually step through the program and 
> print out variables until I’ve located the error. But this does not seem an 
> option here. Please excuse my ignorance regarding debuggers.

PETSc uses a signal handler to attach the debugger. You need to go up the stack 
until you get to the point where the signal handler was invoked (via CHKERRQ or 
similar). Then you should be able to inspect the relevant variables.

Cheers,

Lawrence

Reply via email to