Sponsored Content
Top Forums Programming dbx - break on access violations Post 302497504 by achenle on Thursday 17th of February 2011 11:38:49 AM
Old 02-17-2011
What OS?

On Solaris 10 or later, or in multithreaded processes on just about any version of Solaris, probably the easiest way is to set a break in the ___errno() function that's used to return a pointer to each thread's errno variable.
 

4 More Discussions You Might Find Interesting

1. Programming

dbx - attach to process, break when crash

Hey everyone, I have a process that is crashing, and I'd like to have some way to see where it crashes. Is this possible? (2 Replies)
Discussion started by: ctote
2 Replies

2. UNIX for Dummies Questions & Answers

How can I set DBX to break on an Access Violation?

I'm trying to debug a service crash, and would like to break on an access violation - is this possible? (0 Replies)
Discussion started by: ctote
0 Replies

3. AIX

How to set the break point using dbx?

Hi, I am trying to debug my project using dbx to understand the code and functionality of modules. I compiled all my C files using gcc -g flag to enable the debug option. I was able to get in to the debug mode using dbx. I was able to create breakpoints using stop at line no. "stop at... (7 Replies)
Discussion started by: Sachin1987
7 Replies

4. Solaris

Can't use 'break' command, Can't access 'ok' prompt.

Hi I have A Sun Ultra Enterprise 450 server, it has Solaris installed on it. I have A serial terminal hooked up to it (nullmodem cable plugged into serial port 1 on the box, and the other end plugged into the serial port of A laptop (NEC Versa M300)) The laptop is running Ubuntu 12.04.2... (3 Replies)
Discussion started by: SomeoneTwo
3 Replies
BTRACEBACK(1)					     Network backup, recovery and verification					     BTRACEBACK(1)

NAME
btraceback - wrapper script around gdb and bsmtp SYNOPSIS
btraceback /path/to/binary pid DESCRIPTION
btraceback is a wrapper shell script around the gdb debugger (or dbx on Solaris systems) and bsmtp, provided for debugging purposes. USAGE
btraceback is called by the exception handlers of the Bacula daemons during a crash. It can also be called interactively to view the cur- rent state of the threads belonging to a process, but this is not recommended unless you are trying to debug a problem (see below). NOTES
In order to work properly, debugging symbols must be available to the debugger on the system, and gdb, or dbx (on Solaris systems) must be available in the $PATH. If the Director or Storage daemon runs under a non-root uid, you will probably need to be modify the btraceback script to elevate privi- leges for the call to gdb/dbx, to ensure it has the proper permissions to debug when called by the daemon. Although Bacula's use of btraceback within its exception handlers is always safe, manual or interactive use of btraceback is subject to the same risks than live debugging of any program, which means it could cause Bacula to crash under rare and abnormal circumstances. Conse- quently we do not recommend manual use of btraceback in production environments unless it is required for debugging a problem. ENVIRONMENT
btracback relies on $PATH to find the debugger. FILES
/usr/lib/bacula/btraceback The script itself. /usr/sbin/btraceback symbolic link to /usr/lib/bacula/btraceback /etc/bacula/scripts/btraceback.gdb the GDB command batch used to output a stack trace AUTHOR
This manual page was written by Lucas B. Cohen <lbc@members.fsf.org> SEE ALSO
bsmtp(1) Kern Sibbald 6 December 2009 BTRACEBACK(1)
All times are GMT -4. The time now is 03:58 PM.
Unix & Linux Forums Content Copyright 1993-2022. All Rights Reserved.
Privacy Policy