Subject: fvwm2 Core dump info

From: [email-masked] (Paul D. Smith)
Date: 01 Dec 1998 16:24:00 -0500

OK, I've spent most of the afternoon trying to track down the core I'm
getting running the tests.

First, note I compiled a non-Purify version of fvwm2 and I _also_ get a
core dump using that.  It seems to me that anyone using one of the
debugging mallocs (there are versions around for Linux, for example,
that use mmap() to allocate memory, so that when you free it (munmap) it
becomes completely invalid and any access yields an immediate core)
should be able to see this!

Second, note that the core dump appears to happen a long time after the
actual bug; at least according to Purify there's a lot of FMR (Free
Memory Reads) going on before the core dump.  I tried to track the first
one, assuming that's the culprit.  There _DOES_ appear to be a bug here.

The first FMR that Purify finds is during the run of the "function
test_func" complex function.  It's trying to access memory in the
FvwmWindow struct; that struct has been freed:

  FMR: Free memory read
    * This is occurring while in:
          ComplexFunction [complex.c:155]
          ExecuteFunction [functions.c:260]
          HandleButtonPress [events.c:1138]
          DispatchEvent  [events.c:155]
          HandleEvents   [events.c:176]
          main           [fvwm.c:479]
          _start         [crt1.o]
    * Reading 4 bytes from 0x153c78 in the heap.
    * Address 0x153c78 is 20 bytes past end of a freed block at 0x153c60

ComplexFunction():155 is just:

	  if(tmp_win)
==>	    w = tmp_win->frame;

I checked this value of Tmp_win when ExecuteFunction() is entered, and
again when ComplexFunction is entered, and it's perfectly valid.

Then it continues on, and during the processing of the test_func
function, it does a "Recapture":

  ##### REFRESH WINDOW, REFRESH, RECAPTURE

   + "I" RefreshWindow
   + "I" RefreshWindow 	 	 	
   + "I" RefreshWindow wäepik-ö .-,poci32
   + "I" Refresh
   + "I" Refresh 	 	 	 	
   + "I" Refresh .-3mölp 9 n a.d.ök3qj0
   + "I" Recapture
   + "I" Recapture	 	 	 
   + "I" Recapture .-QW,ÖKcäük,.-qköcli qopiuw

It's the first Recapture that seems to be causing the problem.

OK, so we call builtins.c:Recapture().  That calls
fvwm.c:CaptureAllWindows().  It's not an initial capture, so it goes to
the else-clause at line 593.

This appears to go through every window.  At some point (in my case it
was actually the first time through the loop) it's going to find the
current window as tmp.  Then, at line 621, it calls Destroy(tmp).

In misc.c:Destroy(), it frees all the memory the window points to, then
at line 211, it frees the FvwmWindow structure itself.

Boom.

Now the global Tmp_win pointer and all the values of tmp_win,
etc. passed as arguments to ComplexFunction, etc. are invalid; they're
pointing to freed memory.  The next attempt to dereference them will
fail.

Not sure what the story is _supposed_ to be here, but it seems like that
Destroy isn't such a good idea?  Or is the "current" window supposed to
be protected somehow?  Or something?

Anyway, I'll comment out those Recapture calls and see if it gets
further.

-- 
-------------------------------------------------------------------------------
 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: [email-masked] (Paul D. Smith)
Date: 01 Dec 1998 16:38:40 -0500

It looks like the Destroy command has the same problem; after I removed
the Recapture calls I get this FMR:

 FMR: Free memory read (28 times):
   * This is occurring while in:
         ComplexFunction [complex.c:155]
         ExecuteFunction [functions.c:260]
         HandleButtonPress [events.c:1144]
         DispatchEvent  [events.c:161]
         HandleEvents   [events.c:182]
         main           [fvwm.c:479]
   * Reading 4 bytes from 0x154a38 in the heap.
   * Address 0x154a38 is 24 bytes into a freed  block at 0x154a20 of 508 bytes.
   * This block was allocated from:
         malloc         [rtlib.o]
         calloc         [rtlib.o]
         AddWindow      [add_window.c:114]
         HandleMapRequestKeepRaised [events.c:726]
         HandleMapRequest [events.c:705]
         DispatchEvent  [events.c:161]
   * There have been 3 frees since this block was freed from:
         free           [rtlib.o]
         Destroy        [misc.c:211]
         destroy_function [builtins.c:753]
         ExecuteFunction [functions.c:260]
         ComplexFunction [complex.c:159]
         ExecuteFunction [functions.c:260]