# $Id: OPENBUGS,v 1.16 1998/06/17 09:03:25 zeller Exp $ -*- Text -*-
# The list of reported DDD bugs.

Note: For problems occurring when *building* DDD, see the file `PROBLEMS'.
      For known bugs that could be reproduced, see the file `BUGS'.

This is a list of reported DDD bugs which could not yet be reproduced.
Feel free to investigate into one of these problems or send in more
detail.

700 mayer@paradigml.com (Ron Mayer) says:

    In a number of structures I would attempt to "Modify [the]
    dependent display expression" to display in hex using expressions
    like "/x g->head", instead of the default "(g)->head".

    Occasionally this would make ddd hang, and lock up the X-server
    completely so that I would have to rlogin from another terminal
    to kill the program.  The bus-error was not reproducable, and
    unfortunatelly I had core files disabled when it happened.

    These structures did happen to be in a mmap()'d region of shared
    memory, but since I didn't see the problems when I didn't use the
    "/x" modifier I suspect this isn't the problem.

    PS: What is the prefered way (if any) of making the hex output 
        the default in the display graph?  If I "set output-radix 16" 
        in the gdb window ddd seems to lock up very often.
    [I could not reproduce this bug.  Can anyone clarify this?  -AZ]

701 Bob Vickers <bobv@dcs.rhbnc.ac.uk> says that DDD 2.0
    (alpha-dec-osf3.2) sometimes fails to start.  Often it works
    fine. But sometimes, especially if you haven't run it for a while
    (e.g. first thing in the morning) the command window comes up but
    there is no sign of the source window. There are sometimes error
    messages, and these vary slightly.

    The parent Unix window sometimes contains tty error messages, e.g.

    platon$ make check
    ==> Making check in ./ddd...
    make[1]: Entering directory `/nobackup/work/bobv/ddd-2.0/ddd'
    XUSERFILESEARCHPATH=. XAPPLRESDIR=. ./ddd cxxtest
    X Toolkit Warning: Cannot convert string 
    "-*-Menu-Medium-R-Normal--*-120-*-*-P-*-ISO8859-1" to type FontStruct
    (gdb) cannot set terminal foreground process group: I/O error
    (gdb) cannot get slave terminal settings: I/O error

    [We cannot fix this, as we neither have an OSF box nor
     appropriate OSF documentation at our disposition.  The DDD
     distribution comes with a demo program `ttytest' which is useful
     for debugging the TTY interface in `TTYAgent.C'  -AZ]

702 Jonathan Edwards <edwards@intranet.com> says that in AIX DBX,
    the local variable display does not display function arguments.
    [This is probably due to using AIX xlC instead of GCC.  -AZ]

703 Jonathan Edwards <edwards@intranet.com> says:
    A status display only shows once.  After stepping the program it
    collapses into just the title.  Doing a refresh command restores
    the display.
    [This is due to using AIX xlC instead of GCC.  -AZ]

704 Jonathan Edwards <edwards@intranet.com> says: If I interrupt my
    program while it is running, my data displays are not updated,
    and instead I get the info in the debugger console.

705 Matthias Kurz <mk@baerlap.north.de> says:
    - Often the first graph display is not completely inside the
      window; after selecting 'layout graph' things are right

706 Harry Mangalam <mangalam@uci.edu> reports: As soon as I click on
    a variable to try to highlight a structure name, DDD 2.1 goes
    into an unresponsive state for several seconds (seems like up to
    a minute on a 486) in which the ddd process hogs the cpu.  It
    then returns to a usable state until the next time I try to
    highlight a variable name.  It seems that if I click on a simple
    variable name, it responds appopriately, but if I try to
    drag-hilite the name, ddd goes berserk with the cpu.

707 Roy Dragseth <royd@math.uit.no> reports that if you type in
    commands really fast in ddd, it gets problems to cope.  When
    using DDD from XEmacs, and defining XEmacs command sequences to
    be sent to DDD, the last command(s) in the sequence get lost.

708 Nagi M. Aboulenein <naboulen@ichips.intel.com> says: I'm seeing a
    persistent problem with various version of DDD on FreeBSD/x86
    platforms. The problem occurs when an attempt is made to save
    options. At that point DDD dies and the options file is not
    updated.

709 Lev Makhlis <mlev@writeme.com> states that DDD 2.2.3
    (i586-pc-linux-gnulibc1) consistently crashes if he runs it when
    no `~/.ddd/' exists.

