Subject: purify tests on solaris with vanilla .25

From: "Nils Lohner" <[email-masked]>
Date: Sat, 16 Dec 2000 20:33:03 +0100

Here is the log of the purify tests under solaris.  I'm not sure if the 
tests ran correctly, as there are a lot of fvwmrc errors in the log.  
Could someone fix the 'normal' errors in the rc file, and comment on 
whether what I'm seeing is usual or not?

When there are no more errors from the purify.fvwm2rc I'll let it run 
with dmalloc enabled.

 - execute the shell script purify.install to copy some files needed by
   the config file to /tmp

No problem.

 - edit purify.fvwm2rc so that the correct ModulePath is included in the
   last ModulePath statement (all in one block)

 + I ModulePath $HOME/bin/fvwm2:/usr/local/libexec/fvwm/2.3.22:/opt/publ
ic/src/f
vwm/2.3.22:/sup/libexec/fvwm/2.3.25

 - copy purify.fvwm2rc over your .fvwm2rc (or execute it any way you 
like)

~ > tail -1 .xinitrc
exec /sup/bin/fvwm2 -f purify/purify.fvwm2rc

 - (re)start fvwm

~ > openwin >& errors.purifyrc

 - wait until the six windows have been created and the cursor warps 
near the
   lower right edge of the screen; the windows redraw and the setup 
halts;
   now press mouse button 2 to proceed.

Here's where things start to go wrong IMO.  I get the menu asking which 
tests to run immediately, and select 'run all tests'.  I then get asked 
to press escape quite a few times, and the tests seem to stop a lot.  
There, hitting button 1 or escape lets it restart.

Also, the window title bar coloring looks terrible... looks like a 
color sweep, but there are black vertical lines in it making it look 
very broken.  Is this normal?  I would assume not.

 - whenever fvwm expects user input, press mouse button 1

When is this, only when there is the crosshair cursor?

 - the script will ternimate itself
                      ^^^
typo... and I'm not sure if this is considered 'normal' termination or 
not.  I'd assume 'not' ...

[FVWM][DispatchEvent]: <<DEBUG>> Leaving Routine
### Sat Dec 16 20:20:48 MET 2000: Test ModulePath ###
xterm:  fatal IO error 32 (Broken pipe) or KillClient on X server 
":0.0"^M
### Sat Dec 16 20:20:48 MET 2000: Test Cleanup ###
xterm:  fatal IO error 32 (Broken pipe) or KillClient on X server 
":0.0"^M
xterm:  fatal IO error 32 (Broken pipe) or KillClient on X server 
":0.0"^M
xterm:  fatal IO error 32 (Broken pipe) or KillClient on X server 
":0.0"^M
xterm:  fatal IO error 32 (Broken pipe) or KillClient on X server 
":0.0"^M
xterm:  fatal IO error 32 (Broken pipe) or KillClient on X server 
":0.0"^M
[FVWM][Echo]:  ------------ ok ------------
[FVWM][CloseICCCM2]: <<DEBUG>> good luck, new wm
^M
waiting for X server to shut down ..........
^M
/usr/openwin/bin/xinit:  X server slow to shut down, sending KILL 
signal.^M

---

From: Dan Espen <[email-masked]>
Date: Sat, 16 Dec 2000 15:19:48 -0500

> whether what I'm seeing is usual or not?

Errors are a part of the test.
The tests are attempting to exercise most of the logic paths
in fvwm so testing the error reporting is necessary.
In some places there are echos indicating that the following errors are
normal, but that work isn't complete yet.

>    now press mouse button 2 to proceed.

This seems wrong, the menu should appear before the 6 windows.

> very broken.  Is this normal?  I would assume not.

All of this is normal.  The appearance of the windows isn't important,
what is important is that as many features as possible are tested.

> When is this, only when there is the crosshair cursor?

The need for user input to drive the tests is unfortunate
especially when the input can affect the outcome of the tests.
Toward the end of the tests, there are commands issued without any
target at all, depending on what you click on, the result will be
different.  I've been working on the tests, trying to first make sure
everything in the man pages is tested, and also to try to make the
flow of the tests more predictable.

> not.  I'd assume 'not' ...

The last function in the test ends with a "quit":

AddTest "Test Cleanup" Cleanup-Func
AddToFunc Cleanup-Func
 + I All (window1) destroy
 + I All (window2) destroy
 + I All (window3) destroy
 + I All (window4) destroy
 + I All (window5) destroy
 + I All (window6) destroy
 + I beep
 + I Echo ------------ ok ------------
 + I quit poesfj apäuofw ük-lnlöiooüp. ..a,sjdms.,x-,

> xterm:  fatal IO error 32 (Broken pipe) or KillClient on X server 

I guess this is a normal message generated by X when fvwm does a
"destroy".

> [FVWM][Echo]:  ------------ ok ------------

Since we see the OK message, it looks like the test has run to
completion.

> /usr/openwin/bin/xinit:  X server slow to shut down, sending KILL 

These tests need a lot of work.  I believe that for the 2.2 release,
the tests were fairly up to date.  Since then lots of commands and
features got added to fvwm but the tests weren't updated.

