Subject: Changes committed

From: [email-masked] (Paul D. Smith)
Date: 06 Nov 1998 18:34:01 -0500

I just committed a bunch of changes, including lots of memory fixes
(leaks, uninitialized access, etc.), performance enhancements to the
module interaction code, some build fixes, some configuration fixes,
etc.  I implemented a first-cut at the generic DB() macro for debugging
info.  It doesn't have the module name stuff in it, and right now it all
prints to stderr; we should probably have it print to a module-specific
file or something.

I compiled on SunOS and Solaris, and did a successful make distcheck on
Solaris, too.

It seems to run OK, barring the odd things dealing with menus and moving
windows that others have mentioned.  And of course my "FvwmForm exits
too fast" bug I just found :).

I'll run some purify on fvwm2 and post it, so people can see what's
left.  Note I'm just going to be doing some basic stuff, so I might miss
some more esoteric things.

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <[email-masked]>         Network Management Development
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
-------------------------------------------------------------------------------
   These are my opinions---Nortel Networks takes no responsibility for them.
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked].

---

From: Dan Espen <[email-masked]>
Date: Sat, 07 Nov 1998 08:52:32 -0500

> prints to stderr; we should probably have it print to a module-specific

Ever since the last 2 large commits, the fvwm2 that I build core dumps
while reading the config file.

This is the stack that I see:

#1  0xef5fc1b8 in cleanfree ()
#2  0xef5fb2cc in _malloc_unlocked ()
#3  0xef5fb1c4 in malloc ()
#4  0x58ca4 in safemalloc (length=11) at ../../version-2_1_0/libs/safemalloc.c:18
#5  0x5877c in stripcpy (source=0x81867 "FvwmBanner\n") at ../../version-2_1_0/libs/Strings.c:104
#6  0x423b8 in AddToMenu (menu=0x89010, item=0x72e58 "%mini.xbiff.xpm%Ba&nner",
    action=0x81864 "  \tFvwmBanner\n", fPixmapsOk=1, fNoPlus=0)
    at ../../version-2_1_0/fvwm/menus.c:2328
#7  0x21994 in add_another_item (eventp=0x6d890, w=41, tmp_win=0x0, context=8,
    action=0x8184a "\"%mini.xbiff.xpm%Ba&nner\"   \tFvwmBanner\n", Module=0xefffe84c)
    at ../../version-2_1_0/fvwm/builtins.c:522
#8  0x33be4 in ExecuteFunction (
    Action=0xefffe860 "+ \"%mini.xbiff.xpm%Ba&nner\"   \tFvwmBanner\n", tmp_win=0x0,
    eventp=0x6d890, context=8, Module=-1) at ../../version-2_1_0/fvwm/functions.c:247
#9  0x4cfc8 in ReadSubFunc (eventp=0x6d890, junk=41, tmp_win=0x0, context=8,
    action=0xefffe860 "+ \"%mini.xbiff.xpm%Ba&nner\"   \tFvwmBanner\n", Module=0xefffeddc,
    piperead=0) at ../../version-2_1_0/fvwm/read.c:165
#10 0x4d06c in ReadFile (eventp=0x6d890, junk=41, tmp_win=0x0, context=8,
    action=0x8642d "/usr/dje/fvwmrc/.fvwmrc.modules\n", Module=0xefffeddc)
    at ../../version-2_1_0/fvwm/read.c:186
#11 0x33be4 in ExecuteFunction (Action=0xefffedf0 "Read /usr/dje/fvwmrc/.fvwmrc.modules\n",
    tmp_win=0x0, eventp=0x6d890, context=8, Module=-1) at ../../version-2_1_0/fvwm/functions.c:247
#12 0x4cfc8 in ReadSubFunc (eventp=0x6d890, junk=41, tmp_win=0x0, context=8,
    action=0xefffedf0 "Read /usr/dje/fvwmrc/.fvwmrc.modules\n", Module=0xeffff36c, piperead=0)
    at ../../version-2_1_0/fvwm/read.c:165
#13 0x4d06c in ReadFile (eventp=0x6d890, junk=41, tmp_win=0x0, context=8,
    action=0x7bb9d ".fvwm2rc", Module=0xeffff36c) at ../../version-2_1_0/fvwm/read.c:186
#14 0x33be4 in ExecuteFunction (Action=0x5a5c8 "Read .fvwm2rc", tmp_win=0x0, eventp=0x6d890,
    context=8, Module=-1) at ../../version-2_1_0/fvwm/functions.c:247
#15 0x34bd8 in main (argc=1, argv=0xeffff784) at ../../version-2_1_0/fvwm/fvwm.c:380

