[petsc-users] Segmentation violation in DMPlexDistribute on MacOS

[Maximilian Hartig]

> On 6. Nov 2018, at 15:42, Matthew Knepley <knepley at gmail.com> wrote:
> 
> On Tue, Nov 6, 2018 at 9:38 AM Maximilian Hartig via petsc-users <petsc-users at mcs.anl.gov <mailto:petsc-users at mcs.anl.gov>> 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.
> 
> Okay, at the prompt you type 'bt'. This gives you the backtrace.
Thanks for this hint. Would’ve had to search some time. What I get is the following:

(lldb) process attach --pid 1265
Process 1265 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
    frame #0: 0x00007fff74371876 libsystem_kernel.dylib`__semwait_signal + 10
libsystem_kernel.dylib`__semwait_signal:
->  0x7fff74371876 <+10>: jae    0x7fff74371880            ; <+20>
    0x7fff74371878 <+12>: movq   %rax, %rdi
    0x7fff7437187b <+15>: jmp    0x7fff7436de31            ; cerror
    0x7fff74371880 <+20>: retq   
Target 0: (meshTest) stopped.

Executable module set to "/Users/maximilianhartig/cimply_playground/./meshTest".
Architecture set to: x86_64h-apple-macosx.
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
  * frame #0: 0x00007fff74371876 libsystem_kernel.dylib`__semwait_signal + 10
    frame #1: 0x00007fff742fc830 libsystem_c.dylib`nanosleep + 199
    frame #2: 0x00007fff742fc692 libsystem_c.dylib`sleep + 41
    frame #3: 0x000000010e969fde libpetsc.3.10.dylib`PetscSleep(s=<unavailable>) at psleep.c:50
    frame #4: 0x000000010e9e2546 libpetsc.3.10.dylib`PetscAttachDebugger at adebug.c:390
    frame #5: 0x000000010e9e31ba libpetsc.3.10.dylib`PetscAttachDebuggerErrorHandler(comm=<unavailable>, line=<unavailable>, fun=<unavailable>, file=<unavailable>, num=<unavailable>, p=<unavailable>, mess=<unavailable>, ctx=0x0000000000000000) at adebug.c:452
    frame #6: 0x000000010e9e389f libpetsc.3.10.dylib`PetscError(comm=1140850689, line=0, func="User provided function", file=" unknown file", n=59, p=PETSC_ERROR_INITIAL, mess=0x0000000000000000) at err.c:367
    frame #7: 0x000000010e9e78f0 libpetsc.3.10.dylib`PetscSignalHandlerDefault(sig=<unavailable>, ptr=<unavailable>) at signal.c:152
    frame #8: 0x000000010e9e79b6 libpetsc.3.10.dylib`PetscSignalHandler_Private(sig=11) at signal.c:43
    frame #9: 0x00007fff7441eb3d libsystem_platform.dylib`_sigtramp + 29
    frame #10: 0x00007fff74220e97 libdyld.dylib`stack_not_16_byte_aligned_error + 1
(lldb) 

Thanks,
Max

> 
>   Thanks,
> 
>      Matt
>  
> 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.
> 
> Thanks,
> Max
> 
>> On 6. Nov 2018, at 11:23, Stefano Zampini <stefano.zampini at gmail.com <mailto:stefano.zampini at gmail.com>> wrote:
>> 
>> 
>> [0]PETSC ERROR: Try option -start_in_debugger or -on_error_attach_debugger
>> 
>> Have you tried what PETSc suggests here (-on_error_attach_debugger)?
>> You may need to specify "-on_error_attach_debugger lldb" on a MacOS
>>  
>> 
>> -- 
>> Stefano
> 
> 
> 
> -- 
> What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.
> -- Norbert Wiener
> 
> https://www.cse.buffalo.edu/~knepley/ <http://www.cse.buffalo.edu/~knepley/>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20181106/be2e8bcf/attachment.html>