Subject: Re: HandleModuleInput ERROR command is too big

From: Olivier Chapuis <[email-masked]>
Date: Wed, 01 Dec 1999 10:22:08 +0100

Giuseppe Della Ricca wrote:
> 
> Hi !
> 
> I'm using 2.3.10 on Linux RH 6.1 2.2.12-20 and Digital OSF1 V4.0 878
> alpha, with basically the same .fvwm2rc (only the paths to pixmaps and
> executables are different). Everything is fine on Linux, while on Alpha
> fvwm2 hangs when I start one of the modules. The typical messages
> (obtained after killing fvwm2) are:
> 
> WinList:
> 
> [FVWM][HandleModuleInput]: <<ERROR>> Module(0) command is too big
> (536863056), limit is 1000
> [FVWM][HandleModuleInput]: <<ERROR>> Fail to read command (Module: 0,
> read: 165, size: 1000)
> 
> Banner:
> 
> [FVWM][HandleModuleInput]: <<ERROR>> Module(0) command is too big
> (536863056), limit is 1000
> [FVWM][HandleModuleInput]: <<ERROR>> Fail to read command (Module: 0,
> read: 0, size: 1000)
> 
> Pager:
> 
> [FVWM][HandleModuleInput]: <<ERROR>> Module 0, Size Problem: cont is zero
> 
> Can this be related to the 64-bit stuff on Alpha ? Is anybody testing
> fvwm2 on this platform ? The same .fvwm2rc works fine with 2.2.3.
> 
> I've tried with both gcc (egcs-2.91.60) and with cc (DEC C V5.6-071).
> Same problem.
> 
> Any idea ?

Hello,

May be it is a story of memory corruption. I recall the story:
Nadim Saeed and me noted random crashes of the TaskBar and of WinList.
The errors were of the kind mentioned above and came from the SendFvwmPipe
of these modules. So, I took the SendFvwmPipe of IconMan put it in the 
library (libs/Module.c) and do so that any module that used the
SendFvwmPipe function (bad function any way ???) use the one of the
library. This modification fixed the random crashes of the TaskBar and of 
WinList. Now, we 've got new crashes ...

I am not a specialist of memory allocation but my intuition is that
we have such a problem in libs/Module.c (SendFvwmPipe).
I suggest that some one that know really something about memory
allocation take a look to SendFvwmPipe (moreover, I am at work and
do not have cvs access at the present time). 
It seems to me that the memory allocation logic in SendText is better than
in SendFvwmPipe.

Olivier
--
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: Brad Giaccio <[email-masked]>
Date: Wed, 1 Dec 1999 08:44:04 -0500

> It seems to me that the memory allocation logic in SendText is better than

I took a glance at both SendFvwmPipe an SendText and both seem to be
handling memory correctlly. Was there something specific you saw or just
stepping through your problem and this was the next step?

Brad
 
-- 
--- There are two kinds of knowledge, you either know the answer or
			you know where to find it
		      -Kane, Johnson, and anonymous
--
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: Olivier Chapuis <[email-masked]>
Date: Wed, 01 Dec 1999 15:51:43 +0100

> stepping through your problem and this was the next step?

I am ok with you: SendFvwmPipe seems to handle memory correctly.
But I think that the errors that Giuseppe Della Ricca have come
from SendFvwmPipe and when I see a message like:

I imagine that a crazy thing has been sent to fvwm2, so ...

But I've almost no experience in C programming, so I ask someone
to do something by giving MHO. Moreover, it seems that this problem
is machine specific ...

My idea is to do something more safe than:

  const char *hold = message;
  const char *temp;

by allocating memory to these pointers even if in *theory*
this not useful ...
But, I do not want to do things that I do not understand.

Olivier

---

From: Brad Giaccio <[email-masked]>
Date: Wed, 1 Dec 1999 10:15:58 -0500

> to do something by giving MHO. Moreover, it seems that this problem

Well since Giuseppe is the only one who has seen the problem thus far, I
would suggest he put an fprintf in SendText so he can see what message
is cossing the error.  Looking again at the error string it looks more
like 536863056 would be a window id, not a strlen, and I'm not sure how
that would have happened.

Brad

---

From: [email-masked] (Paul D. Smith)
Date: 01 Dec 1999 10:50:37 -0500

How large (how many bits) is an unsigned long on Alpha?  Is it 32 or 64
bits?

I looked for, but can't find, a message I sent almost a year ago; it
_could_ be causing the problem if the Alpha compiler has a 64-bit long
but 32-bit int.  Maybe.

The problem is that our Send functions are now variadic (like
SendPacket()), and the variable arguments are expected to be of type
unsigned long.  But sometimes the arguments we pass to these functions
are just "int"; since we are using a variadic prototype there's no
automatic integer promotion.  In a correct ANSI C program we have to
cast all these arguments, but we're not.

