Subject: Purify test results

From: Dan Espen <[email-masked]>
Date: Thu, 30 Nov 2000 09:35:06 -0500

This morning I am unable to reproduce the problem with the FvwmWindow
pointers.  I don't think the new purify.fvwm2rc is fully functional
so I ran tests using the new one (first) and then the old one.
I still am unable to start 2.3.25 when I have overlapping
windows, but removing the windows before I start seems to bypass the
problem.  There were lots of duplicates in the log files so I trimmed them
a bit.

-- 
Dan Espen
444 Hoes Lane  Room RRC 1C-214             E-mail: [email-masked]
Piscataway, NJ 08854                       Phone: (732) 699-5570

---

From: Dominik Vogt <[email-masked]>
Date: Sat, 2 Dec 2000 08:00:13 +0100

On Thu, Nov 30, 2000 at 09:35:06AM -0500, Dan Espen wrote:
> problem.

I still need a config file or an explanation :-)

> There were lots of duplicates in the log files so I trimmed them
> a bit.

Uh, isn't it possible to tell Purify not to report the same
memory leak dozens of times?

Bye

Dominik ^_^  ^_^

--
Dominik Vogt, [email-masked]
Reply-To: [email-masked]
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
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: Dominik Vogt <[email-masked]>
Date: Sat, 2 Dec 2000 10:48:32 +0100

> problem.  There were lots of duplicates in the log files so I trimmed them

I can't find some of these errors, Dan.  Can you please check
which specific WindowId line triggers this error:

-----------------------------------------------------------
ABR: Array bounds read:
  * This is occurring while in:
        execute_function [functions.c:1011]
-->     WindowIdFunc   [conditional.c:806]
        execute_function [functions.c:1053]
        old_execute_function [functions.c:1117]
        execute_complex_function [functions.c:1580]
        execute_function [functions.c:1070]
        old_execute_function [functions.c:1117]
        execute_complex_function [functions.c:1580]
        execute_function [functions.c:1070]
        do_menu        [menus.c:885]
        menu_func      [menus.c:5139]
        staysup_func   [menus.c:5155]
        execute_function [functions.c:1053]
        old_execute_function [functions.c:1117]
        run_command_stream [read.c:143]
        run_command_file [read.c:217]
        ReadFile       [read.c:269]
        execute_function [functions.c:1053]
        old_execute_function [functions.c:1117]
        ExecuteModuleCommand [module_interface.c:641]
  * Reading 1 byte from 0x19f14f in the zero'd data, bss section.
  * Address 0x19f14f is       35 bytes past start of global variable "pure_thread_stacks_overlap".
    This is defined in fvwm2.
-----------------------------------------------------------

and which ...Path command triggers this one:

-----------------------------------------------------------
ABW: Array bounds write:
  * This is occurring while in:
        strIns         [envvar.c:130]
        envExpand      [envvar.c:267]
        envDupExpand   [envvar.c:328]
        setPath        [System.c:77]
-->     setModulePath  [builtins.c:888]
        execute_function [functions.c:1053]
        old_execute_function [functions.c:1117]
        run_command_stream [read.c:143]
        run_command_file [read.c:217]
        ReadFile       [read.c:269]
        execute_function [functions.c:1053]
        old_execute_function [functions.c:1117]
        ExecuteModuleCommand [module_interface.c:641]
        ExecuteCommandQueue [module_interface.c:1494]
        My_XNextEvent  [events.c:2420]
        HandleEvents   [events.c:2558]
        main           [fvwm.c:730]
        _start         [crt1.o]
  * Writing 1 byte to 0x28459e in the heap.
  * Address 0x28459e is 1 byte past end of a malloc'd block at 0x284568 of 54 bytes.
  * This block was allocated from:
        malloc         [rtlib.o]
        safemalloc     [safemalloc.c:42]
        envDupExpand   [envvar.c:322]
        setPath        [System.c:77]
        setModulePath  [builtins.c:888]
        execute_function [functions.c:1053]
        old_execute_function [functions.c:1117]
        run_command_stream [read.c:143]
        run_command_file [read.c:217]
        ReadFile       [read.c:269]
        execute_function [functions.c:1053]
        old_execute_function [functions.c:1117]
        ExecuteModuleCommand [module_interface.c:641]
        ExecuteCommandQueue [module_interface.c:1494]
        My_XNextEvent  [events.c:2420]
        HandleEvents   [events.c:2558]
        main           [fvwm.c:730]
        _start         [crt1.o]