I've been trying to update the tests, but at the rate I'm going,
its going to be months before I'm done.

Its interesting that these tests ran to completion for you, I was
half expecting that they would cause a core dump.

I haven't looked at the log yet.

--
Dan Espen
444 Hoes Lane  Room RRC 1C-214           E-mail: [email-masked]
Piscataway, NJ 08854                     Phone: (732) 699-5570
--
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: Dan Espen <[email-masked]>
Date: Sat, 16 Dec 2000 15:28:18 -0500

> When there are no more errors from the purify.fvwm2rc I'll let it run 

The log looks completely "normal".

---

From: Nils Lohner <[email-masked]>
Date: Sat, 16 Dec 2000 21:40:11 +0100

In message <[email-masked]>, Dan Espen 
>normal, but that work isn't complete yet.

OK.

>This seems wrong, the menu should appear before the 6 windows.

It does, this is from the README in the purify dir.  Perhaps it should 
clarify the points I brought up?  I assume anyone running these tests 
for the first time will have the questions...

>flow of the tests more predictable.

Hmmm... then it would be nice to know exactly when to click.  I just 
clicked or hit escape (since that's what the first few menus asked 
for...) whenever it seemed to not do anything...

>> xterm:  fatal IO error 32 (Broken pipe) or KillClient on X server 
...
>I guess this is a normal message generated by X when fvwm does a

Ah, yes.

>half expecting that they would cause a core dump.

Not really, I suspect that something wrt openlook specifics (or old 
xview stuff) throw off FVWM.  When not running with those windows, its 
as stable as any other MW.  The WMs that don't crash, btw, are OLWM and 
CDE.

Crashes have been seen on (or after) opening lots of windows like this:
cmdtool -Wp 468 384 -Ws 664 456 -WP 959 448 -Wi

...except that they weren't command tools but windows specific to the applications we run here at work.  When I get back from vacation (beginning of january) I plan to write a few scripts to just open, move, shade, (un)iconify and close those windows and see if that'll produce the crash within minutes (i.e. after a few hundres of those operations- I assume that's about what it takes to crash the WM considering normal work over the course of a few hours).

If that gives me the crash, I'll run it with dmalloc and see what it spits out.  Can you suggest the appropriate parts of the purifyrc to cut out to test those functions nicely with the windows I plan to open?  I guess I can reference them by title?

>The log looks completely "normal".
  Fine, then I'll repeat the tests a few times to see if I get the crash, but I'm not counting on it.

Thanks for your help...

Merry Xmas, I'm off on vacation for ~two weeks.
Nils.

---

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

> for the first time will have the questions...

I've been changing the tests but not updating the README.
I'll get to it.

> for...) whenever it seemed to not do anything...

As I go over the tests I'm trying to deal with this.

> cmdtool -Wp 468 384 -Ws 664 456 -WP 959 448 -Wi

After we talked I tried cmdtool under Purify with no joy.
I didn't use the args through, I'll try again when I get a chance.

> If that gives me the crash, I'll run it with dmalloc and see what it spits ou
> t.  Can you suggest the appropriate parts of the purifyrc to cut out to test 
> those functions nicely with the windows I plan to open?  I guess I can refere
> nce them by title?

Since we don't know what causes the problem, thats difficult.
I think up until the line that reads:

# Ending ManPage Order

is a good place to start.
You can use your application instead of xterm in CreateWindows if you
can get your application to name the windows as needed.

> Merry Xmas, I'm off on vacation for ~two weeks.

Have a good time.

---

From: Nils Lohner <[email-masked]>
Date: Sat, 16 Dec 2000 22:12:13 +0100

In message <[email-masked]>, Dan Espen 
>I didn't use the args through, I'll try again when I get a chance.

It might not be the options, it might be some of the application 
windows that set/request strange OLWM-related things from the WM... I'd 
assume cmdtool alone will not cause the crash.

>can get your application to name the windows as needed.

I doubt I can set the titles... the apps are probably too stubborn, but 
I can predict the titles.  I assume that's good enough?

>> Merry Xmas, I'm off on vacation for ~two weeks.

Thanks!

Nils.

---

From: Dominik Vogt <[email-masked]>
Date: Sun, 17 Dec 2000 16:05:00 +0100

> > whether what I'm seeing is usual or not?

This test is meant to be run in conjunction with purify, insure++,
dmalloc or whatever.  The output is generates is of little value.
Originally it was written to test command parsing.

> flow of the tests more predictable.

Dan, this is exactly what I wrote the FakeClick command for. To
fake a mouse click in a window programmatically, warp the pointer
into the window and issue

  FakeClick depth 2 press 1 wait 250 release 1

or short

  FakeClick d 2 p 1 w 250 r 1

This will simulate a click with button 1 in the parent window
(depth 2) with a delay of 250 milliseconds between the press and
the release.  To generate clicks on the root window use depth 0,
for the frame depth 1 and for the client window only depth 3.  It
is explained in the man page also.  However, FakeClick will not
work in menus, for resize or move etc.

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]