>
>
>I gave you the command:
>
>dbx `which fvwm2` core
>
>it sounds like you ran:
>
>dbx core
>
>perhaps the "which" command isn't working right.
>As I remember, you executed fvwm using the full path.
>Try running it this way instead:
>
>dbx /lsi/home/bsferraz/bin/fvwm-2.5.5/bin/fvwm core
>
>then type in "where".
>
>
Yeah, 'which' didn't seem to work before. The above works though.
Seems FvwmTaskBar is causing the core dump. As I mentioned before,
once I add '-C TrueColor', or '-I 0x28' for that matter, FvwmTaskBar
craps out. Here's what happens when I run the above.
Reading fvwm
dbx: core object name "FvwmTaskBar" doesn't match object name "fvwm"
core file ignored. Use -f to force loading of corefile
dbx: warning: core file header read failed
When re-run with FvwmTaskBar path included:
Reading FvwmTaskBar
core file header read successfully
Reading ld.so.1
Reading libm.so.1
Reading libXpm.so.4.11
Reading libpng.so.3
Reading libSM.so.6
Reading libICE.so.6
Reading libXext.so.0
Reading libX11.so.4
Reading libsocket.so.1
Reading libnsl.so.1
Reading libc.so.1
Reading libucb.so.1
Reading libresolv.so.2
Reading libelf.so.1
Reading libdl.so.1
Reading libmp.so.2
Reading libc_psr.so.1
Reading en_US.so.2
Reading xlibi18n.so.2
Reading xomEuro.so.2
program terminated by signal ABRT (Abort)
(/lsi/soft/forte/6.0-update1/WS6U1/bin/sparcv9/dbx) where
=>[1] _kill(0x0, 0x6, 0xff033a30, 0x0, 0xffffffff, 0x0), at 0xff0182c4
[2] abort(0xff033a30, 0x19, 0xff03b654, 0x0, 0xff210000, 0x0), at
0xfefb9468
[3] PrintXErrorAndCoredump(0x66148, 0xffbeebb0, 0x62788, 0x0, 0x0,
0x0), at 0x34a88
[4] ErrorHandler(0x66148, 0xffbeebb0, 0x20bfc, 0x0, 0xff033a30,
0xff1972e0), at 0x20c3c
[5] _XError(0xff215a5c, 0x66ed0, 0xff210000, 0x66148, 0x40, 0x66148),
at 0xff1a75c4
[6] _XEventsQueued(0x66148, 0x66ed0, 0xff210000, 0x40, 0x0, 0x0), at
0xff19af00
[7] XPending(0x66148, 0x66148, 0x1, 0x0, 0xff036abc, 0xffffffff), at
0xff19b69c
[8] FPending(0x66148, 0x0, 0xff036abc, 0xff036abc, 0xff036abc, 0x6),
at 0x34484
[9] LoopOnEvents(0x4, 0x0, 0x1, 0x0, 0xffbeef08, 0x5d400), at 0x1f3a4
[10] EndLessLoop(0x0, 0x436f0, 0x0, 0x42d, 0x17, 0xb4), at 0x1ca28
[11] main(0x0, 0xffbef094, 0xffbef0b0, 0x610ec, 0x0, 0x0), at 0x1c908
>
>Hmm, one of the other developers will probably look at this.
>I see you ran with -C Truecolor, but the cards first Truecolor
>visual is 8 bit. I think that might be a problem.
>
>It might be better to use the visualid as in:
>
>-I 0x28
>
>instead of
>
>-C TrueColor
>
Actually, using '-C TrueColor' does allow me to view pixmaps correctly
now under fvwm. It's just that once I add that option, I start
receiving those Errors and FvwmTaskBar core dumps. So, I correct one
problem, introduce more.
>I'm sorry, I should know exactly where the CDE stderr ends up,
>but I hated CDE so much, I just had it removed from my workstation.
>
>I did run with it once...OK, I found it.
>The fvwm output should be in $HOME/.xsession-errors
>
>Sorry to mislead you.
>
>
>
PrintInfo Colors output doesn't seem to be going to ~/.xsession-errors.
Maybe I should try running another fvwm process on top of the existing
one from the command line, but redirect its output to another file. I
suppose this is kind of what you were instructing me to do before with
the '>'. Any ideas here?
Thanks,
Ben
--
Visit the official FVWM web page at <URL: http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to majordomo_at_fvwm.org.
To report problems, send mail to fvwm-owner_at_fvwm.org.
Received on Wed Dec 18 2002 - 17:14:21 GMT