On Tue, 5 Feb 2008, Dominik Vogt wrote:

On Tue, Feb 05, 2008 at 03:00:18AM +0600, Roman S Dubtsov wrote:
On Tuesday 05 February 2008, Dominik Vogt wrote:
[snip]
There is no output of FvwmButtons in there.  Can you please post
a stack trace in a new thread please?

Log file has these lines that are related to FvwmButtons (starting from line
52):

ComboPanel: Cause of next X Error.
   Error: 13 (BadGC (invalid GC parameter))
   Major opcode of failed request:  70 (PolyFillRectangle)
   Minor opcode of failed request:  0
   Resource id of failed request:  0x3000020

I doubt I will be able to post a stack trace since FvwmButtons did not dump
core, they just exited due to some error condition. (The message above looks
like it is from default X11 error handler which exists after printing a error
AFAIK). Could you please hint me how to obtain log file solely from
FvwmButtons?

You can't.  Most of the modules, including FvwmButtons, do not
print much to the console.  FvwmButtons should really write a core
file here as it crashes with abort().  I have committed a patch
that tries to force a core by accessing a null pointer instead.

Actually you could write up a script that lies inbetween fvwm and the modules to do some redirection of output. But since the modules mostly don't generate any output that wouldn't be of mush help. However it is fully possible to attach a gdb process to any running module do do live debugging. The attached script starts a module and then opens an xterm with gdb attached to that module. It should be put into the module path
and then used as

DebugModule FvwmModule module arguments

/Viktor
#!/bin/sh
i=1
args=""
while [ $i -lt 6 ]
do
        args="$args $1"
        i=`expr $i + 1`
        shift
done
title="gdb: $1"
module=$1
shift
which=`which which`
module=`env PATH=$FVWM_MODULEDIR $which $module`
$module $args "$@" &
module_pid=$!
xterm -T "$title" -e gdb $module $module_pid

Reply via email to