Subject: first dmalloc failures...

From: "Nils Lohner" <[email-masked]>
Date: Fri, 15 Dec 2000 15:55:43 +0100

Here is the first error I got when running with .25 and dmalloc.

Not all memory allocation use the safe*alloc() calls... should they?  
IMO yes, at least in the core fvwm/* and libs/*.  Would patches be 
accepted to fix this?  I'll try to track where this zero-allocation is 
coming from...

I'm also not sure about the use of alloca() in the program... its used 
in a few places, but the solaris manpage warns about it.  Could it be 
rewritten in malloc and free's?

Sorry to keep bugging you guys about this, but this problem is 
frustrating and I can't seem to advance... whatever I do to try and 
figure out what it is brings five other obstacles with it.

Any help in whatever form is appreciated...

Nils.

part 1:

~ > cat errors.test2 

[FVWM][main]: <<DEBUG>> Entered, about to parse args
[FVWM][main]: <<DEBUG>> Done parsing args
[FVWM][main]: <<DEBUG>> Installing signal handlers
debug-malloc library: dumping program, fatal error
   Error: invalid allocation size (err 40)

~ > cat logfile-test 
976891066: 30: Dmalloc version '4.8.1' from 'http://dmalloc.com/'
976891066: 30: flags = 0x4e40503, logfile 'logfile-test2'
976891066: 30: interval = 100, addr = 0, seen # = 0
976891066: 30: starting time = 976891066
976891066: 30: malloc: bad zero byte allocation request: from 
'ra=0xff2baefc'
976891066: 30: ERROR: _chunk_malloc: invalid allocation size (err 40)

part 2:

from man alloca:
...
     The alloca() function allocates size  bytes of space in  the
     stack  frame  of  the  caller,  and returns a pointer to the
     allocated block. This temporary space is automatically freed
     when  the  caller  returns. If the allocated block is beyond
     the current stack limit, the  resulting  behavior  is  unde-
     fined.
...
     The alloca() function is machine-, compiler-,  and  most  of
     all, system-dependent. Its use is strongly discouraged.

And from libs/alloca.c:
   As a special case, alloca(0) reclaims storage without
   allocating any.  It is a good idea to use alloca(0) in
   your main control loop, etc. to force garbage collection.  */

And from fvwm/events.c:
#ifdef C_ALLOCA
  /* If we're using the C version of alloca, see if anything needs to be
   * freed up.
   */
  alloca(0);
#endif

--
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: Nils Lohner <[email-masked]>
Date: Fri, 15 Dec 2000 16:34:38 +0100

Here's the followup, with a little more info and a stack trace.  According to the stack trace, seems the error is caused by openwin system routines (_X11TransGetPeerAddr () from /usr/openwin/lib/libX11.so.4)

Help?  I'mfresh  out of clues.

Nils.

~ > dmalloc -l log-debug -i 100 medium
~ > cd /sup/build/fvwmdevel/fvwm-2.3.25/fvwm/
/sup/build/fvwmdevel/fvwm-2.3.25/fvwm > gdb ./fvwm2
GNU gdb 4.18
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "sparc-sun-solaris2.7"...
(gdb) run
Starting program: /mnt/build/fvwmdevel/fvwm-2.3.25/fvwm/./fvwm2 
[FVWM][main]: <<DEBUG>> Entered, about to parse args
[FVWM][main]: <<DEBUG>> Done parsing args
[FVWM][main]: <<DEBUG>> Installing signal handlers
debug-malloc library: dumping program, fatal error
   Error: invalid allocation size (err 40)

Program received signal SIGABRT, Aborted.
0xff0969c0 in _libc_kill () from /usr/lib/libc.so.1
(gdb) where
#0  0xff0969c0 in _libc_kill () from /usr/lib/libc.so.1
#1  0xff039340 in abort () from /usr/lib/libc.so.1
#2  0xff0effdc in _dmalloc_die (silent_b=-4265360) at error.c:391
#3  0xff0f006c in dmalloc_error (func=0xff0f2360 "_chunk_malloc")
    at error.c:427
#4  0xff0ee08c in _chunk_malloc (file=0xff2baefc "@", line=0, size=0, 
    func_id=10, alignment=0) at chunk.c:2689
#5  0xff0f0688 in _loc_malloc (file=0xff2baefc "@", line=0, size=0, 
    func_id=10, alignment=0) at malloc.c:646