710 Marco Hess <marcoh@senet.com.au> says that sometimes, the source
    window locks in scroll mode until it reaches the top or bottom of
    the file.  [Changing the `glyphUpdateDelay' resource should fix
    this; tell me if this helps.  -AZ]

711 Brian Dowtin <Private_User@gilbarco.com> reports that on 
    SCO Server 5 and running DDD somehow the breakpoint pixmap
    'sticks' to the window.  Sometime after setting a breakpoint, The
    stop sign, stays in one spot. If I scroll up or down, its
    there. If I delete the actual breakpoint its still there. If I
    resize/close//reopen source window, its still there. If I load a
    different source file - you get the picture.

712 Ralf Hildebrandt <R.Hildebrandt@tu-bs.de> reports that on his
    HP-UX box, the tooltips are not complete: "Set/Delete Breakpo???",
    "Display/Undisplay???", etc.

713 Michael Marxmeier <mike@msede.com> writes: When configuring a
    separate Command Tool (with separate windows), its location
    relative to the source window changes.

    The border size is not accounted for. Everytime you change the
    location of the source window, the distance shrinks.  This happens
    with CDE on Linux.

    The border_width structure member (XWindowAttributes) seems to be
    always zero in recenter_tool_shell() although no error is
    returned. When the new cmd window position is calculated this will
    result in a slight move.

    [Could we check for the frame that actually adds a border?  -AZ]

714 Michael Marxmeier <mike@msede.com> writes: I discovered that ddd
    2.99.1 "run again" discards any arguments specified previously
    with "run".  This works fine with gdb so i assume ddd is
    responsible.

715 Terence P. Spielman <terence@GlobeSet.com> reports:
    1) I can accidentally paste material into the source window.  Once
       this is done, the gdb (debugger) window becomes unstable.
       Standard GDB cmds no longer work as expected.

    3) If a program is NOT running, yet I view the execution window
       (Alt+9) and then kill the window, ddd seg faults.

716 Michael Marxmeier <mike@msede.com> reports that 4 digit line
    numbers are truncated. Only the last three digits are visible.

717 Lassi A. Tuura <lat@iki.fi> states:

    On HP-UX and on DEC Unix everything is fine except that:

    - The default font I get is a bit big and clunky, the old one was
      much better (in case it matters, I have 100dpi fonts before
      75dpi fonts in my font path).  BTW, again this is only a problem
      on my HP-UX display (see the item below), not on the NT.

    - On data display window, the grayed out icons on the tool bar
      sometimes "disappear", i.e. don't show anything but the little
      arrow in the corner.  In more detail, the rotate icon disappears
      completely, undisplay is just a funny little light gray blob,
      and show/hide is somewhat larger but still unreadable blob.
      When enabled, all show just fine.  I would venture to guess that
      the problem is related to choosing right colors for them.  This
      is on on a 8-bit PseudoColor screen on workstation running HP-UX
      10.20.  On my Windows NT 4.0 running Exceed on 24-bit screen
      everything shows fine.

720 Jens Albrecht <Jens.Albrecht@informatik.uni-erlangen.de> complains 
    that using DBX, the `file' command does not change the source
    file.

721 Johan Vermeire <jvme@se.bel.alcatel.be> reports: `In ddd I
    tried to copy the whole contents of the command output buffer via
    the "select all" in ddd and to paste it into a UNIX editor for
    interpretation.  This results in: `gdb: write failed: Resource
    temporarily unavailable' messages until I kill the ddd process'.

722 Steffen Wieschalla <steffen.wieschalla@student.uni-tuebingen.de>
    uses ddd-2.99.99 with tvtwm-pl11 on Solaris 2.5.1.  He says: `If I
    start ddd, the window with the buttons "run", "stop", "step",
    "stepi", ... appears for a short time and then disappears. On
    e.g. fvwm it works correct. Does someone have an idea?'

723 (Insert new bugs here)
