Re: [Bacula-users] Using btraceback
Martin Simmons wrote: On Fri, 05 Jan 2007 11:20:16 -0500, DAve said: Martin Simmons wrote: On Tue, 02 Jan 2007 17:49:22 -0500, DAve said: I have a problem that may be simple. But trying to get a traceback is proving to be problematic. Following the directions in the manual, and what I could find in archives, I believe I am doing it correctly. However a couple issues spring up. First, the manual states that running btraceback manually should send the current state of bacula and exit leaving the processes running. This is true if there are no jobs running. http://pixelhammer.com/DAve/Bacula/btraceback2.txt But if jobs are running, bacula-dir goes away. Should btraceback stop bacula-dir? http://pixelhammer.com/DAve/Bacula/btraceback3.txt And finally, the traceback I get when I see the problem I am trying to report. I get the strange feeling that I need more information to properly report the problem to Kern. http://pixelhammer.com/DAve/Bacula/btraceback1.txt I am running Bacula 1.38.5 FreeBSD 5.4 Bacula installed from ports. I have debug set to a value of 99. I am running btraceback manually as root with the following command. btraceback /usr/local/sbin/bacula-dir 86459 The PID is correct and /usr/local/sbin/btraceback has been correctly edited. Thanks, any assistance is appreciated. The errors Previous frame inner to this frame (corrupt stack?) and No stack can mean several things, in order of likeliness: 1) the code doesn't contain sufficient debug info 2) gdb is broken or incompatible with gcc 3) gcc is broken or incompatible with gdb As this is a clean install, nothing beyond Bacula is installed other than the base OS, I think 2 and 3 are not likely the problem. However I'll look into the FreeBSD archives to see if anything has been reported. OK, but I've had some kind of gdb breakage in almost all distros/versions of Linux and FreeBSD :-( Sometimes it is caused by kernel bugs, but often the distro just lags behind the latest version of gdb, probably for good reasons like stability. It's getting better, but there are often problems debugging multithreaded programs and attaching/detaching to/from running programs, since these are less commonly used operations. You could try configuring and building Bacula with CFLAGS=-g to solve 1, though there will still be issues with the system libraries. I can do that, my next step was to abandon the port and build from source for that reason. What issues would this cause with system libraries? The problem is typically that are compiled with various optimization options and also never with -g. This makes it difficult for gdb to generate backtraces when the program is running (or blocked) in system libraries (again something which is more common in multithreaded programs). If that doesn't work, then building your own gdb from the latest sources might help with 2. You might be able to build your own gcc too, but that's pretty drastic. I have built gcc from sources before, it has never solved any problem it was advised as a solution for 8^( That will be my last ditch effort before changing the OS. Agreed -- it probably won't help much. __Martin OK, reading the release notes and such, and following the thread on upgrades, we are going to first move to 2.0 before we go any further with troubleshooting. We want the new features and I don't want to clutter the list with troubleshooting data twice. I will look at enabling debugging in the 2.0 install and try to get the upgrade done by Monday. We will move forward then. Thanks for the help. DAve -- Three years now I've asked Google why they don't have a logo change for Memorial Day. Why do they choose to do logos for other non-international holidays, but nothing for Veterans? Maybe they forgot who made that choice possible. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Using btraceback
Martin Simmons wrote: On Tue, 02 Jan 2007 17:49:22 -0500, DAve said: I have a problem that may be simple. But trying to get a traceback is proving to be problematic. Following the directions in the manual, and what I could find in archives, I believe I am doing it correctly. However a couple issues spring up. First, the manual states that running btraceback manually should send the current state of bacula and exit leaving the processes running. This is true if there are no jobs running. http://pixelhammer.com/DAve/Bacula/btraceback2.txt But if jobs are running, bacula-dir goes away. Should btraceback stop bacula-dir? http://pixelhammer.com/DAve/Bacula/btraceback3.txt And finally, the traceback I get when I see the problem I am trying to report. I get the strange feeling that I need more information to properly report the problem to Kern. http://pixelhammer.com/DAve/Bacula/btraceback1.txt I am running Bacula 1.38.5 FreeBSD 5.4 Bacula installed from ports. I have debug set to a value of 99. I am running btraceback manually as root with the following command. btraceback /usr/local/sbin/bacula-dir 86459 The PID is correct and /usr/local/sbin/btraceback has been correctly edited. Thanks, any assistance is appreciated. The errors Previous frame inner to this frame (corrupt stack?) and No stack can mean several things, in order of likeliness: 1) the code doesn't contain sufficient debug info 2) gdb is broken or incompatible with gcc 3) gcc is broken or incompatible with gdb As this is a clean install, nothing beyond Bacula is installed other than the base OS, I think 2 and 3 are not likely the problem. However I'll look into the FreeBSD archives to see if anything has been reported. You could try configuring and building Bacula with CFLAGS=-g to solve 1, though there will still be issues with the system libraries. I can do that, my next step was to abandon the port and build from source for that reason. What issues would this cause with system libraries? If that doesn't work, then building your own gdb from the latest sources might help with 2. You might be able to build your own gcc too, but that's pretty drastic. I have built gcc from sources before, it has never solved any problem it was advised as a solution for 8^( That will be my last ditch effort before changing the OS. Finally, you can run bacula-dir directly under gdb (add the -f option when starting bacula-dir). Then interrupt bacula-dir and use the gdb commands in the script at the gdb command line, which should allow you to skip any that fail. I can give that a try though scheduling a time frame might be difficult. There are some features in 2.0 we have been waiting for, I am considering moving all services and clients to 2.0 first on the off chance the problem may go away. I did not see anything in the release notes that leads me to believe so, but then again I have not opened a bug either. So as a heads up, the issue I am trying to get a traceback on is the following. We are still unable to get a specific client fd to transfer more than 7.5GB of data. We have updated the client to 1.38.10, tried heartbeat, compression on/off, scheduled based on max available bandwidth. We even let the backup project wait until the client server was replaced. It is now running a fresh install of Windows Server 2003 on new hardware. I did discover after repeated queries that the network admin also had to configure a NetScreen FW between the client server and our COLOC switch. That is another device to investigate that I was not aware of. I have not yet attempted working with the network buffer size as I do not have enough information/knowledge on how to calculate the requirements. __Martin Thank you, DAve -- Three years now I've asked Google why they don't have a logo change for Memorial Day. Why do they choose to do logos for other non-international holidays, but nothing for Veterans? Maybe they forgot who made that choice possible. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Using btraceback
On Fri, 05 Jan 2007 11:20:16 -0500, DAve said: Martin Simmons wrote: On Tue, 02 Jan 2007 17:49:22 -0500, DAve said: I have a problem that may be simple. But trying to get a traceback is proving to be problematic. Following the directions in the manual, and what I could find in archives, I believe I am doing it correctly. However a couple issues spring up. First, the manual states that running btraceback manually should send the current state of bacula and exit leaving the processes running. This is true if there are no jobs running. http://pixelhammer.com/DAve/Bacula/btraceback2.txt But if jobs are running, bacula-dir goes away. Should btraceback stop bacula-dir? http://pixelhammer.com/DAve/Bacula/btraceback3.txt And finally, the traceback I get when I see the problem I am trying to report. I get the strange feeling that I need more information to properly report the problem to Kern. http://pixelhammer.com/DAve/Bacula/btraceback1.txt I am running Bacula 1.38.5 FreeBSD 5.4 Bacula installed from ports. I have debug set to a value of 99. I am running btraceback manually as root with the following command. btraceback /usr/local/sbin/bacula-dir 86459 The PID is correct and /usr/local/sbin/btraceback has been correctly edited. Thanks, any assistance is appreciated. The errors Previous frame inner to this frame (corrupt stack?) and No stack can mean several things, in order of likeliness: 1) the code doesn't contain sufficient debug info 2) gdb is broken or incompatible with gcc 3) gcc is broken or incompatible with gdb As this is a clean install, nothing beyond Bacula is installed other than the base OS, I think 2 and 3 are not likely the problem. However I'll look into the FreeBSD archives to see if anything has been reported. OK, but I've had some kind of gdb breakage in almost all distros/versions of Linux and FreeBSD :-( Sometimes it is caused by kernel bugs, but often the distro just lags behind the latest version of gdb, probably for good reasons like stability. It's getting better, but there are often problems debugging multithreaded programs and attaching/detaching to/from running programs, since these are less commonly used operations. You could try configuring and building Bacula with CFLAGS=-g to solve 1, though there will still be issues with the system libraries. I can do that, my next step was to abandon the port and build from source for that reason. What issues would this cause with system libraries? The problem is typically that are compiled with various optimization options and also never with -g. This makes it difficult for gdb to generate backtraces when the program is running (or blocked) in system libraries (again something which is more common in multithreaded programs). If that doesn't work, then building your own gdb from the latest sources might help with 2. You might be able to build your own gcc too, but that's pretty drastic. I have built gcc from sources before, it has never solved any problem it was advised as a solution for 8^( That will be my last ditch effort before changing the OS. Agreed -- it probably won't help much. __Martin - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Using btraceback
On Tue, 02 Jan 2007 17:49:22 -0500, DAve said: I have a problem that may be simple. But trying to get a traceback is proving to be problematic. Following the directions in the manual, and what I could find in archives, I believe I am doing it correctly. However a couple issues spring up. First, the manual states that running btraceback manually should send the current state of bacula and exit leaving the processes running. This is true if there are no jobs running. http://pixelhammer.com/DAve/Bacula/btraceback2.txt But if jobs are running, bacula-dir goes away. Should btraceback stop bacula-dir? http://pixelhammer.com/DAve/Bacula/btraceback3.txt And finally, the traceback I get when I see the problem I am trying to report. I get the strange feeling that I need more information to properly report the problem to Kern. http://pixelhammer.com/DAve/Bacula/btraceback1.txt I am running Bacula 1.38.5 FreeBSD 5.4 Bacula installed from ports. I have debug set to a value of 99. I am running btraceback manually as root with the following command. btraceback /usr/local/sbin/bacula-dir 86459 The PID is correct and /usr/local/sbin/btraceback has been correctly edited. Thanks, any assistance is appreciated. The errors Previous frame inner to this frame (corrupt stack?) and No stack can mean several things, in order of likeliness: 1) the code doesn't contain sufficient debug info 2) gdb is broken or incompatible with gcc 3) gcc is broken or incompatible with gdb You could try configuring and building Bacula with CFLAGS=-g to solve 1, though there will still be issues with the system libraries. If that doesn't work, then building your own gdb from the latest sources might help with 2. You might be able to build your own gcc too, but that's pretty drastic. Finally, you can run bacula-dir directly under gdb (add the -f option when starting bacula-dir). Then interrupt bacula-dir and use the gdb commands in the script at the gdb command line, which should allow you to skip any that fail. __Martin - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
[Bacula-users] Using btraceback
I have a problem that may be simple. But trying to get a traceback is proving to be problematic. Following the directions in the manual, and what I could find in archives, I believe I am doing it correctly. However a couple issues spring up. First, the manual states that running btraceback manually should send the current state of bacula and exit leaving the processes running. This is true if there are no jobs running. http://pixelhammer.com/DAve/Bacula/btraceback2.txt But if jobs are running, bacula-dir goes away. Should btraceback stop bacula-dir? http://pixelhammer.com/DAve/Bacula/btraceback3.txt And finally, the traceback I get when I see the problem I am trying to report. I get the strange feeling that I need more information to properly report the problem to Kern. http://pixelhammer.com/DAve/Bacula/btraceback1.txt I am running Bacula 1.38.5 FreeBSD 5.4 Bacula installed from ports. I have debug set to a value of 99. I am running btraceback manually as root with the following command. btraceback /usr/local/sbin/bacula-dir 86459 The PID is correct and /usr/local/sbin/btraceback has been correctly edited. Thanks, any assistance is appreciated. DAve -- Three years now I've asked Google why they don't have a logo change for Memorial Day. Why do they choose to do logos for other non-international holidays, but nothing for Veterans? Maybe they forgot who made that choice possible. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
