Running a program through gdb without "interfering"

Dag-Erling Smørgrav des at
Fri Oct 9 19:27:23 UTC 2009

Mel Flynn <mel.flynn+fbsd.hackers at> writes:
> Dag-Erling Smørgrav <des at> 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?

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.

Dag-Erling Smørgrav - des at

More information about the freebsd-hackers mailing list