This might be completely off the wall; it just popped into my head
again.

-- 
-------------------------------------------------------------------------------
 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.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: Bob Woodside <[email-masked]>
Date: Wed, 01 Dec 1999 10:59:14 -0500

> that would have happened.

	I was going to suggest that, since it seems to be machine dependent,
you should look at the discrepancy between HandleModuleInput, which uses
plain old int variables, and SendText, which plugs the window id and the
length into the data stream as unsigned long ints. You're right, that
does look like a window id!

Cheers,
Bob

---

From: Olivier Chapuis <[email-masked]>
Date: Wed, 01 Dec 1999 18:47:33 +0100

> How large (how many bits) is an unsigned long on Alpha?  Is it 32 or 64

I have a Digital OSF1  V4.0 1091 alpha at work. Here the machine limit:

#define CHAR_BIT        8               /* number of bits in a char */

#define SCHAR_MIN       (-128)          /* min value for a signed char */
#define SCHAR_MAX        127            /* max value for a signed char */

#define CHAR_MAX         127            /* max value for a char */
#define CHAR_MIN        (-128)          /* min value for a char */

#define SHRT_MAX         32767          /* max value for a short */
#define SHRT_MIN        (-32768)        /* min value for a short */
                                        /* sneaky way so result type is int */

#define LONG_MAX         9223372036854775807 /* max value for a long */
#define LONG_MIN        (-LONG_MAX-1)   /* min value for a long -- define in */
                                        /* sneaky way so restul type is long */

#define UCHAR_MAX       255U          /* max value for an unsigned char */
#define USHRT_MAX       65535U        /* max value for an unsigned short */
#define UINT_MAX        4294967295U   /* max value for an unsigned int */
#define ULONG_MAX       18446744073709551615U   /* max value for an unsigned lon
g */

/* Must be at least two, for internationalization (NLS/KJI) */
#define MB_LEN_MAX      4               /* multibyte characters */

Maybe some of these limits depend on the kernel compile time
options.
I have just tried 2.3.10 (first time I test an alpha version at work, I don't
want to have problem with my sysadm, neither work to much on fvwm2 here).
The point is that no module work (I use fvwm2rc-sample). Either nothing
happen or the process is on but no module on the screen and fvwm2 is 
locked, I have to kill the module process to unlock fvwm2 ...
No error message, no core file ...

> cast all these arguments, but we're not.

It seems that we have to do that ...

Olivier

---

From: [email-masked]
Date: Wed, 1 Dec 1999 13:01:51 -0500 (EST)

>> How large (how many bits) is an unsigned long on Alpha?  Is it 32 or 64

Using Tru64 Unix and Compaq C (which comes with it), unsigned longs are 64
bits.  As far as I know, this has always been the case.  This is also the case
with gcc 2.95 (I just checked).
 
-- 
Larry Gensch					   [email-masked]
Compaq Computer Corporation                        As usual, the standard
110 Spit Brook Road ZKO3-2/W17                     disclaimers apply, etc.
Nashua, NH 03062                                   Yada yada yada

---

From: [email-masked] (Paul D. Smith)
Date: 01 Dec 1999 13:27:39 -0500

>> cast all these arguments, but we're not.

  oc> It seems that we have to do that ...

Hmm.  We might have a bigger/different problem.

I _think_ most of the packet encode/decode stuff is based on the
assumption that we are sending 32-bit quantities of data.  If a long is
64 bits, we may have larger problems than just throwing a few casts in
there...

It's been more than a year since I looked at that but we may need more
fundamental changes--either allow the elements of the package to be as
large as a long, regardless of how large that is, or use a typedef like
eint32 or something to mean "an int exactly 32 bits" and have configure
or somesuch work out what the right type for that would be (the new ANSI
C spec has some kind of int_types.h standard header which is supposed to
define lots of stuff like this, but I'm not that familiar with it yet).

---

From: Dominik Vogt <[email-masked]>
Date: Thu, 2 Dec 1999 09:50:28 +0100

> that would have happened.

Hm, I don't know how window id's look on other X servers, but
with XFree I always get something like

  0x0?000???

but 536863056 in hex is 0x1FFFE150 which doesn't fit at all into this
scheme.  Of course this might depend on the X server.

Bye

Dominik ^_^

-- 
Dominik Vogt, Agilent Technologies, Dept. BVS
Herrenberger Str.130, 71034 Boeblingen, Germany
phone: 07031/464-4596, fax: 07031/464-3883, [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: Brad Giaccio <[email-masked]>
Date: Thu, 2 Dec 1999 08:54:42 -0500

> scheme.  Of course this might depend on the X server.

Well if you think about it just means you don't have enough windows
open.  A quick look through xlswins says that I have window ids in
the range of 0x0* to 0xe*.  Not to say that that particualr value is
a window id, I think I'm leaning more towards the 32 bit vs 64 bit
problem.

Brad