Since its a core dump during malloc, it looks like the heap is corrupted
in some way.  Not a particularly easy problem to track down without
Purify.  (I'm at home, so I can't use it.)

Am I the only one seeing this problem?

>  Paul D. Smith <[email-masked]>         Network Management Developmen

--
Dan Espen                                Phone: (732) 699-5570
444 Hoes Lane  Room RRC 1C-214           E-mail: [email-masked]
Piscataway, NJ 08854
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked].

---

From: [email-masked]
Date: Sat, 7 Nov 1998 15:37:27 +0100

> Am I the only one seeing this problem?

I'll check that. Seems to be a menu problem.

Bye

Dominik
-- 
Dominik Vogt, Hewlett-Packard GmbH, Dept. BVS
Herrenberger Str.130, 71034 Boeblingen, Germany
phone: 07031/14-4596, fax: 07031/14-3883, [email-masked]
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked].

---

From: [email-masked] (Paul D. Smith)
Date: 07 Nov 1998 10:35:50 -0500

%% Dan Espen <[email-masked]> writes:

  de> Ever since the last 2 large commits, the fvwm2 that I build core dumps
  de> while reading the config file.

  de> Am I the only one seeing this problem?

I don't see it (I'm running 2.1.1 now) and Purify didn't report anything
like that for me, so it must be you're using some feature of configure
that I don't use (my setup is pretty vanilla, actually).

I've got some major (real) work to get done by Monday evening and next
week, and I need to work on a new release of GNU make at some point, so
I won't be able to do too much more (beyond the two minor fixes I
mentioned yesterday) for a bit... I think you're going to need to try
Purifying it :(

Don't know if you guys are aware of it or not, but there's nothing
better for debugging window managers than the Xnest server!  It's a
"virtual server" which opens a window displaying on your regular X
server, but acts like a full-fledged server.  You can test much more
easily, including debugging, using this so it doesn't freeze your normal
display.  Just start it like:

  $ Xnest :1 &

to have it take display:1, then debug fvwm2 like this:

  $ gdb fvwm2
  (gdb) run -display :1

Or, you can attach to a running process (like a module) with:

  $ gdb FvwmButtons <pid>

As long as the bug isn't when something has grabbed the mouse/keyboard,
you can easily debug this stuff.

You can even run remotely: start the Xnest locally, then on the remote
system (where you may have Purify available, for example), you can set
it to display locally.

I know there's an XFree86 Xnest server package.  For other systems you
have to build it yourself since almost no vendors ship it standard;
unfortunately there's no way to build it without building the entire X
source tree :(.  If you want to do that, let me know and I'll give you
some hints.

---

From: Dan Espen <[email-masked]>
Date: Mon, 09 Nov 1998 10:17:40 -0500

> that I don't use (my setup is pretty vanilla, actually).

I'm not sure what my problem is.  I get core dumps at home and at work
with all the latest releases.  The problem is in the XPM library:

 FNH: Freeing non heap memory
 This is occurring while in:
       free           [rtlib.o]
       xpmFreeColorTable [Attrib.c]
       XpmFreeXpmImage [Image.c]
       GetXPMFile     [icons.c:727]
              tmp_win->flags |= SHAPED_ICON;
          #endif
          
       =>   XpmFreeXpmImage(&my_image);
            free(path);
          #endif /* XPM */
          }
       CreateIconWindow [icons.c:76]
       Iconify        [icons.c:935]
       HandleMapRequestKeepRaised [events.c:773]
       CaptureAllWindows [fvwm.c:571]
       Recapture      [builtins.c:3353]
       ExecuteFunction [functions.c:247]
       ComplexFunction [complex.c:159]
       ExecuteFunction [functions.c:253]
       ReadSubFunc    [read.c:160]
       ReadFile       [read.c:181]
       ExecuteFunction [functions.c:247]
       main           [fvwm.c:380]
       _start         [crt1.o]
 Attempting to free block at 0xe4268 in the text section.
 Address 0xe4268 is 14316 bytes past start of global variable "_lib_version".
 This is defined in fvwm2.

I tried initializing  my_image to  zero  which  didn't  help.  My  XPM
library is 3.4j.

When  I comment out the XpmFreeXpmImage,  I don't see any memory leak.
However, I can't  seem to run  fvwm2 2.1.2 to completion under purify,
it  hangs  in  icons.c line  600,   doing a "grabiconsbuttons"  during
startup.

I'm suspecting a bug in the Xpm library, but so far, I don't see it.

---

From: "Charles Hines" <[email-masked]>
Date: Mon, 9 Nov 1998 10:20:11 -0500 (EST)

>>>>> "Paul" == Paul D Smith <[email-masked]> writes:

Paul> Don't know if you guys are aware of it or not, but there's nothing
Paul> better for debugging window managers than the Xnest server!

You can also open up another virtual terminal under Linux and start another
X11 session there.  In fact, something like that will likely be necessary
for solving some bugs.

....
Paul> I know there's an XFree86 Xnest server package.  For other systems you
Paul> have to build it yourself since almost no vendors ship it standard;
Paul> unfortunately there's no way to build it without building the entire X
Paul> source tree :(.  If you want to do that, let me know and I'll give you
Paul> some hints.

There are a couple of other alternatives too that I used to use at work
under AIX:

  VNC:  http://www.orl.co.uk/vnc/
  XMX:  http://www.cs.brown.edu/software/xmx/

VNC behaves a little better than XMX for debugging fvwm, from my experience
(since it is actually an XFree86 X11 server, like Xnest, where XMX is
playing games to achieve that effect).

VNC and XMX are also quite useful for other things too (like remotely
working from home, remote problem solving, and classroom demonstrations)
and probably much easier to build than the full X11 distribution.

Chuck

--
*******************************************************************************
Charles K. Hines <[email-masked]>
IBM Logic Synthesis Developer [BooleDozer (TM)]
Martial Arts Instructor [Modern Arnis and Balintawak Escrima]

         "Go back to sleep, Chuck.  You're just havin' a nightmare
             -- of course, we ARE still in Hell." (Gary Larson)
*******************************************************************************
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked].

---

From: [email-masked]
Date: Mon, 9 Nov 1998 16:46:08 +0100

> X11 session there.  In fact, something like that will likely be necessary

How do I do this?

Dominik

---

From: [email-masked] (Paul D. Smith)
Date: 09 Nov 1998 12:52:46 -0500

de> I'm not sure what my problem is.  I get core dumps at home and at work
  de> with all the latest releases.  The problem is in the XPM library:

  de>  FNH: Freeing non heap memory
                    ^^^^^^^^^^^^^^^ !!!
  de>  This is occurring while in:
  de>        free           [rtlib.o]
  de>        xpmFreeColorTable [Attrib.c]
  de>        XpmFreeXpmImage [Image.c]
  de>        GetXPMFile     [icons.c:727]
  de>             tmp_win-> flags |= SHAPED_ICON;
  de>           #endif
          
  de>        =>   XpmFreeXpmImage(&my_image);
  de>             free(path);
  de>           #endif /* XPM */
  de>           }

