Re: Running a program through gdb without interfering
On Fri, 9 Oct 2009 01:16:59 +0200 Mel Flynn mel.flynn+fbsd.hack...@mailing.thruhere.net wrote: On Friday 09 October 2009 00:38:32 Paul B Mahol wrote: On 10/9/09, Mel Flynn mel.flynn+fbsd.hack...@mailing.thruhere.net wrote: Hi, is there a way to have a program run through gdb and gdb only record a segfault, but otherwise let the program run? Why I'd like this is the following: I've got a i386 jail on an amd64 box, running 7.2-p4. UNAME_p and UNAME_m have been set to i386 as well as ARCH in /etc/make.conf. Running portmaster[1] to build ports under my uid and PM_SU_CMD, sudo *sometimes* segfaults. It's only sudo, so at present I don't have a reason to doubt memory. However, it doesn't dump core, so I'm at a loss what the culprit could be. Tried 'sysctl kern.sugid_coredump=1' ? Hmm, no. Enabled now and waiting for the next segfault. I actually looked at the sysctl -d, but it didn't register that this could be the main cause. Perhaps that sentence could be more clear: -kern.sugid_coredump: Enable coredumping set user/group ID processes +kenr.sugid_coredump: Allow setuid/setgid processes to dump core See the info file for gdb, section 5.3 Signals. It's possible to tell gdb how to handle signals, e.g. stop vs. nostop, etc. --- Gary Jennejohn ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Running a program through gdb without interfering
Mel Flynn mel.flynn+fbsd.hack...@mailing.thruhere.net writes: is there a way to have a program run through gdb and gdb only record a segfault, but otherwise let the program run? Yes, just run gdb /path/to/program and type run. [...] sudo *sometimes* segfaults [...] However, it doesn't dump core sudo(1) is setuid root. You need to set kern.sugid_coredump to get it to dump core. [1] In order to get this working I had to put a statically compiled ps in the jail, or the uid test would fail. It has the downside that it lists both jail and host processes, [...] Uh, no. Processes outside the jail are not visible inside it, no matter what version of ps(1) or top(1) or any other such program you use. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Running a program through gdb without interfering
Mel Flynn wrote: [1] In order to get this working I had to put a statically compiled ps in the jail This is a pretty standard practice. I always put these statically built into any jails that don't match the outside system. I use the following crunchgen config to accomplish that. Cheers, Stef # Commands to build in progs ps ipcs netstat pkill top w killall progs systat iostat progs jkill progs kldstat # Link these programs to each other ln pkill pgrep ln w uptime # Libraries which we need libs -lutil -lkvm -ldevstat -lncurses -ldevstat -lm -lnetgraph -lmemstat -lipx ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Running a program through gdb without interfering
On Friday 09 October 2009 11:38:29 Dag-Erling Smørgrav wrote: Mel Flynn mel.flynn+fbsd.hack...@mailing.thruhere.net writes: is there a way to have a program run through gdb and gdb only record a segfault, but otherwise let the program run? Yes, just run gdb /path/to/program and type run. Not what I was looking for. The segfaults are random and the only way to somewhat reliably reproduce it is to have portmaster invoke it as it's PM_SU_CMD. And no, running that same command again doesn't trigger the segfault, so it's something environmental. Hence I'm looking for something like: gdb -batch -x script_with_run_cmd.gdb -exec /usr/local/bin/sudo $argv where somehow I need $argv to be passed as arguments to sudo. I'm thinking i should just wrap it and mktemp(1) a new command script for gdb to use with set args $*, but if anyone has a more clever idea, I'd love to hear it. [...] sudo *sometimes* segfaults [...] However, it doesn't dump core sudo(1) is setuid root. You need to set kern.sugid_coredump to get it to dump core. It still segfaults and doesn't dump: Oct 9 04:34:18 smell kernel: pid 39476 (sudo), uid 0: exited on signal 11 Oct 9 04:36:32 smell kernel: pid 79657 (sudo), uid 0: exited on signal 11 Oct 9 04:36:43 smell kernel: pid 82390 (sudo), uid 0: exited on signal 11 Oct 9 04:51:46 smell kernel: pid 3601 (sudo), uid 0: exited on signal 11 find / -name '*.core' in the jail does not yield anything. [1] In order to get this working I had to put a statically compiled ps in the jail, or the uid test would fail. It has the downside that it lists both jail and host processes, [...] Uh, no. Processes outside the jail are not visible inside it, no matter what version of ps(1) or top(1) or any other such program you use. I'll write this off as pilot error, cause I cannot reproduce it. I saw bash as one of the processes listed in a blank ps run, which isn't installed in the jail, but since I don't have the terminal history anymore, it's entirely possible I ran ps on the host. -- Mel ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Running a program through gdb without interfering
On Friday 09 October 2009 16:50:04 Mel Flynn wrote: On Friday 09 October 2009 11:38:29 Dag-Erling Smørgrav wrote: Mel Flynn mel.flynn+fbsd.hack...@mailing.thruhere.net writes: [...] sudo *sometimes* segfaults [...] However, it doesn't dump core sudo(1) is setuid root. You need to set kern.sugid_coredump to get it to dump core. It still segfaults and doesn't dump: Oct 9 04:34:18 smell kernel: pid 39476 (sudo), uid 0: exited on signal 11 Oct 9 04:36:32 smell kernel: pid 79657 (sudo), uid 0: exited on signal 11 Oct 9 04:36:43 smell kernel: pid 82390 (sudo), uid 0: exited on signal 11 Oct 9 04:51:46 smell kernel: pid 3601 (sudo), uid 0: exited on signal 11 find / -name '*.core' in the jail does not yield anything. FYI, there's one read-only mount into the jail, being /usr/src. I don't see a reason given the commands it segfaults on, for $cwd to be below that.For example it segfaulted on sudo pkg_delete glproto2. Thought I'd mention it to rule it out. -- Mel ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: crashinfo: print the content of ddb capture budder
On Monday 05 October 2009 1:48:06 am Mikolaj Golub wrote:
Hi,
It would be nice if crashinfo(8) were also trying to output the content of ddb
capture buffer. Something like in this patch:
--- crashinfo.sh.orig 2009-10-05 08:26:26.0 +0300
+++ crashinfo.sh 2009-10-05 08:43:56.0 +0300
@@ -304,3 +304,18 @@
echo kernel config
echo
config -x $KERNEL
+
+file=`mktemp /tmp/crashinfo.XX`
+if [ $? -eq 0 ]; then
+ ddb capture -M $VMCORE -N $KERNEL print $file 2/dev/null
+ if [ -s $file ]; then
+ echo
+ echo ddb capture buffer
+ echo
+ cat $file |
+ sed -e 's/p\{10\}p*//' # XXX: this removes the unfilled part of
a capture buffer
+ echo
+ fi
+ rm -f $file
+fi
+
I'm definitely in favor of this. I assume you have tested it locally? Do you
have a sample
crash.X.txt file with it enabled?
--
John Baldwin
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
newfs -r 2
I have found that newfs in 8-STABLE has -r switch with zero default value. I think it should be 1 or 2 by default: as I understand, these sectors are not used usually by filesystem anyway since they are not in last cylinder group. Therefore noone would see the difference in usable space, but this reservation will allow to add gjournal to the filesystem later. BTW, could anyone tell how to learn the last sector that filesystem may really use ? -- Igor Sysoev http://sysoev.ru/en/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Running a program through gdb without interfering
On Fri, 9 Oct 2009, Mel Flynn wrote: On Friday 09 October 2009 11:38:29 Dag-Erling Smørgrav wrote: Mel Flynn mel.flynn+fbsd.hack...@mailing.thruhere.net writes: is there a way to have a program run through gdb and gdb only record a segfault, but otherwise let the program run? Yes, just run gdb /path/to/program and type run. Not what I was looking for. The segfaults are random and the only way to somewhat reliably reproduce it is to have portmaster invoke it as it's PM_SU_CMD. And no, running that same command again doesn't trigger the segfault, so it's something environmental. Hence I'm looking for something like: gdb -batch -x script_with_run_cmd.gdb -exec /usr/local/bin/sudo $argv where somehow I need $argv to be passed as arguments to sudo. I'm thinking i should just wrap it and mktemp(1) a new command script for gdb to use with set args $*, but if anyone has a more clever idea, I'd love to hear it. This won't work. You can't debug setuid programs (for reasons which should be obvious). You could do it if you ran everything as root, but it sounds like the bug doesn't occur in that case. -- Nate Eldredge n...@thatsmathematics.com___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Running a program through gdb without interfering
On Friday 09 October 2009 16:50:04 Mel Flynn wrote: On Friday 09 October 2009 11:38:29 Dag-Erling Smørgrav wrote: Mel Flynn mel.flynn+fbsd.hack...@mailing.thruhere.net writes: is there a way to have a program run through gdb and gdb only record a segfault, but otherwise let the program run? Yes, just run gdb /path/to/program and type run. Not what I was looking for. The segfaults are random and the only way to somewhat reliably reproduce it is to have portmaster invoke it as it's PM_SU_CMD. And no, running that same command again doesn't trigger the segfault, so it's something environmental. Hence I'm looking for something like: gdb -batch -x script_with_run_cmd.gdb -exec /usr/local/bin/sudo $argv where somehow I need $argv to be passed as arguments to sudo. I'm thinking i should just wrap it and mktemp(1) a new command script for gdb to use with set args $*, but if anyone has a more clever idea, I'd love to hear it. Dead end path :/ % bin/gdbsudo echo hi /tmp/gdbsudo.F3kdwJ:1: Error in sourced command file: /usr/local/bin/sudo: Permission denied. % ls -l /usr/local/bin/sudo ---s--x--x 2 root wheel 116380 Oct 8 18:31 /usr/local/bin/sudo % sudo chmod g+r /usr/local/bin/sudo % bin/gdbsudo echo hi (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...sudo: must be setuid root Program exited with code 01. Perhaps the cause of it not dumping core either. Would've been nice to know why it segfaults, but not nice enough to keep digging. -- Mel ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: sigwait - differences between Linux FreeBSD
On Thu, Oct 08, 2009 at 01:02:09PM +0300, Kostik Belousov wrote: On Thu, Oct 08, 2009 at 11:53:21AM +1100, Stephen Hocking wrote: In my efforts to make the xrdp port more robust under FreeBSD, I have discovered that sigwait (kind of an analogue to select(2), but for signals rather than I/O) re-enables ignored signals in its list under Linux, but not FreeBSD. The sesman daemon uses SIGCHLD to clean up after a session has exited. Under Linux this works OK, under FreeSBD it doesn't. I have worked around it in a very hackish manner (define a dummy signal handler and enable it using signal, which means that the sigwait call can then be unblocked by it), but am wondering if anyone else has run across the same problem, and if so, if they fixed it in an elegant manner. Also, does anyone know the correct semantics of sigwait under this situation? ports@ is the wrong list to discuss the issue in the base system. Solaris 10 sigwait(2) manpage says the following: If sigwait() is called on an ignored signal, then the occurrence of the signal will be ignored, unless sigaction() changes the disposition. We have the same behaviour as Solaris, ingored signals are not queued or recorded regardeless of the presence of sigwaiting thread. POSIX permits both behaviours here: a blocked and ignored signal may or may not be discarded immediately on generation. Making this depend on whether there is a sigwaiting thread seems broken, and I don't think Linux does that. I think your very hackish approach is correct: set up a dummy signal handler after blocking the signal. Additionally, POSIX requires applications to set the SA_SIGINFO flag if they want queuing. This applies even if the signals are blocked and received using sigwaitinfo(2) or sigtimedwait(2). The SA_SIGINFO flag can only be set by setting a handler using sigaction(2). (Note, this does not mean that all signals are queued if SA_SIGINFO is set. It means that signals may not be queued if SA_SIGINFO is not set.) -- Jilles Tjoelker ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Running a program through gdb without interfering
Mel Flynn mel.flynn+fbsd.hack...@mailing.thruhere.net writes: Dag-Erling Smørgrav d...@des.no writes: Yes, just run gdb /path/to/program and type run. Not what I was looking for. The segfaults are random and the only way to somewhat reliably reproduce it is to have portmaster invoke it as it's PM_SU_CMD. And no, running that same command again doesn't trigger the segfault, so it's something environmental. Hence I'm looking for something like: gdb -batch -x script_with_run_cmd.gdb -exec /usr/local/bin/sudo $argv where somehow I need $argv to be passed as arguments to sudo. I'm thinking i should just wrap it and mktemp(1) a new command script for gdb to use with set args $*, but if anyone has a more clever idea, I'd love to hear it. Why look for a clever option, when the simple one will do just fine? :gdb-script-$$ echo set args $@ gdb-script-$$ echo run gdb-script-$$ gdb -batch -x gdb-script-$$ /usr/local/bin/sudo It still segfaults and doesn't dump: Oct 9 04:34:18 smell kernel: pid 39476 (sudo), uid 0: exited on signal 11 Oct 9 04:36:32 smell kernel: pid 79657 (sudo), uid 0: exited on signal 11 Oct 9 04:36:43 smell kernel: pid 82390 (sudo), uid 0: exited on signal 11 Oct 9 04:51:46 smell kernel: pid 3601 (sudo), uid 0: exited on signal 11 find / -name '*.core' in the jail does not yield anything. Add 'ulimit -c unlimited' somewhere in the script before it invokes sudo. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Running a program through gdb without interfering
Nate Eldredge n...@thatsmathematics.com writes: This won't work. You can't debug setuid programs (for reasons which should be obvious). Ah, true, but easily fixable. Add a sysctl for it (just copy-paste the declaration for kern.sugid_coredump and change the name) and check its value in p_candebug() (hint: if (credentialchanged)). DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
sysinstall colours
hi there, sysinstall is probably one of those ancient relics everybody tries to avoid dealing with from a developers point of view but i just found this beautiful screenie of a (probably) ncurse-based installer: http://www.phoronix.net/image.php?id=yoper_2009_betaimage=yoper_dresden_7_lrg i was surprised how much better it looks with those nice colours compared to sysinstall. is there any way the sysinstall colours could be adjusted (without a lot of work) to also feature such beautiful colours? i had a quick look at the sysinstall, libdialog and ncurses sources and to me it seems that to change sysinstall's colours the hardcoded values of COLOR_BLACK COLOR_RED COLOR_GREEN COLOR_YELLOW COLOR_BLUE COLOR_MAGENTA COLOR_CYAN COLOR_WHITE have to be changed in contrib/ncurses/ncurses/base/lib_color.c or is there an easier way? because this would of course affect all apps that are linked to ncurses. cheers. alex ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: crashinfo: print the content of ddb capture budder
On Fri, 9 Oct 2009 11:28:11 -0400 John Baldwin wrote:
JB On Monday 05 October 2009 1:48:06 am Mikolaj Golub wrote:
Hi,
It would be nice if crashinfo(8) were also trying to output the content of
ddb
capture buffer. Something like in this patch:
--- crashinfo.sh.orig2009-10-05 08:26:26.0 +0300
+++ crashinfo.sh2009-10-05 08:43:56.0 +0300
@@ -304,3 +304,18 @@
echo kernel config
echo
config -x $KERNEL
+
+file=`mktemp /tmp/crashinfo.XX`
+if [ $? -eq 0 ]; then
+ddb capture -M $VMCORE -N $KERNEL print $file 2/dev/null
+if [ -s $file ]; then
+echo
+echo ddb capture buffer
+echo
+cat $file |
+sed -e 's/p\{10\}p*//' # XXX: this removes the unfilled
part of a capture buffer
+echo
+fi
+rm -f $file
+fi
+
JB I'm definitely in favor of this. I assume you have tested it locally? Do
you have a sample
JB crash.X.txt file with it enabled?
I have tested it on 8.0.
zhuzha:~% ls -l /var/crash/vmcore.23
-rw--- 1 root wheel 166703104 2009-10-05 08:03 /var/crash/vmcore.23
zhuzha:~% sudo crashinfo
Writing crash summary to /var/crash/core.txt.23.
zhuzha:~% grep -B5 -A30 'ddb capture buffer' /var/crash/core.txt.23
kernel config
config: File /boot/kernel.old/kernel doesn't contain configuration file. Either
unsupported, or not compiled with INCLUDE_CONFIG_FILE
ddb capture buffer
db:0:kdb.enter.panic show pcpu
cpuid= 0
dynamic pcpu= 0x68ee80
curthread= 0xc4a1ad80: pid 2276 sysctl
curpcb = 0xe6d44d90
fpcurthread = none
idlethread = 0xc4576900: pid 11 idle: cpu0
APIC ID = 0
currentldt = 0x50
spin locks held:
db:0:kdb.enter.panic show allpcpu
Current CPU: 0
cpuid= 0
dynamic pcpu= 0x68ee80
curthread= 0xc4a1ad80: pid 2276 sysctl
curpcb = 0xe6d44d90
fpcurthread = none
idlethread = 0xc4576900: pid 11 idle: cpu0
APIC ID = 0
currentldt = 0x50
spin locks held:
cpuid= 1
dynamic pcpu= 0x34ffe80
curthread= 0xc5837480: pid 2191 screen
curpcb = 0xe6e5ed90
fpcurthread = none
idlethread = 0xc4576b40: pid 11 idle: cpu1
zhuzha:~% tail /var/crash/core.txt.23
mi_switch(104,0,c0c798d3,1d6,44,...) at mi_switch+0x200
sleepq_switch(c0dc8190,0,c0c798d3,26e,0,...) at sleepq_switch+0x15f
sleepq_timedwait(c0dc7ee0,44,c0c7793c,0,0,...) at sleepq_timedwait+0x6b
_sleep(c0dc7ee0,0,44,c0c7793c,2710,...) at _sleep+0x339
scheduler(0,141ec00,141ec00,141e000,1425000,...) at scheduler+0x23e
mi_startup() at mi_startup+0x96
begin() at begin+0x2c
db:0:kdb.enter.panic call doadump
zhuzha:~%
Actually the last echo in the patch looks like is not necessary.
Do you want the whole crash.23.txt file for review?
Also, I remember I tested it on crashdump of a kernel without ddb support and
no issues were noticed too.
--
Mikolaj Golub
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: sysinstall colours
On Fri, 9 Oct 2009 21:52 +0200, alexbestms@ wrote: hi there, sysinstall is probably one of those ancient relics everybody tries to avoid dealing with from a developers point of view but i just found this beautiful screenie of a (probably) ncurse-based installer: http://www.phoronix.net/image.php?id=yoper_2009_betaimage=yoper_dresden_7_lrg i was surprised how much better it looks with those nice colours compared to sysinstall. is there any way the sysinstall colours could be adjusted (without a lot of work) to also feature such beautiful colours? i had a quick look at the sysinstall, libdialog and ncurses sources and to me it seems that to change sysinstall's colours the hardcoded values of COLOR_BLACK COLOR_RED COLOR_GREEN COLOR_YELLOW COLOR_BLUE COLOR_MAGENTA COLOR_CYAN COLOR_WHITE have to be changed in contrib/ncurses/ncurses/base/lib_color.c or is there an easier way? because this would of course affect all apps that are linked to ncurses. cheers. alex sysinstall looks like this too when it is ran in a gnome terminal or some other terminal that is ran in a X environment. -- ;; dataix.net!jhell 2048R/89D8547E 2009-09-30 ;; BSD since FreeBSD 4.2Linux since Slackware 2.1 ;; 85EF E26B 07BB 3777 76BE B12A 9057 8789 89D8 547E ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: sysinstall colours
Alexander, ==8== http://www.phoronix.net/image.php?id=yoper_2009_betaimage=yoper_dresden_7_lrg ==8== The head maintainer of Yoper; Tobias G, runs a kernel patchset I work on from http://zen-sources.org as his default kernel. I am sure he would be more than happy to discuss some of their methods if you are interested in learning or modifying the current sysinstall system. Not sure how much this will help; however, it cannot hurt to ask. Taking ideas from Linux distros is rarely a good idea I've found though :) =jt ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: sysinstall colours
On Fri, Oct 9, 2009 at 12:52 PM, Alexander Best alexbes...@math.uni-muenster.de wrote: hi there, sysinstall is probably one of those ancient relics everybody tries to avoid dealing with from a developers point of view but i just found this beautiful screenie of a (probably) ncurse-based installer: http://www.phoronix.net/image.php?id=yoper_2009_betaimage=yoper_dresden_7_lrg i was surprised how much better it looks with those nice colours compared to sysinstall. is there any way the sysinstall colours could be adjusted (without a lot of work) to also feature such beautiful colours? i had a quick look at the sysinstall, libdialog and ncurses sources and to me it seems that to change sysinstall's colours the hardcoded values of COLOR_BLACK COLOR_RED COLOR_GREEN COLOR_YELLOW COLOR_BLUE COLOR_MAGENTA COLOR_CYAN COLOR_WHITE have to be changed in contrib/ncurses/ncurses/base/lib_color.c or is there an easier way? because this would of course affect all apps that are linked to ncurses. cheers. alex Seriously?!?!?! All the problems with sysinstall, and your idea is to change the color? Are you trying to start a bikeshed? If so, I prefer pink. -- randi ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Running a program through gdb without interfering
On Friday 09 October 2009 21:27:21 Dag-Erling Smørgrav wrote: Mel Flynn mel.flynn+fbsd.hack...@mailing.thruhere.net writes: Dag-Erling Smørgrav d...@des.no writes: Yes, just run gdb /path/to/program and type run. Not what I was looking for. The segfaults are random and the only way to somewhat reliably reproduce it is to have portmaster invoke it as it's PM_SU_CMD. And no, running that same command again doesn't trigger the segfault, so it's something environmental. Hence I'm looking for something like: gdb -batch -x script_with_run_cmd.gdb -exec /usr/local/bin/sudo $argv where somehow I need $argv to be passed as arguments to sudo. I'm thinking i should just wrap it and mktemp(1) a new command script for gdb to use with set args $*, but if anyone has a more clever idea, I'd love to hear it. Why look for a clever option, when the simple one will do just fine? Cause I don't know how much of the cause of this bug I'm influencing. Even though this is now the simple solution, it would be simpler if gdb (or another debugger) could work similar as sudo, where it would take the first argument as binary and the rest as arguments to the binary. This would do away with some extra IO I'm now creating. Though, it's unlikely it is related to IO, there is no pattern that I've found yet for the segfault, so I'm trying to limit any extra stuff. I'll patch the kernel tomorrow with the new sysctl and see how far that gets me. Add 'ulimit -c unlimited' somewhere in the script before it invokes sudo. I'll add it. -- Mel ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
