Subject: Re: pointer tracking patch for fvwm/* and libs/*

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

[sorry, I didn't copy fvwm-workers on the last mail...]

In message <[email-masked]>, 
"Paul D.
 Smith" writes:
>Personally, I think that there are already many tools out there which
>perform these functions at least as well as we could, and most of them
>are probably better (more comprehensive coverage, better error checking,
>more sophisticated error reporting and logging facilities, etc.)
>
>There are heap checkers out there that replace many standard C functions
>in efforts to check heap usage more closely (dbmalloc, for instance).
>
>We've already discussed dmalloc.  There is also the bounds checking
>version of GCC, and other heap tools that do things like allocate memory
>using mmap(), so that free calls (that use munmap) make the memory
>completely unavailable and the first attempt to use that memory results
>in a core dump.
>
>Not to mention that some of us have access to very sophisticated,
>proprietary tools for handling this: Dan and I both have access to
>Purify (well, I will again shortly: right now I'm trying to get renewed
>licenses) and it looks like we may soon get one or more donated licenses
>of Insure++.  Obviously this only helps if one of us can reproduce the
>problem, I realize that.
>
>Maybe I'm missing something but I just don't see a lot of value in
>including code that duplicates all of this already-available stuff with
>FVWM itself... it's just one more thing we have to maintain and enhance
>ourselves, rather than relying on others who do that sort of thing more
>full-time.
>

Well, if anyone could tell me how these tools can help me solve the 
crashes I have right now, I'd be more than happy to avoid doing extra 
work.  I'll try .25 with dmalloc compiled in... any hints on how to 
best get it to provide me with useful output considering the specific 
problem I have?

Nils.

--
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: "Paul D. Smith" <[email-masked]>
Date: 15 Dec 2000 11:19:42 -0500

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

  nl> Well, if anyone could tell me how these tools can help me solve
  nl> the crashes I have right now, I'd be more than happy to avoid
  nl> doing extra work.  I'll try .25 with dmalloc compiled in... any
  nl> hints on how to best get it to provide me with useful output
  nl> considering the specific problem I have?

The manual for dmalloc is at http://dmalloc.com/docs/dmalloc.html.

Make sure that the -DDMALLOC_FUNC_CHECK is defined on every compile line
for every .o (at least in fvwm itself; you don't need to compile the
modules with it if they're not having problems).  Make sure
HAVE_DMALLOC_H is defined in config.h.  Make sure you've rebuilt fvwm
and all its .o's since those settings changed, and make sure you're
running the rebuilt fvwm2 binary.

If your problem is overrunning the end of a buffer, you want to enable
the check-heap option (see the docs or man page for the dmalloc program
for an easy way to set up your environment for these options).  You
probably also want check-funcs.

If your problem is free memory being accessed, try the options
check-blank, check-funcs, free-blank, and alloc-blank.  If you need more
help you might try never-reuse, but this will really make FVWM use tons
of memory; if the bug takes a long time to show up you might run out of
memory first.

Also, you shouldn't run FVWM under a debugger.  Since FVWM is your
window manager, if it dies and the debugger traps it, your entire window
system will hang and you won't be able to give focus to the window
containing the debugger.  You _might_ be able to switch consoles, if
you're using Linux/XFree86; then you could start the debugger in the
console and attach to FVWM and when it crashes, switch back.  I'm not
sure about that.

The best way to run FVWM under a debugger is to run it within an Xnest
server; unfortunately that's more difficult if the bug isn't easily
reproducible.

HTH.

-- 
-------------------------------------------------------------------------------
 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: Dominik Vogt <[email-masked]>
Date: Sun, 17 Dec 2000 07:44:25 +0100

> console and attach to FVWM and when it crashes, switch back.  I'm not

This can be done, but most of the time either fvwm has already
died or is hogging all CPU so that you can't switch to the console
anymore.

> server; unfortunately that's more difficult if the bug isn't easily

If possible, use a multi head setup for debugging.  If not and you
can use XFree86, start another X server on a different display and
switch with Alt-Fn.  However, X will freeze if the pointer is
grabbed when you switch.  Xnest does not work well most of the
time.

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]