-----------------------------------------------------------

The second error seems to come from a module command, but the test
script does not start modules.  Did you modify the script?

Bye

Dominik ^_^  ^_^

---

From: Dan Espen <[email-masked]>
Date: Sat, 02 Dec 2000 08:01:01 -0500

> I still need a config file or an explanation :-)

Sorry.

Start fvwm from your .xinitrc something like

fvwm2 ; fvwm2 ; fvwm2

(I actually use a loop.)

I use this for placement:

Style "*"           ActivePlacement, SmartPlacement

then place windows on more  than one page,  make sure they overlap and
cover the screen so that they would need placement.

then quit fvwm and let it restart.

Normally, fvwm just starts up with all the windows in the correct
position.

After your fixes from a  week ago (or  so), I get  a rubberband and  a
position feedback box during startup and fvwm is completely locked up.
No button presses or keyboard keys work.

I didn't do this a lot, but it didn't seem completely consistent.
It didn't always lock up.

We  had a similar  problem last summer where fvwm  was trying to place
windows during  startup (which it should  never  do), but that problem
didn't include a lockup.

On the subject of the FvwmWindow pointers, do you think you might have
fixed the problem?

> memory leak dozens of times?

When you run in GUI mode, it combines like events to some extent.
Purify in GUI mode on the same display that fvwm uses can lead to
lockups.  I haven't read the man page recently though...

---

From: Dan Espen <[email-masked]>
Date: Sat, 02 Dec 2000 17:39:35 -0500

> which specific WindowId line triggers this error:

Since it happens twice it seems like its a good bet its the
blank ones.  I've put it quite a bit of tracing code, and so far,
I don't see it either.

> and which ...Path command triggers this one:

What you see here is the read command arriving from FvwmTalk.
Since this happened once, its the first module command with data.
The "54" looks like the number this logic produces when
it sees:

ModulePath $HOME/bin/fvwm2:/usr/local/libexec/fvwm/2.1.2

and $HOME set to /u/dane

I've got a test module to test envDupExpand but so far, I don't see it.
I start out with no module path at all.

I'll get to re-running Purify, but its painfully slow from home.

Got to take a break.  Later.

---

From: Dominik Vogt <[email-masked]>
Date: Sun, 3 Dec 2000 15:01:04 +0100

> No button presses or keyboard keys work.

Got that one.  I removed all the XAllowEvents() calls in the move
code, but during startup, the pointer was grabbed synchronously,
i.e. fvwm locked up waiting for pointer events that were queued in
the server.

> windows during  startup (which it should  never  do), but that problem

It does not behave like this on my machine.  I had to force fvwm
programmatically to enter the active placement code to bring up
the hang.  This can happen only if the PPosOverride boolean is
False when it decides whether to do WM placement or just take the
old position (placement.c):

  if (mode == PLACE_AGAIN)
  {
    use_wm_placement = True;
  }
  ... (some conditions ==> use_wm_placement = False)
  else if (PPosOverride)
  {
    use_wm_placement = False;
  }
  ...
  if (use_wm_placement)
  {
    ... the code doing active placement is in here
  }

But when you restart fvwm, the CaptureAllWindows() function is
called - but this sets PPosOverride to True before capturing the
windows.

> On the subject of the FvwmWindow pointers, do you think you might have

Not knowingly.  I didn't see any problem related to corrupt window
pointers in the logs, but it may have been an array bounds write
or some malloc/free problem.  I give it a 25% chance of being
fixed.

Bye

Dominik ^_^  ^_^