#6  0xff0f0908 in malloc (size=0) at malloc.c:778
#7  0xff2baf04 in _X11TransGetPeerAddr () from /usr/openwin/lib/libX11.so.4
#8  0xff2a3a3c in _X11TransConnectDisplay () from /usr/openwin/lib/libX11.so.4
#9  0xff281450 in XOpenDisplay () from /usr/openwin/lib/libX11.so.4
#10 0x51870 in main (argc=1, argv=0xffbef864) at fvwm.c:371
(gdb) quit
The program is running.  Exit anyway? (y or n) y
/sup/build/fvwmdevel/fvwm-2.3.25/fvwm > /sup/bin/fvwm2 >& ~/fvlog &
[1] 4849
/sup/build/fvwmdevel/fvwm-2.3.25/fvwm > 
/sup/build/fvwmdevel/fvwm-2.3.25/fvwm > cd 
~ > cat errors-medium 

waiting for X server to shut down ..........

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

~ > cat logfile-medium 
976893327: 1: Dmalloc version '4.8.1' from 'http://dmalloc.com/'
976893327: 1: flags = 0x4f4154b, logfile 'logfile-low'
976893327: 1: interval = 100, addr = 0, seen # = 0
976893327: 1: starting time = 976893327
976893327: 1: *** alloc: at 'fvwm.c:2200' for 56 bytes, got '0x80008|s1'
976893327: 2: *** alloc: at 'ra=0x5e2ec' for 256 bytes, got '0x82008|s1'
976893327: 3: *** alloc: at 'fvwm.c:2231' for 52 bytes, got '0x84008|s1'
976893327: 4: *** alloc: at 'ra=0xff04c4e0' for 208 bytes, got '0x86008|s1'
976893327: 5: *** alloc: at 'fvwm.c:234' for 16 bytes, got '0x8a008|s1'
976893327: 6: *** alloc: at 'fvwm.c:237' for 29 bytes, got '0x84048|s1'
976893327: 7: reading info about pointer '0x86008'
976893327: 7: *** alloc: at 'ra=0xff04c4b0' for 212 bytes, got '0x86108|s1'
976893327: 7: *** free: at 'ra=0xff04c4b0' pnt '0x86008|s2': size 208, alloced at 'ra=0xff04c4e0'
976893327: 7: *** realloc: at 'ra=0xff04c4b0' from '0x86008' (208 bytes) file 'ra=0xff04c4e0' to '0x86108' (212 bytes)
976893327: 8: *** calloc: at 'ra=0xff281404' for 1344 bytes, got '0x8c008|s1'
976893327: 9: *** alloc: at 'ra=0xff2a34bc' for 2 bytes, got '0x8a028|s1'
976893327: 10: *** alloc: at 'ra=0xff2a34bc' for 5 bytes, got '0x8a048|s1'
976893327: 11: *** free: at 'ra=0xff2a38dc' pnt '0x8a048|s2': size 5, alloced at 'ra=0xff2a34bc'
976893327: 12: *** alloc: at 'ra=0xff2a34bc' for 5 bytes, got '0x8a068|s1'
976893327: 13: *** alloc: at 'ra=0xff2a399c' for 8 bytes, got '0x8a088|s1'
976893327: 14: *** alloc: at 'ra=0xff2ba8f4' for 8 bytes, got '0x8a0a8|s1'
976893327: 15: *** alloc: at 'ra=0xff2baa18' for 5 bytes, got '0x8a0c8|s1'
976893327: 16: *** alloc: at 'ra=0xff2baa5c' for 7 bytes, got '0x8a0e8|s1'
976893327: 17: *** alloc: at 'ra=0xff2baaa8' for 2 bytes, got '0x8a108|s1'
976893327: 18: *** free: at 'ra=0xff2baaf4' pnt '0x8a0a8|s2': size 8, alloced at 'ra=0xff2ba8f4'
976893327: 19: *** calloc: at 'ra=0xff2b9e04' for 44 bytes, got '0x84088|s1'
976893327: 20: *** free: at 'ra=0xff2bac08' pnt '0x8a0c8|s2': size 5, alloced at 'ra=0xff2baa18'
976893327: 21: *** free: at 'ra=0xff2bac10' pnt '0x8a0e8|s2': size 7, alloced at 'ra=0xff2baa5c'
976893327: 22: *** alloc: at 'ra=0xff2ba8f4' for 8 bytes, got '0x8a128|s1'
976893327: 23: *** alloc: at 'ra=0xff2baa18' for 5 bytes, got '0x8a148|s1'
976893327: 24: *** alloc: at 'ra=0xff2baa5c' for 7 bytes, got '0x8a168|s1'
976893327: 25: *** alloc: at 'ra=0xff2baaa8' for 2 bytes, got '0x8a188|s1'
976893327: 26: *** free: at 'ra=0xff2baaf4' pnt '0x8a128|s2': size 8, alloced at 'ra=0xff2ba8f4'
976893327: 27: *** free: at 'ra=0xff2bad14' pnt '0x8a148|s2': size 5, alloced at 'ra=0xff2baa18'
976893327: 28: *** free: at 'ra=0xff2bad2c' pnt '0x8a168|s2': size 7, alloced at 'ra=0xff2baa5c'
976893327: 29: *** free: at 'ra=0xff2bad44' pnt '0x8a188|s2': size 2, alloced at 'ra=0xff2baaa8'
976893327: 30: malloc: bad zero byte allocation request: from 'ra=0xff2baefc'
976893327: 30: ERROR: _chunk_malloc: invalid allocation size (err 40)