It looks to me like your XpmFreeXpmImage tries to free the contents of
the pointer it's passed, not just the things it points to, so it's
trying to free memory on the stack (the my_image structure).  Well,
maybe not, the free is in xpmFreeColorTable.  Hmm.  I don't have xpm
sources handy; do you know what the code looks like there?

  de> I tried initializing my_image to zero which didn't help.  My XPM
  de> library is 3.4j.

Mine says 3.4j, too, when I run strings on the shared lib.

Very odd.  Can you rebuild xpm with debugging on and see anything more?

  de> When I comment out the XpmFreeXpmImage, I don't see any memory
  de> leak.  However, I can't seem to run fvwm2 2.1.2 to completion
  de> under purify, it hangs in icons.c line 600, doing a
  de> "grabiconsbuttons" during startup.

Weird!

The xpmFreeColorTable() function makes me ask: what about the "color
normalization" code for pixmaps?  Where does that fit into fvwm and how
is it invoked?  Maybe there's a bug in here which is corrupting pixmaps
somehow?  I wonder if you have an older or newer version of that code
lying around somewhere?  Have you tried to "cvs co" a shiny new version
to see if it happens there, too?

---

From: "Charles Hines" <[email-masked]>
Date: Mon, 9 Nov 1998 14:01:48 -0500 (EST)

>>>>> "dv" == dominik vogt <[email-masked]> writes:

>> X11 session there.  In fact, something like that will likely be necessary

dv> How do I do this?

If I remember correctly, like this:

  startx -- :1

Then just use Alt-Ctrl-F7/F8 to toggle between :0 and :1 (I believe that by
default F1 to F6 are text virtual terminals and F7 to F12 are for X :0 to
:5).

That's also useful if you need to run a program under a different
visual/depth than what your current X session is (ie - programs that can
only handle 8bpp PseudoColor when you might normally run 24bpp TrueColor)
since XFree86 doesn't currently support multiple visual types.

Chuck

---

From: Dan Espen <[email-masked]>
Date: Mon, 09 Nov 1998 15:40:13 -0500

> to see if it happens there, too?

Thanks Paul, you put your finger right on it.
Also recompiling the xpm library with debug led me right to it.

The colorlimiting code was replacing the malloced storage
in the XPM color structure with some static storage.
(It seemed very efficient to me at the time.)

I've checked in a fix for this.