You can start a process directly from gdb, or you can attach gdb to a running process before it crashes and 'continue', then obtain a backtrace after the crash. Without more information (specifically a backtrace) there isn't much anyone can do to help.
"its not problem of tor, nobody reported about the problem somewhere else" - this doesn't make sense. Buggy programs are more likely to crash quickly on OpenBSD than other OS (reasons include free() overwriting the start of freed memory by default and stricter mutex checks). These would still be bugs in the program not the OS. On 29 September 2014 00:16:28 BST, [email protected] wrote: >Monday, September 29, 2014, 1:11:03 AM, you wrote: > >> On Sun, Sep 28, 2014 at 07:51:19PM +0400, [email protected] wrote: >>> >Synopsis: tor segmentation fault on amd64 current >>> >Category: user >>> >Environment: >>> System : OpenBSD 5.6 >>> Details : OpenBSD 5.6-current (GENERIC.MP) #390: Thu Sep >25 14:38:54 MDT 2014 >>> >[email protected]:/usr/src/sys/arch/amd64/compile/GENERIC.MP >>> >>> Architecture: OpenBSD.amd64 >>> Machine : amd64 >>> >Description: >>> began about two months ago after updating userland. also >tested on vm >>> >How-To-Repeat: >>> run tor v0.2.4.22+ on amd64 current >>> >Fix: >>> uninstall obsd >>> > >> I believe ports@ might be a more suitable list for this topic. > >> Why are you not showing a strack trace from a crashed tor process? > >no crash dump file created. its not problem of tor, nobody reported >about the problem somewhere else -- Sent from a phone, please excuse the formatting.