---

From: [email-masked]
Date: Fri, 15 Dec 2000 10:55:27 -0500 (EST)

> Help?  I'mfresh  out of clues.

The error appears to be a call to malloc with a size of zero.  I
believe that this is ALLOWED in C89 (not sure about C99).

Although it is allowed, it is also not a very good practice.  I don't
know why dmalloc fails with this, though.

By the way, Tru64 Unix has an ATOM-based tool called "Third Degree"
(aka "third") that works like Purify/Insure (doesn't require changes
to the sources) and which instruments an executable image reporting
memory leaks, etc.

If somebody can point me to the .fvwm2rc that is used for the Purify
tests, I can pass it through this tool and send the reports to this
list. (Third comes standard with Tru64, so there's no licensing issues
involved.)

-- 
Larry Gensch                                          [email-masked]

              Working for COMPAQ since the turn of the century

---

From: Nils Lohner <[email-masked]>
Date: Fri, 15 Dec 2000 17:02:42 +0100

In message <[email-masked]>, 
larry.gensch@compaq.
>list. (Third comes standard with Tru64, so there's no licensing issues

Here you go...

Nils.

lftp ftp.fvwm.org:~/pub/fvwm/devel/sources/tests/purify> ls
drwxr-xr-x  --  /
drwxr-xr-x  --  /pub
drwxr-xr-x  --  /pub/fvwm
drwxr-xr-x  --  /pub/fvwm/devel
drwxr-xr-x  --  /pub/fvwm/devel/sources
drwxr-xr-x  --  /pub/fvwm/devel/sources/tests
drwxr-xr-x  --  /pub/fvwm/devel/sources/tests/purify
drwxr-xr-x   3 tibbs    staff         512 Dec 11 00:15 .
drwxr-xr-x   5 tibbs    staff         512 Oct 12 08:15 ..
drwxr-xr-x   2 tibbs    staff         512 Dec 11 00:15 CVS
-rw-r--r--   1 tibbs    staff        1723 Aug 14  1999 README
-rwxr-xr-x   1 tibbs    staff          86 Jan 16  1999 install.purify
-rw-r--r--   1 tibbs    staff       61096 Dec 11 00:15 purify.fvwm2rc
-rw-r--r--   1 tibbs    staff        2987 Jan 16  1999 purify.read
-rw-r--r--   1 tibbs    staff         581 Jan 16  1999 test1.xpm
-rw-r--r--   1 tibbs    staff         425 Jan 16  1999 test2.xpm
-rw-r--r--   1 tibbs    staff         647 Jan 16  1999 test3.xpm
lftp ftp.fvwm.org:~/pub/fvwm/devel/sources/tests/purify>

---

From: "Paul D. Smith" <[email-masked]>
Date: 15 Dec 2000 11:07:37 -0500

%% "Nils Lohner" <[email-masked]> writes:

  nl> Here is the first error I got when running with .25 and dmalloc.

  nl> Not all memory allocation use the safe*alloc() calls... should they?  

I think so.  There may be specific reasons not to, I suppose, but I
can't think of any offhand.

  nl> I'm also not sure about the use of alloca() in the program... its used 
  nl> in a few places, but the solaris manpage warns about it.  Could it be 
  nl> rewritten in malloc and free's?

alloca() is OK.

What C compiler are you using to build with?

  nl> ~ > cat errors.test2 

  nl> [FVWM][main]: <<DEBUG>> Entered, about to parse args
  nl> [FVWM][main]: <<DEBUG>> Done parsing args
  nl> [FVWM][main]: <<DEBUG>> Installing signal handlers
  nl> debug-malloc library: dumping program, fatal error
  nl>    Error: invalid allocation size (err 40)

  nl> ~ > cat logfile-test 
  nl> 976891066: 30: Dmalloc version '4.8.1' from 'http://dmalloc.com/'
  nl> 976891066: 30: flags = 0x4e40503, logfile 'logfile-test2'
  nl> 976891066: 30: interval = 100, addr = 0, seen # = 0
  nl> 976891066: 30: starting time = 976891066
  nl> 976891066: 30: malloc: bad zero byte allocation request: from 
  nl> 'ra=0xff2baefc'
  nl> 976891066: 30: ERROR: _chunk_malloc: invalid allocation size (err 40)

Strange.  Why are there no filenames and linenumbers here?

Anyway, you need to recompile your dmalloc after reconfiguring it to set
ALLOW_ALLOC_ZERO_SIZE to enabled.  Edit settings.dist and set it to 1,
then run ./config.status and rebuild the library.

  nl>      The alloca() function is machine-, compiler-,  and  most  of
  nl>      all, system-dependent. Its use is strongly discouraged.

This isn't so the way we use it.

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <[email-masked]>    HASMAT--HA Software Methods & Tools
 "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: Nils Lohner <[email-masked]>
Date: Fri, 15 Dec 2000 17:23:02 +0100

In message <[email-masked]>, "Paul D. 
Smith" wr
>can't think of any offhand.

Could someone with CVS access patch this then please?  It took me 5 
minutes to fix locally, there aren't many calls.

>What C compiler are you using to build with?

~ > gcc --version
2.95.2
~ > uname -a
SunOS topaze 5.7 Generic_106541-02 sun4u sparc SUNW,Ultra-5_10

>Strange.  Why are there no filenames and linenumbers here?

because it happens in system routines- see my second mail on the 
subject with the stack trace from gdb.

>then run ./config.status and rebuild the library.

Thanks, will do.

Nils.

---

From: "Paul D. Smith" <[email-masked]>
Date: 15 Dec 2000 15:35:59 -0500

%% Nils Lohner <[email-masked]> writes:

  nl> ~ > gcc --version
  nl> 2.95.2
  nl> ~ > uname -a
  nl> SunOS topaze 5.7 Generic_106541-02 sun4u sparc SUNW,Ultra-5_10

Alloca always works fine if you're using GCC; it's a builtin feature of
the GCC compiler and so is available in GCC regardless of platform.

It's also available on most other UNIX compilers, and if not FVWM comes
with its own implementation of alloca() which works perfectly well on
any traditional stack-based operating system.

---

From: Dominik Vogt <[email-masked]>
Date: Sun, 17 Dec 2000 08:01:30 +0100

> #9  0xff281450 in XOpenDisplay () from /usr/openwin/lib/libX11.so.4

I don't think we can do anything about a malloc problem in the
XOpenDisplay call.  This is clearly a problem in some system
library.

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: Michael Wolf <[email-masked]>
Date: Wed, 20 Dec 2000 15:31:27 +1100

> know why dmalloc fails with this, though.

Because it's not good practice.  The aim of dmalloc is to encourage *good*
practice with allocated memory.  

I suspect, however, that dmalloc can be configured to allow malloc(0), but I
can't find the right #define on short notice.

mike

---

From: "Paul D. Smith" <[email-masked]>
Date: 20 Dec 2000 11:10:15 -0500

I sent mail about this to the list a few days ago containing the proper
#define; I can't recall it offhand but the archives will have it.

I think defaulting to not allowing malloc(0) is a mistake.  That is
certainly allowed and valid by the C standard, and it in _no_ way is it
poor practice... except perhaps that it won't work well on very old
systems which don't support the ISO C standard runtime library.  Given
that the standard is 11 years old, systems like that are surely
difficult to find.

At the _very_ least it should be configurable more easily than
recompiling the entire dmalloc library, which is what's required now.